Dispose the native call queue when disposing a window object, so we
don't end up with stale calls in the queue that can cause crashes.
MozReview-Commit-ID: J1HNOXKAX6E
--HG--
extra : rebase_source : 9a3ec940c19513d29c692d4e550fa3fd046d73f9
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : f599de01c63b873a95252d6b01128a6f069ff105
extra : intermediate-source : 060290b66b370137cfd3dbbac7c442ef107aaa68
extra : source : be888fa125dc1948fc073ed69aa8116f47e22877
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : 77470c2043598175c427a137b54f56263f6dc499
extra : intermediate-source : df53850e90878d703a2bd867dfbc13295aec998d
extra : source : 44bcb609e721598135a19bf41ba7ff94f3051553
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 9de77b6278bae76df3597bc2580bcedbf6d33075
extra : intermediate-source : c6e6fe49ecd2dd422878d80f57f1c89bf69eebff
extra : source : 8f1655752d43af33356d497d559888a967bbf6a0
The Page menu is disabled when no tab is open, so not doing a null-check on the
currently selected tab in the menu click handler is safe.
MozReview-Commit-ID: CYKHJ5N1q8I
--HG--
extra : rebase_source : 3ec7b1a9708a905785850feb44b48723c24f1363
We still need to explicitly set the progress when loading stops, so the progress
bar animates to completion before updateProgressState hides it, but in all other
cases calling just updateProgressState is enough to set the new progress value.
MozReview-Commit-ID: 9mQr5s83i9F
--HG--
extra : rebase_source : 7ce8751a97ea4220df7f3502c268507cd53a00dc
All they do is clutter up the log with "HighlightsRanking: Skipping invalid
highlight item." entries, so we should just skip them in the query already.
MozReview-Commit-ID: 1ra7LcYxp4m
--HG--
extra : rebase_source : 5f150e9ed5fd293f27f110cd2973525d5b82e86d
When checking settings categories, if category not found, scroll down; if still
not found, scroll up. This allows for the (apparently rare) case where settings
are initially rendered scrolled down, obscuring the top choice(s).
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 04a8e4b89153a2a11e8a793e893a2e626cbc877a
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : 009c13d53663553ded4d3645c926f12ecee9da0b
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 4184f40d82bcd44c2bb380d1a8ab534967818af5
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 1a6f7414c0b8108862701dca896befd815d2ac16
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : 63e4eaab1cf81b765503750c9b356fcc4a2470dd
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 0547c79ecf404688972fc55658f09bdfce07b613
Those are all remnants of APIs that are now gone for good.
MozReview-Commit-ID: 266GvgbES3s
--HG--
extra : rebase_source : d160f559bfcb805ecf02f53784777534ede943f4
This thorn in my side turns out to be unnecessary! For reasons
unknown, brand.dtd is not localized for mobile/android/ in the way it
is for browser/. That means we can just pull from the branding
directory, which avoids a frustrating issue where single-locale
repacks couldn't actually produce strings.xml since the subtle
dependency on the branding directory being built first wasn't
satisfied.
MozReview-Commit-ID: CBBaxfj5lMW
--HG--
extra : rebase_source : f020c82a78bb2d14760ba6cfb5d586795471bd8d
This got mixed up by Bug 1411654, which migrated to Android-Gradle
3.0+. However, it's also much easier to fix due to the changes in the
new version! This patch uses the new audience flavor dimension to
control the version of LeakCanary included.
Note that this turns off LeakCanary for builds produced by |mach
build|, because |mach build| always builds the official audience
flavor dimension. We could use MOZILLA_OFFICIAL to differentiate, but
it's not worth it: local developers who care about LeakCanary
will/should be running a local audience flavor dimension from Android
Studio.
MozReview-Commit-ID: ASgxhNOMsWc
--HG--
extra : rebase_source : a5de2b6fdaf92a1d91739ca0b480a9d04d434b8c
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 9e62ed6adf4b0fa01bcb9a927fa24626d3ce4d29
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : 325bc8142ec9b8a9d5029e7820e8f990d7e1a5fd
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 38a9781c472d858f3300cbbcbdc6d2311c465713
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : 2373eecc45e670ff7a5697f2e8095a8ea8fb5058
This was added for the Remote Tabs panel in Bug 785199. That code has
now morphed into the combined history panel, which uses a
RecyclerView.
MozReview-Commit-ID: J6KsVCn8mzh
--HG--
extra : rebase_source : 8e18f57882edee2de1e9decec323ea5831d314c8
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : 3b26f65d455c049b6190a9c481f8a4bec4e06dfd
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : c883a3fa60d1a47b19b53f2bbc7a9c2f0e2cf711
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : 01df9bd8ff4f2d700999ee5d2045890f8acb51ac
This was added in Bug 1096627 to enforce the baseline GeckoView
layering that we had at that time. Now that GeckoView is a separate
Gradle project, that layering is automatically enforced. It's time
for this to go.
MozReview-Commit-ID: Ly35QhgBdWM
--HG--
extra : rebase_source : 2a1807b3b06e332ca7d0980c01aa1e343f4df5d9
This was added in Bug 1096627 to enforce the baseline GeckoView
layering that we had at that time. Now that GeckoView is a separate
Gradle project, that layering is automatically enforced. It's time
for this to go.
MozReview-Commit-ID: Ly35QhgBdWM
--HG--
extra : rebase_source : 8b7b6c5f3386804209bccca48a1549cc74cd0836
A single color in the color list renders just as border-bottom-color.
This used to have two colors, but was changed in [1], so now it can go away.
[1]: https://hg.mozilla.org/mozilla-central/rev/cfdf310748918c3d5eadc16daa5153091e325995
MozReview-Commit-ID: LDocmCwjkzw
--HG--
extra : rebase_source : 0b5027434d7a964165f547c3c67f31045ecc3df4
Add a './mach android geckoview-docs' command that generates javadoc for
GeckoView using Gradle. Specifying the '--archive' option will generate
a geckoview-javadoc.jar archive. Specifying the '--upload' option,
intended primarily for Taskcluster, will upload the javadoc to Github
pages under the given user/repository.
MozReview-Commit-ID: HfwXlf8aFhw
--HG--
extra : rebase_source : 25ccbf3380ba2c8f391c48c882256f970be92c9f
Add some missing lines and fix some mistakes in our javadoc comments.
MozReview-Commit-ID: 9Q7qWJJ51Vo
--HG--
extra : rebase_source : afc70812b26de19e610412df014070b75c46017b
Tweak the javadoc task arguments to not generate errors for a standard
GeckoView javadoc run.
MozReview-Commit-ID: 931xCtUcX6N
--HG--
extra : rebase_source : 51e13cd4ec4a0ad9ec91e3bf2b52768aa6ba5e16
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 7f8f8e7b2ec80de1104d51815ff2b66f389a33c3
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : 1b4a681863e8917b473f4852c4b88fe1f95dc1fd
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 5a5730b4b9ce84af40a7c73c4f1abba017103f02
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : 311e1b18a2f0ad60b41d574f3c23aa160ecd56c0
This was added for the Remote Tabs panel in Bug 785199. That code has
now morphed into the combined history panel, which uses a
RecyclerView.
MozReview-Commit-ID: J6KsVCn8mzh
--HG--
extra : rebase_source : b7dcf3130878987b52a7184438f2d5a84002c2ad
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : fee00a6a068d68e7f7978df56bcad94997d70afb
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : d5efb14bff510e2a2982085237c53e27b4c7564d
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : 6390d41a43e2724e81f4c0ae6c3122f487b3f4a4
Jim Chen
Narcis Beleuzu
Brindusan Cristian
Dylan Roeh
Nick Alexander
Tad
Jan Henning
Gurzau Raul
Dão Gottwald
Grigory Kruglov
Mike Conley
Geoff Brown
Shane Caraveo
Ciure Andrei
Tiberius Oros
Ryan VanderMeulen
Noemi Erli
Dustin J. Mitchell
Margareta Eliza Balazs
Eugen Sawin
Coroiu Cristina
Emilio Cobos Álvarez
Dorel Luca