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
IntelliJ should still work, but we're committed to Android Studio at
this point.
MozReview-Commit-ID: 3BaXB4dh4vA
--HG--
extra : rebase_source : 9c48f5c81613f77b32614b6f50b4e502a11fa4f0
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
Turns out Google's maven repository doesn't publish checksums. I
can't imagine why not, but there it is. We have to think more about
whether to trust the artifacts downloaded from maven.google.com.
MozReview-Commit-ID: CdWijorq1IV
--HG--
extra : rebase_source : a884971e51ce7b1ff993754b130f462c476646ab
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
The spec changed in order to align with the error thrown by importNode.
--HG--
rename : dom/tests/mochitest/webcomponents/test_bug1176757.html => dom/tests/mochitest/webcomponents/test_shadowroot_clonenode.html
The forthcoming window tracking refactoring introduces the new
abstractions ContentContext and ChromeContext that to a large extent
share the same interface. They make it possible to interact with
both types of browsing context in a uniform manner.
Marionette currently has a lot of convoluted if-conditions to
paper over the differences between ChromeWindow, <xul:browser>,
and browser.Context. Examples of this includes the assert.window
and assert.contentBrowser assertions: they essentially perform the
same job, but does not share the same API because the underlying
APIs they call are different.
In an effort to prepare Marionette for the window tracking refactoring,
this patch adds a bit of glue to combine them both into one assertion
called assert.open. This checks that the browsing context has not
been discarded.
MozReview-Commit-ID: K5e7Sr1mq0
