The fat AAR task aggregates multiple platform-specific builds into a single
package. This is done with a build, since that's the natural entry point
into the Gradle packaging step. Historically, that build was a "full build",
since the resulting omnijar needed to be multi-locale. But that's no longer
true; now the input builds are multi-locale, so there's no need to run the
multi-locale steps in this task. That means we can use artifact builds and
avoid the long full build in this task. The only change is to the generated
buildconfig.xhtml; having that vary in a fat AAR package is not impactful.
Details
- Reviewers
nalexander RyanVM - Group Reviewers
geckoview-reviewers - Commits
- rFIREFOXAUTOLANDbff5347a6d02: Bug 1918653 - Make shippable fat AAR builds faster r=nalexander,geckoview…
rFIREFOXAUTOLAND587bf55a03e5: Bug 1918653 - Make shippable fat AAR builds faster r=nalexander,geckoview… - Bugzilla Bug ID
- 1918653
Diff Detail
- Repository
- rFIREFOXAUTOLAND firefox-autoland
Event Timeline
Code analysis found 5 defects in diff 1242960:
- 5 defects found by android-fenix (Mozlint)
You can run this analysis locally with:
- ./mach lint --warnings --outgoing
If you see a problem in this automated review, please report it here.
You can view these defects in the Diff Detail section of Phabricator diff 1242960.
Thoughts:
- This needs a commit message explaining why this is safe. Something like:
"The fat AAR task aggregates multiple platform-specific builds into a single package. This is done with a build, since that's the natural entry point into the Gradle packaging step. Historically, that build was a "full build", since the resulting omnijar needed to be multi-locale. But that's no longer true; now the input builds are multi-locale, so there's no need to run the multi-locale steps in this task. That means we can use artifact builds and avoid the long full build in this task. The only change is to the generated buildconfig.xhtml; having that vary in a fat AAR package is not impactful."
- This needs to handle -lite, which I don't think it does.
- I'm confident that the only change this makes is to buildconfig.xhtml. I tested this by adding support for setting the pushdate (not yet landed) and manually inspecting try builds; see original build and build with this patch applied, pushdate set, and existing tasks re-used.
@RyanVM -- FYSA. We'd talked about this in the past, but it was blocked on digging into the produced APKs. I did that last weekend, so I think we're good to go with this.
Looks like it works the way we had previously discussed, thanks! Any chance we'll eventually extend this to Beta & Release also so we get the E2E benefits there as well?
Ask and ye shall receive. As far as I'm aware, there's nothing channel-specific here. Does this require fat-aar variants of the beta and release mozconfigs?