1500607 - Simplify Fennec and GeckoView product flavors

Status: NEW

(Firefox Build System :: Android Studio and Gradle Integration, enhancement)

Description

[Nick Alexander :nalexander [he/him]]

Now that we always build with Gradle (post Bug 1414415), we can start to remove some of the complexity that Bug 1242284 added.  We build a dizzying array of product flavors along many dimensions: see https://searchfox.org/mozilla-central/rev/9cb3e241502a2d47e2d5057ca771324a446b6695/mobile/android/docs/gradle.rst#29.  Per https://searchfox.org/mozilla-central/rev/9cb3e241502a2d47e2d5057ca771324a446b6695/mobile/android/gradle/product_flavors.gradle#7

- audience
- geckoBinaries
- minApi

and for Fennec,

- skin

Now, skin is always Photon and can just be removed.  minApi is only used to opt-in to some developer features, and if https://developer.android.com/studio/build/optimize-your-build#create_dev_variant is to be believed, it's not necessary when deploying to a device from within Android Studio.  Android Studio is the only developer environment we really care about, so I think minApi can be removed now too.

Now, audience and geckoBinaries.  audience is exactly MOZILLA_OFFICIAL and can be dropped.  Historically the Gradle support was a ride-along to moz.build producing JARs and APKs, and it seemed more important to be very clear who the target audience was, in particular to be able to developer-centric things based on the product flavor.  But those developer-centric things largely didn't transpire, so that's no longer something that needs to be called out explicitly.

That leaves geckoBinaries, the really complicated piece of the puzzle.  The tough thing about geckoBinaries is that it's a product flavor capturing a _stage_ of the build.  In particular, it's used during the moz.build integration to produce a Fennec APK _before_ |mach package| has run and the native code libraries have been built.  In addition, the |mach android ...| test tasks run against withoutGeckoBinaries flavors (for Fennec), because they don't actually require libraries.  But we also run withGeckoBinaries flavors (for GeckoView), so the libraries must be present at test time (or those tasks would fail).  All of this suggests that we can:

a) remove the geckoBinaries flavor dimension; and
b) figure out a way to do the right thing during `assemble-app` in |mach build mobile/android/base|

For the latter, we have many tools at our disposal.  Off the top:

- command line parameters or environment variables
- taskgraph inspection
- ensuring that we only build mobile/android/base (or at least, an APK) after the native libraries have been built

All of this will make tickets like Bug 1418464 (which got closed for a subset of functionality) and Bug 1500573 more feasible.

Comment 1

[Jan Henning [:JanH]]

(In reply to Nick Alexander :nalexander [he/him] from comment #0)
> minApi is only used to
> opt-in to some developer features, and if
> https://developer.android.com/studio/build/optimize-your-
> build#create_dev_variant is to be believed, it's not necessary when
> deploying to a device from within Android Studio.  Android Studio is the
> only developer environment we really care about, so I think minApi can be
> removed now too.

The minApi21 fudge also has the drawbacks that locally in Android Studio you don't get warnings when using an API that was introduced between our real minApi (16) and 21.

Comment 2

[Nick Alexander :nalexander [he/him]]

We're down to just `with/withoutGeckoBinaries`.  I wonder if we should make `withoutGeckoBinaries` a "build type" rather than a product flavor?  Over in github.com/mozilla/application-services I'm doing some AAR packaging that needs to select Android jniLibs in somewhat similar ways and I'm using a build type; it seems to be fine.

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Nick Alexander :nalexander [he/him] from comment #2)
> We're down to just `with/withoutGeckoBinaries`.  I wonder if we should make
> `withoutGeckoBinaries` a "build type" rather than a product flavor?  Over in
> github.com/mozilla/application-services I'm doing some AAR packaging that
> needs to select Android jniLibs in somewhat similar ways and I'm using a
> build type; it seems to be fine.

I remembered (in the shower?) that only one build type can produce a debug APK.  Or that was true at one time in the past.