The Android ARchive contains the compiled Gecko libraries that Firefox
for Android interfaces to. It does not contain the Gecko resources
(the omnijar, omni.ja) nor the compiled Java code (classes.dex).
This also uploads metadata and sha1 hashes for future consumption by
Maven and/or Ivy dependency managers. In some brave future world,
we'll work out exactly what that looks like; for now, this solves a
storage problem (each .aar file is ~20MB) and it's possible to point
Gradle directly at the uploaded Ivy metadata and artifacts.
--HG--
extra : rebase_source : 0c12b44f587d4a027ca5258bae8fcbb6f6028c24
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
This is a little tricky only because MOZ_CHILD_PROCESS_NAME is
"lib/libplugin-container.so" on Android, which meant special handling
at multiple places in the tree. This patch reduces the number of such
places.
This builds a new Java JAR containing only org.mozilla.gecko.R. This
new JAR file is included in Fennec, but not included in
geckoview_library. (Usually ant, gradle, or Eclipse arranges to produce
org.mozilla.gecko.R but not include it in the classes.jar output as part
of a library project. This mimics that.)
Changing the GeckoView package to org.mozilla.gecko declares to
consuming applications that they should produce org.mozilla.gecko.R,
replacing what was removed above (but with correct resource IDs).
This is a temporary measure. We have multiple resource directories
that all need to be included into the GeckoView library. This patch
stuffs the resources into a zip file which can be included in the
GeckoView packaging step.
These resources used to be copied into res/, which led to
synchronization issues. This new zip file will now suffer the same
synchronization problems. Android Archive (.aar) files make this
synchronization step explicit, and tools such as gradle do the work to
keep things in sync. We'll move to use a tool like this eventually,
but for now...
James Willcox
Mike Hommey
Ahmed Khalil
Nick Alexander
Nathan Toone
Brad Lassey
Ms2ger
Shane Tully
Chris Peterson