Quick start
Temporarily, you’ll need to pull the new mach command into your source tree:
It’s easy! Open your mozconfig file and add:
You might want to also use a different object directory:
Then mach build and mach build mobile/android as usual. When it’s time to package an APK, use:
instead of mach package. Use mach install like normal to deploy to your device!
After running mach package-frontend once, mach gradle-install, mach gradle
app:installDebug, and developing with IntelliJ (or Android Studio) work as well.
Disclaimer
This only works when you are building Fennec (Firefox for Android) and developing JavaScript and/or
Fennec frontend Java code!
You have been warned.
Options
mach package-frontend takes a couple of options that let you control downloading:
--force-remote-binaries, -r
Download and use remote binaries without comparing local and remote timestamps.
--force-local-binaries, -l
Do not download remote binaries; use local cached binaries.
Troubleshooting
What version of the downloaded binaries am I using?
Look in ~/.mozbuild/package-frontend/stage/assets/fennec-*.json for build ID, timestamps, and
additional configuration.
I’m seeing weird errors and crashes!
Since your local build and the upstream binaries may diverge, lots of things can happen. If the
upstream binaries change a C++ XPCOM component, you may see a binary incompatibility. Such a
binary incompatibility looks like:
You should update your tree (using hg pull -u --rebase or similar) and run mach build && mach
package-frontend again.
Technical details
There are two things happening here. The reduction in build time comes from
--disable-compile-environment: this tells the build system to never build C++ libraries
(libxul.so and friends) [1]. On my laptop, a clobber build with this configuration
completes in about 3 minutes [2]. This configuration isn’t well tested, so please file
tickets blocking Bug 1159371.
The new mach package-frontend downloads pre-built binaries [3], copies them into your
object directory, and then runs the regular packaging code to include them in an APK. This new mach
command is tracked at Bug 1162191. A successful run looks something like:
If the upstream binaries haven’t changed, new binaries aren’t downloaded, so it’s reasonable to use
mach package-frontend as a drop-in replacement for mach package:
Conclusion
In my blog post The Firefox for Android build system in 2015, the first priority was making it
easier to build Firefox for Android the first time. So I landed mach bootstrap for Fennec, and
we turned an onerous process into a one-liner that works for most people [4]. The second
priority was reducing the edit-compile-test cycle time. The work described here drastically reduces
the first compile-test cycle time, and subsequent compile-test cycles after pulling from the
upstream tree. It’s hitting part of the first priority, and part of the second priority. Baby steps.
The Firefox for Android team is always making things better for contributors! Get involved with
Firefox for Android.
Discussion is best conducted on the mobile-firefox-dev mailing list and I’m nalexander on
irc.mozilla.org/#mobile and @ncalexander on Twitter.
Changes
Fri 8 May 2015: Thanks @michaelcomella for pointing out a bad Bugzilla ticket number.
Notes
[1]
In theory, --disable-compile-environment also means we don’t need a host C++
toolchain (e.g., gcc targeting Mac OS X) nor a target C++ toolchain (e.g., the Android NDK).
This is not my primary motivation but I’m happy to mentor a contributor who wanted to test this
and make sure it works! It would be a nice win: you could get a working Fennec build with fewer
(large!) dependencies.
[2]
I intend to profile mach build in this case and try to improve it. Much of
the build is essentially single-threaded in this configuration, including compiling the Java
sources for Fennec. Splitting Fennec into smaller pieces and libraries would help, but that is
hard. See for example Bug 1104203.
[3]
By default, the downloaded binaries are stored in ~/.mozbuild/package-frontend.
The remote binaries change frequently — several times a day — and are not yet purged from your
local cache after a reasonable time. In future, we’ll download less (maybe once a day? maybe
only according to the latest revision in your local tree?) and delete old binaries after some set
time (one week?).
[4]
This was tracked by Bug 1108771. It’s made a huge difference, and I should
know: I used to field build problems in #mobile every few days. Now, I field build problems
every few months.