This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
This paves the way for defining additional Android packages in
moz.build, which is a step toward moving the special
mobile/android/base/Makefile.in aapt invocations into the generic
java-build.mk framework.
The new variables are both passthru variables for now: in the future,
we'll roll them into some aggregate Android APK definition.
It's worth noting that references to the variables in Makefile.in
files are only defined after including rules.mk (and thereby
backend.mk). This only required a few changes in the tree but it
confused me for some time.
The use case is to ship a classes.dex file in a Gecko add-on. This
makes it easy to extract such a file from an add-on to a temporary
location. (Sadly, the Android Dex loading classes expect files, not
streams.)
This was just a remnant from earlier days. This launched the Fennec
activity, which is absolutely *not* something we want to do during
these browser JUnit 3 tests. That is, these should be pure
instrumentation tests that just run Java code in the correct package
and Java classloader context. They shouldn't interact with the App
lifecycle at all.
Not all the tests pass; I took a shot at fixing one but don't care to
dig deeply right now.
There are few things happening here:
* A purely mechanical move of test sources into org.mozilla.test.browser.junit3.
This is only to make it easy to specify the suite in Spoon. (But it has the
advantage of making it possible to move files around in IntelliJ, since the
symlink points to src instead of org/mozilla/gecko.)
* Specifying the suite (package name) ended up requiring changes to the
spoon-gradle-plugin anyway. Hence, I've included this custom
spoon-gradle-plugin version locally, while I work to upstream the changes.
* Some Gradle trickery to make |mach gradle runBrowserTests| execute Spoon with
the correct package name.
These manifests are special in that they don't package their test files
into the test package. Each test listed in an instrumentation manifest
serves as an identifier rather than a file.
I also took the opportunity to move a constant into
AndroidManifest.xml.in; it removes a layer of indirection when trying to
determine what Android package gets built.
