Create fat .aar for geckoview
Downstream consumers like android-components and fenix use fat .aar files. We need to create them out of ouf per-arch ones. https://bugzilla.mozilla.org/show_bug.cgi?id=1508976 is the bug where this got implemented on Mozilla's side.
Activity
Trac:
Parent Ticket: #33184 (moved)
Child Ticket(s): #33987 (moved)
So, by default the current firefox project in #33626 (moved) produces a .arr file per
armv7,aarch64,x86andx86_64. However, downstream consumers expect a .aar with all those 4 .aar files merged. We need to figure out how that model fits into our build system. I am not sure yet what the best solution is given that we are dealing with arch-dependent code.
Replying to gk:
boklm had the idea to just use a for loop in the
geckoviewproject to build all the per arch .aar files and then merge them in a final step and use that one as output. I think that's the closest to what I had in mind and I'll start playing with that.I think the loop can be done in two ways. Either with the
forfrom shell:for arch in [% c('var/android_archs').join(' ') %] do cp $rootdir/mozconfig-android-$arch .mozconfig make doneor the
FOREACHfrom template language:[% FOREACH arch = c('var/android_archs') %] cp $rootdir/mozconfig-android-[% arch %] .mozconfig make [% END %]-
An other option is using a separate
stepinprojects/geckoview/configto merge the .aar files. Inprojects/geckoview/configwe would add something like this:steps: merge_aars: merge_aars: | #!/bin/bash # commands to merge .aar files input_files: - name: geckoview_armv7 project: geckoview pkg_type: build target_prepend: torbrowser-android-armv7 - name: geckoview_aarch64 project: geckoview pkg_type: build target_prepend: torbrowser-android-aarch64And in
projects/fenix/configwe would have something like this:input_files: - name: geckoview project: geckoview pkg_type: merge_aarsIn
rbm.confwe also need to setvar/container/disable_network/merge_aarsto prevent network access during themerge_aarsstep.Then we can use the following command to build geckoview for a single arch:
./rbm/rbm build geckoview --target nightly --target torbrowser-android-x86_64Or this command to build it for all archs and merge them:
./rbm/rbm build geckoview --step merge_aars --target nightly --target torbrowser-android-all -
Seems I am running into issues:
07:23 <+GeKo> boklm: another question: we have arch specific dependencies in the input_files (the genneral ones, not for the steps part) to build the per arch .aar, e.g. the rust compiler or the mozconfig files. how make i those available? 07:23 <+GeKo> right now i only get a weird non-descriptive error 07:26 <+GeKo> Error: Missing filename: 07:26 <+GeKo> { name => "[% c(\"var/compiler\") %]", project => "[% c(\"var/compiler\") %]", 07:27 <+GeKo> } 07:42 <+GeKo> boklm: oh, i actually see a different error if i remove the compiler project: https://paste.debian.net/1142722/ 07:42 <+GeKo> which is not really more descriptive, though :) 07:43 <+GeKo> fwiw, that's with my bug_33973 07:45 <+GeKo> oh, and i get it again if i have the compiler project removed _and_ the mozconfig part, weird 07:50 <+GeKo> and once rust/cbindgen deps are removed additionally i am past that breakage -
Okay, for the fat .aar creation we would have to do in the
stepsstep:- Specify the archs we support like so:
export MOZ_ANDROID_FAT_AAR_ARCHITECTURES=armeabi-v7a,arm64-v8a,x86,x86_64 - export the relative paths to the respective arch dependent .aar file using
MOZ_ANDROID_FAR_AAR_ARMEAVI_V7A,MOZ_ANDROID_FAT_AAR_ARM64_V8A,MOZ_ANDROID_FAT_AAR_X86, andMOZ_ANDROID_AAR_X86_64The full path is assembled out ofMOZ_FETCHES_DIR+ the relative ones above (so we need to export the absoluteMOZ_FETCHES_DIR, too. - We should be able to run now
./mach build android-fat-aar-artifactand the .aar should be in$DIST/fat-aar
(I've not tested that locally, yet, though)
- Specify the archs we support like so:
-
Replying to gk:
Seems I am running into issues:
07:23 <+GeKo> boklm: another question: we have arch specific dependencies in the input_files (the genneral ones, not for the steps part) to build the per arch .aar, e.g. the rust compiler or the mozconfig files. how make i those available? 07:23 <+GeKo> right now i only get a weird non-descriptive error 07:26 <+GeKo> Error: Missing filename: 07:26 <+GeKo> { name => "[% c(\"var/compiler\") %]", project => "[% c(\"var/compiler\") %]", 07:27 <+GeKo> } 07:42 <+GeKo> boklm: oh, i actually see a different error if i remove the compiler project: https://paste.debian.net/1142722/ 07:42 <+GeKo> which is not really more descriptive, though :) 07:43 <+GeKo> fwiw, that's with my bug_33973 07:45 <+GeKo> oh, and i get it again if i have the compiler project removed _and_ the mozconfig part, weird 07:50 <+GeKo> and once rust/cbindgen deps are removed additionally i am past that breakage }}}Okay, some process update. That got solved by specifying
torbrowser-android-allinrbm.conf. But then I ran into: {{{ Finished build of project geckoview - geckoview-0dfb56be3c95-android-armv7-5a3e0a Using file /home/gk/tor-browser-build/out/geckoview/geckoview-0dfb56be3c95-android-armv7-5a3e0a Using file /home/gk/tor-browser-build/out/geckoview/geckoview-0dfb56be3c95-android-armv7-5a3e0a Using file /home/gk/tor-browser-build/out/geckoview/geckoview-0dfb56be3c95-android-armv7-5a3e0a Using file /home/gk/tor-browser-build/out/geckoview/geckoview-0dfb56be3c95-android-armv7-5a3e0a rmdir: failed to remove '/srv/home/gk/tor-browser-build/tmp/rbm-CImP7X/rbm-containers/c77fb04e301ae68b9658a685734e5dbd8a6d46eb4d0ee7bb339f1c723bb9528a': No such file or directory Error: Error starting remote:ls: cannot access '/srv/home/gk/tor-browser-build/tmp/rbm-ABnir/container-image_*': No such file or directory Can't find container image in input files total 535100 -rw-r--r-- 1 gk gk 52608651 Apr 24 14:19 geckoview-0dfb56be3c95-android-armv7-5a3e0a -rw-r--r-- 1 gk gk 495327146 Apr 21 15:37 geckoview-0dfb56be3c95.tar.gz
So, for one using four times `armv7` is weird and wrong. It turned out boklm found the bug in my config in that `target_prepend` is supposed to be an array. After fixing that and rebuilding everything with commit `9e4ec0dd1a256de2b75923daa5be0e40996dac48` on `bug_33973` I am still running into the second problem shown in the debug output above. That can easily be solved by adding `container-image` to the `input_files`, too. -
Replying to gk:
So, for one using four times
armv7is weird and wrong. It turned out boklm found the bug in my config in thattarget_prependis supposed to be an array.##33993 (moved) is the ticket to make that error easier to notice.
-
It feels like I am close
0:00.29 /usr/bin/make -j4 -s android-fat-aar-artifact 0:03.21 Allowed: Path "AndroidManifest.xml" has architecture-specific versions: 0:03.21 arm64-v8a -> 71ba81e1e30418fc9b4bc82840fc7f5e437f07f3 0:03.21 x86 -> c5589f4eab042c16278f7f30c6194f995188ed07 0:03.21 Allowed: Path "classes.jar!/org/mozilla/gecko/util/HardwareUtils.class" has architecture-specific versions: 0:03.21 arm64-v8a -> b20b005c5b7c473aff24ce4747f4589e6fd69698 0:03.21 x86 -> c045eae4f64a96575cfcbdf5cfdcc27602371aa5 0:03.21 Allowed: Path "classes.jar!/org/mozilla/geckoview/BuildConfig.class" has architecture-specific versions: 0:03.21 arm64-v8a -> f492c2498953491d3c2126938625eaaa2fe59b46 0:03.21 x86 -> 8bc9603aed7e2bcd0bb91b521e7b2911ac2749b9 0:03.21 Disallowed: Path "assets/chrome/toolkit/content/global/buildconfig.html" has architecture-specific versions: 0:03.21 arm64-v8a -> bb0179449820e27bb8df8dfba3b227238276b59a 0:03.21 x86 -> dd7dd9dab631d9a33f417de707bd73bc02e21035 0:03.21 Disallowed: Inputs missing expected architecture-specific input: arm64-v8a/greprefs.js 0:03.21 Disallowed: Inputs missing expected architecture-specific input: defaults/pref/arm64-v8a/geckoview-prefs.js 0:03.21 Disallowed: Inputs missing expected architecture-specific input: defaults/pref/x86/geckoview-prefs.js 0:03.21 Disallowed: Inputs missing expected architecture-specific input: x86/greprefs.js 0:03.23 make[1]: *** [Makefile:151: recurse_android-fat-aar-artifact] Error 1 -
Replying to cypherpunks:
Yeah, I know. But if you look at some arch dependent .aar files published by Mozilla you'll see that there are no such .js files in them as in those .aar files I generate. Yet, they have a fat .aar, too (without those .js files, of course). One option is that they just disable the compatibility check which seems to be weird, though.
Yeah, I know. But if you look at some arch dependent .aar files published by Mozilla you'll see that there are no such .js files in them as in those .aar files I generate. There is no architecture-specific versioning in them at all (as it should be). Yet, they have a fat .aar, too (without those .js files, of course). Are you sure?
-
To give an update: the problem seems to be that
missing_arch_prefsat https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/action/fat_aar.py#51 is{'defaults/pref/arm64-v8a/geckoview-prefs.js', 'arm64-v8a/greprefs.js'}while the respectivepaths at https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/action/fat_aar.py#59 areassets/defaults/pref/arm64-v8a/geckoview-prefs.jsandassets/arm64-v8a/greprefs.js. So, they don't get discarded [assets/defaults/pref/arm64-v8a/geckoview-prefs.js and assets/arm64-v8a/greprefs.js later on] when trying to generate the far .aar locally. Many thanks to jlorenzo to getting me that far.Checking what Mozilla's CI is doing instead or whether it has additional config did not lead to any clues so far.
-
FWIW, I suspect the issue with different
buildconfig.htmlfiles has the same underlying cause: the problematic path is atassets/chrome/toolkit/content/global/buildconfig.htmlwhile the whitelisted one ischrome/toolkit/content/global/buildconfig.html. -
Trac:
0001-fat-aar-patch.patch -
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4cd793e009c72aed1a5dd81135c5ea501204f779&selectedTaskRun=c-RHgbOgS5OHGYjsgIxskQ-0 corresponds to the
0001-fat-aar-patch.patchand we see that the fat .aar creation succeeds on CI. -
https://bugzilla.mozilla.org/show_bug.cgi?id=1633873 tracks this now on Mozilla's side and be it only to help someone else saving a ton of time figuring out what the heck is going on. :)
-
Okay, for those of you sitting at home and watching along, I finally got this going (thanks for boklm for the invaluable help). A fat .aar file should be buildable with
bug_33973_v2(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v2&id=31d4d5b5c57c45603958295aa92aafe51e6c29d8).(Reparenting as well as Trac does not like a depth > 5)
Trac:
Parent: #33626 (moved) to #33184 (moved) -
bug_33973_v6(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v6&id=2a5a929ccb804fdf3186a4017b2e9db77bb0d4c7) has the fat .aar creation up for review. The patch is directly on top ofbug_33626_v9. Thus, the branch directly buildable pointing to acat's33533+5etc../rbm/rbm build geckoview --step merge_aars --target torbrowser-testbuild --target torbrowser-android-allis the test command one could use. -
Replying to gk:
bug_33973_v6(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v6&id=2a5a929ccb804fdf3186a4017b2e9db77bb0d4c7) has the fat .aar creation up for review. The patch is directly on top ofbug_33626_v9. Thus, the branch directly buildable pointing to acat's33533+5etc../rbm/rbm build geckoview --step merge_aars --target torbrowser-testbuild --target torbrowser-android-allis the test command one could use.bug_33973_v7(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v7&id=92263ab103d9f0ee71f5742d5b228c31d36d8b3d) has the latest work. No changes to the patch itself, just built on the slightly changed android toolchain and improvements in the rust project. 
I have managed to build this branch now on two different machines.
The only changes I have had to make so far are:
diff --git a/README b/README index 8e97e2f..2457f15 100644 --- a/README +++ b/README @@ -198,7 +198,7 @@ builds, and will require that you run Debian Stretch and install build dependencies for all the components that are built. This can be done with the following command: - # apt-get install build-essential python automake libtool zip unzip + # apt-get install build-essential python automake libtool zip unzip \ autoconf2.13 openjdk-8-jdk gettext-base autotools-dev \ automake autoconf libtool autopoint libssl-dev \ pkg-config zlib1g-dev libparallel-forkmanager-perl \ diff --git a/projects/geckoview/config b/projects/geckoview/config index 63da289..ddab204 100644 --- a/projects/geckoview/config +++ b/projects/geckoview/config @@ -93,6 +93,7 @@ steps: input_files: - project: container-image + pkg_type: build - name: '[% c("var/compiler") %]' project: '[% c("var/compiler") %]' pkg_type: buildWhere the last part was from boklm and GeKo on IRC.
From what I can tell with the code is that it seems reasonable. I am not sure what the common strategy is for when you review build-system components in the browser. In Tor we have all kinds of sanitizers from shellcheck that we run on shell-like scripts. The code looks fine to me, is easy to understand once the gist of rbm kicks in.
-
Replying to ahf:
I have managed to build this branch now on two different machines.
The only changes I have had to make so far are:
{{{ diff --git a/README b/README index 8e97e2f..2457f15 100644 --- a/README +++ b/README @@ -198,7 +198,7 @@ builds, and will require that you run Debian Stretch and install build dependencies for all the components that are built. This can be done with the following command:
-
apt-get install build-essential python automake libtool zip unzip
-
apt-get install build-essential python automake libtool zip unzip \
autoconf2.13 openjdk-8-jdk gettext-base autotools-dev \ automake autoconf libtool autopoint libssl-dev \ pkg-config zlib1g-dev libparallel-forkmanager-perl \
diff --git a/projects/geckoview/config b/projects/geckoview/config index 63da289..ddab204 100644 --- a/projects/geckoview/config +++ b/projects/geckoview/config @@ -93,6 +93,7 @@ steps:
input_files: - project: container-image-
pkg_type: build - name: '[% c("var/compiler") %]' project: '[% c("var/compiler") %]' pkg_type: build
}}}
Where the last part was from boklm and GeKo on IRC.
Thanks. The first part is addressed in #34247 (moved) and for the other one I pushed a fixup commit to
bug_33973_v7(commit3a24048253dd5f4fe79c0d44e3aff9f0fdb81d92).bug_33973_v8(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v8&id=544853e0c7c8adb58fb36a4582244a00f72a5838) has the fixed up commit rebased on latestmasterand the updated branch for #33626 (moved) (bug_33626_v11).From what I can tell with the code is that it seems reasonable. I am not sure what the common strategy is for when you review build-system components in the browser. In Tor we have all kinds of sanitizers from shellcheck that we run on shell-like scripts. The code looks fine to me, is easy to understand once the gist of rbm kicks in.
There are no sanitizers for
tor-browser-buildchanges (yet). It's "just" code change review and testing that the proposed changes actually work.Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam202005 deleted, TorBrowserTeam202005R added -
-
The proposed changes seems to work. I have been able to build it reproducible on two different machines and learned about a hw issue on a third machine. It sounds like I got the same results as GeKo, which is good. I have not tried to build with _v8, but only with _v7, but it seems like _v8 is fixing the one issue I had with 'container-image'.
The perl/bash and yaml all seems good to me.
Trac:
Status: needs_review to merge_ready -
Replying to ahf:
The proposed changes seems to work. I have been able to build it reproducible on two different machines and learned about a hw issue on a third machine. It sounds like I got the same results as GeKo, which is good. I have not tried to build with _v8, but only with _v7, but it seems like _v8 is fixing the one issue I had with 'container-image'.
The perl/bash and yaml all seems good to me.
Thanks! I realized we should probably not just copy the .aar file over but the .pom one as well so the dependencies are visible, too. I pushed a fixup commit to
bug_33973_v8(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_33973_v8&id=7133b4d9b32008b1c5063681960888fdab1fe498) for review.Trac:
Status: merge_ready to needs_review mentioned in issue #33989 (moved)
mentioned in issue #34005 (moved)
mentioned in issue #34013 (moved)
mentioned in issue #33184 (moved)
mentioned in issue #33987 (moved)
mentioned in issue tpo/applications/rbm#33989
mentioned in issue tpo/applications/tor-browser#34005