This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icons were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough, but not round
enough to pass the lint check
--HG--
extra : rebase_source : 6c06c903f4fed2ef4aee3c5a915e18c437c5b510
extra : amend_source : ab3eab8e4dc2523a336aef2a4d2889ab7dbc76b9
extra : intermediate-source : 56f9803240157892066fa5b1703b8fe50c28020d
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icon were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough (ignoring the
Fennec icon for local developer builds)
--HG--
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
extra : amend_source : dc14ea076aafd9d24fd5ee7aebcf71348812942c
Used the provided foreground layers and background color for the icons of
Release and Nightly.
Used the old icon and the provided background color for the icons of Beta and
Dev builds. Proper icons for them will be added in bug 1479724.
Added support for round icons which as per
https://developer.android.com/about/versions/nougat/android-7.1#circular-icons
can be required by certain launchers.
The old icons - /drawable/icon.png are still kept because they are used as
logos and also by SiteIdentityPopup.java.
MozReview-Commit-ID: EA9pojukhmw
--HG--
extra : rebase_source : d960bb0785b329a91493d9fe2c126549a5641189
Used the provided foreground layers and background color for the icons of
Release and Nightly.
Used the old icon and the provided background color for the icons of Beta and
Dev builds. Proper icons for them will be added in bug 1479724.
The old icons - /drawable/icon.png are still kept because they are used as
logos and also by SiteIdentityPopup.java.
MozReview-Commit-ID: EA9pojukhmw
--HG--
extra : rebase_source : e546ab143aaba73751c729c79926df3fb08c3b8c
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Non-Mozilla distributors may wish to run their own autopush endpoint,
using a sender ID and corresponding Google API key that they control.
This simplifies that just a little bit, and gets Mozilla's release
engineering out of the business of managing non-sensitive secrets.
In the future, this sender ID will be baked into the Android APK's
string resources, in accordance with newer Google Play Services
library requirements.
MozReview-Commit-ID: AAxreEP73B0
--HG--
extra : rebase_source : 0a35d18a83558e4d27ac6a47b3833f1d69fed264
Note that this not the originally reviewed patch in the bug, but a re-run of
the algorithm that produced that patch.
--HG--
extra : commitid : 51DOIx3PKb8
extra : amend_source : f2e6b601240a9b31df7aadd96f6c53f0a6c430ef
The command I ran was:
for i in `find mobile -name "*.png" | sed "s/\(.*\)\/.*\.png/\1/" | sort | uniq`; do trimage -d ${i}; done
--HG--
extra : rebase_source : 90ae53a7e3c63834b1bbb251cc4e5c48e5d20f08
Every directory with a jar.mn now has JAR_MANIFESTS defined in its
moz.build file.
We also removed the may_skip special consideration of jar.mn files
because this information is now available during tier traversal by the
reader courtesy of the variables being present in moz.build files.
--HG--
extra : rebase_source : 21049b15e6bd9cf65b0805ccaccc4ba5aae93c98
extra : amend_source : 0b1ea866d725beef92d37c6f6d475369ac002e19