Add a custom detekt rule to blacklist certain properties. This is
immediately useful for making sure that developers do not configure
runtime behavior using the `BuildConfig.DEBUG` property but it is
useful in a wider context.
* Remove "abi" product flavor and introduce "engine" product flavor.
This patch will allow us to build Fenix against GeckoView Nightly and GeckoView Beta by
introducing a new flavor dimension: engine = [geckoNightly, geckoBeta].
In addition to that it adds a "fenix" prefix to the nightly, beta and production flavors
to reduce the ambiguity between fenix beta/nightly and GeckoView beta/nightly.
For now the build types have the following engine variants enabled:
**debug**: geckoNightly, geckoBeta
Both variants enabled for local development and testing.
**forPerformanceTest**: geckoNightly, geckoBeta
Both variants enabled unless the perf team only cares about Nightly (tbd)
**fenixNightlyLegacy**: geckoBeta
Uses GeckoView Beta for now - the same version we ship production builds with (same behavior
as before). This release type will eventualyl be decommissioned once we switch to a separate
Nightly app on Google Play.
**fenixNightly**: geckoBeta
Uses GeckoView Beta for now - the same version we ship production builds with (same behavior
as before). Changing this build to use GeckoView Nightly is currently being discussed.
**fenixBeta**: geckoBeta
Fenix Beta uses GeckoView Beta.
**fenixProduction**
Fenix Production uses GeckoView Beta (69) currently.
* gradle.py/variant.py: Replace "abi" with "engine".
* Disable enableUnitTestBinaryResources until we can switch to Android Gradle plugin 3.5.
* Fenix nightly should use both geckoview nightly and beta
* Updates automation to use apk splitting and support different engine
* greenfield (pure Fenix without anything added)
* firefoxNightly (To replace Firefox Nightly)
* firefoxBeta (To replace Firefox Beta)
* firefoxRelease (To replace Firefox Release)
For now it will be a bit annoying to have all those flavors. But once the transition has been
successfully completed we can start to tear them down again.
Once GeckoView universal builds are available we can get rid of the "abi" dimension.
If this is going to slow down the CI process then I might look into parallelizing the build
or potentially introducing a taskcluster CI setup (if that makes sense).
