The mobile/android build system is fairly complex, and the interaction between mach build, Gradle, and mach package is essentially stored in nalexander's head. As a step on the road to simplifying the whole system, and as a first approximation to getting critical functionality out of nalexander's head, some automated testing will help.

In the tree, we have support for cram via mach cramtest. cram is a simple shell testing framework very similar to the one used by Mercurial. My initial thought for this is a set of cram tests that arrange for an Android artifact build and then verify that touching various files results in suitable build/Gradle tasks being executed and appropriate outputs updated.

The real focus here is GeckoView, so this might include:

• GV main Java => JNI wrappers updated, GV AAR updated
• GV androidTest Kotlin => GV/TRA test APK updated
• GVE main Java => GVE APK updated
• GV chrome resources => stage-package invoked, omni.ja in GV AAR updated
• Gecko native code => mach build binaries invoked, libxul.so in GV AAR updated

ahal: any thoughts on why new cram tests wouldn't get picked up? The test manifest stuff is so involved that I'm never quite sure what's supposed to happen... see this try task. Locally, mach cramtest mobile/android works. But I have --enable-application=mobile/android: is this due to some conditional inclusion of moz.build files? Should I:

1. put these cram tests in some global location, like /build (which has tests that do not seem to be run, just FYI)?
2. name the .t file in the command, so they always get found?
3. something else entirely? Maybe narrow clones are to blame?

Thanks!

This starts to convert the cram shell-based tests to Python.

Depends on D161508

Nick and I chatted about this in Matrix and, yes it was due to conditional moz.build processing.

To work around similar problems in the past, we've included the manifests from here:
https://searchfox.org/mozilla-central/rev/d7d2cc647772de15c4c5aa47f74d25d0e379e404/toolkit/toolkit.mozbuild#9

Tasks and enhancements should have severity N/A.

Depends on D175167

Depends on D175168

Gabriel: okay, here's my WIP on these build system changes. The stack is rooted at https://phabricator.services.mozilla.com/D175166.

Bug 1791878 is unchanged, I think, from what RyanVM posted.

Bug 1799002 is what is actually required to make Android-Gradle plugin version 7.3.0 work. It's the part that updates the complicated library shuffling that we had before and simplifies a lot of the code. It's tricky because it really can only be manually tested, and that manual testing is mostly for the local GV substitution flow. With the move to bring the Android products into m-c that will no longer be needed, but we're still a goodly way away from that. I believe that this ticket needs no further work, although additional testing -- both locally and on try -- would go a long way.

Finally, Bug 1570400 is very much WIP. It sets up a new source test that will run in automation. That source test invokes artifact builds and verifies certain details of the AARs and APKs produced. I hacked through to verify that the local GV substitution flow actually works, but I haven't verified lots of other things. You can see various .patch files and some shell tests that I started working on before switching to Python. It's not essential that we land Bug 1570400 but it really would be helpful to get this set up: as we bring Android products into m-c we'll be able to grow our confidence in certain critical build paths succeeding.

This try build https://treeherder.mozilla.org/jobs?repo=try&revision=9f3a6ccfe43011a98cffd01492de7d30435cfa96 runs the Python tests and builds fat AARs (which might be busted, I don't know right now).

Fat AARs failed due to artifact builds above. Here's a try build with full builds: https://treeherder.mozilla.org/jobs?repo=try&revision=6882afb388deacc2c504fe6bc1987930913b4734.