GeckoView For Gecko Engineers¶
Table of contents¶
Introduction¶
Who this guide is for: As the title suggests, the target audience of this guide is existing Gecko engineers who need to be able to build and (locally) test GeckoView. If you aren’t already familiar with building Firefox on a desktop platform, you’ll likely be better served by reading our general introduction. This guide may also be helpful if you find you’ve written a patch that requires changing GeckoView’s public API, see Landing a Patch.
Who this guide is not for: As mentioned above, if you are not already familiar with building Firefox for desktop, you’d likely be better served by our general bootstrapping guide. If you are looking to contribute to front-end development of one of Mozilla’s Android browsers, you’re likely better off starting with their codebase and returning here only if actual GeckoView changes are needed. See, for example, Fenix on Mozilla Central.
What to do if this guide contains bugs or leads you astray: The quickest way to get a response is to ask generally on #gv on Mozilla Slack; #mobile on Mozilla IRC may also work for the time being, albeit likely with slower response times. If you believe the guide needs updating, it would also be good to file a ticket to request that.
Configuring the build system¶
First, a quick note: This guide was written on MacOS 10.14; it should
translate quite closely to other supported versions of MacOS and to
Linux. Building GeckoView on Windows is not officially supported at the
moment. To begin with, re-run ./mach bootstrap; it will present you
with options for the version of Firefox/GV that you want to build.
Currently, option 3 is
GeckoView/Firefox for Android Artifact Mode and 4 is
GeckoView/Firefox for Android; if you’re here, you want one of
these. The brief and approximately correct breakdown of Artifact vs
regular builds for GeckoView is that Artifact builds will not allow
you to work on native code, only on JS or Java. Once you’ve selected
your build type, bootstrap should do its usual thing and grab
whatever dependencies are necessary. You may need to agree to some
licenses along the way. Once bootstrap has successfully completed,
it will spit out a recommended mozconfig.
Mozconfig and Building¶
If you’ve followed from the previous section, ./mach bootstrap
printed out a recommended mozconfig that looks something like this:
# Build GeckoView/Firefox for Android:
ac_add_options --enable-project=mobile/android
# Targeting the following architecture.
# For regular phones, no --target is needed.
# For x86 emulators (and x86 devices, which are uncommon):
# ac_add_options --target=i686
# For newer phones.
# ac_add_options --target=aarch64
# For x86_64 emulators (and x86_64 devices, which are even less common):
# ac_add_options --target=x86_64
As written, this defaults to building for a 32-bit ARM architecture,
which is probably not what you want. If you intend to work on an actual
device, you almost certainly want a 64-bit ARM build, as it is supported
by virtually all modern ARM phones/tablets and is the only ARM build we
ship on the Google Play Store. To go this route, uncomment the
ac_add_options --target=aarch64 line in the mozconfig. On the
other hand, x86-64 emulated devices are widely used by the GeckoView
team and are used extensively on try; if you intend to use an
emulator, uncomment the ac_add_options --target=x86_64 line in the
mozconfig. Don’t worry about installing an emulator at the moment,
that will be covered shortly. It’s worth noting here that other
mozconfig options will generally work as you’d expect. Additionally,
if you plan on debugging native code on Android, you should include the
mozconfig changes mentioned in our native debugging guide. Now, using
that mozconfig with any modifications you’ve made, simply
./mach build. If all goes well, you will have successfully built
GeckoView.
Installing, Running, and Using in Fenix/AC¶
An (x86-64) emulator is the most common and developer-friendly way of
contributing to GeckoView in most cases. If you’re going to go this
route, simply run ./mach android-emulator — by default, this will
install and launch an x86-64 Android emulator running the same Android
7.0 image that is used on try. If you need a different emulator
image you can run ./mach android-emulator --help for information on
what Android images are available via mach. You can also install an
emulator image via Android Studio. In cases where an emulator may not
suffice (eg graphics or performance testing), or if you’d simply prefer
not to use an emulator, you can opt to use an actual phone instead. To
do so, you’ll need to enable USB Debugging on your phone if you
haven’t already. On most modern Android devices, you can do this by
opening Settings, going to About phone, and tapping
Build number seven times. You should get a notification informing
you that you’ve unlocked developer options. Now return to Settings,
go to Developer options, and enable USB debugging.
GeckoView Example App¶
Now that you’ve connected a phone or setup an emulator, the simplest way
to test GeckoView is to launch the GeckoView Example app by running
./mach run (or install it with ./mach install and run it
yourself). This is a simplistic GV-based browser that lives in the tree;
in many cases, it is sufficient to test and debug Gecko changes, and is
by far the simplest way of doing so. It supports remote debugging by
default — simply open Remote Debugging on your desktop browser and the
connected device/emulator should show up when the example app is open.
You can also use the example app for native debugging, follow the
native debugging guide.
GeckoView JUnit Tests¶
Once you’ve successfully built GV, you can run tests from the GeckoView
JUnit test suite with ./mach geckoview-junit. For further examples
(eg running individual tests, repeating tests, etc.), consult the quick
start guide.
Fenix and other GV-based Apps¶
If you are working on something for which the GeckoView Example app is not sufficient for some reason, you may need to use your local build of GeckoView in one of Mozilla’s GV-based apps like Fenix.
Debugging¶
Remote Debugging¶
To recap a bit of the above, in the GeckoView Example app, remote
debugging is enabled by default, and your device should show up in your
desktop browser’s Remote Debugging window with no special effort. For
Fenix, you can enable remote debugging by opening the three-dot menu and
toggling Remote debugging via USB under Developer tools; other
Mozilla GV-based browsers have similar options.
Native Debugging¶
To perform native debugging on any GV app will require you to install Android Studio and follow instructions here.
Landing a Patch¶
In most cases, there shouldn’t be anything out of the ordinary to deal
with when landing a patch that affects GeckoView; make sure you include
Android in your try runs and you should be good. However, if you
need to alter the GeckoView public API in any way — essentially anything
that’s exposed as public in GeckoView Java files — then you’ll find
that you need to run the API linter and update the change log. To do
this, first run ./mach lint --linter android-api-lint — if you have
indeed changed the public API, this will give you a gradle command
to run that will give further instructions. GeckoView API changes
require two reviews from GeckoView team members; you can open it up to
the team in general by adding #geckoview-reviewers as a reviewer on
Phabricator.