[breakdown]Add feature flags

[jenn-chaulk]

From focus-android created by liuche : mozilla-mobile/focus-android#1515

We want to add the ability to turn on/off features based on feature flags so that we can 1) incrementally land features that may not be complete 2) allow predictable feature releases

[liuche]

@pocmo I started the breakdown in the description of #1515, but I need to look into if we need to have a preprocessed "constants" file of feature flags that can be built from a config file, or if there's some gradle-flavor-y way to do it (for different builds, like dev, QA, l10n, dot-release, release, etc) so those can be automated.

I'll probably think on this some more but feel free to pick it up if you want! I'll unassign myself for now and pass it to you.

[pocmo]

Some interesting articles about feature flags:

• https://martinfowler.com/articles/feature-toggles.html
• https://martinfowler.com/bliki/FeatureToggle.html

Requirements

• We want to land (partial) features without them showing up in release versions
• We want to take screenshots of (some) of the (partial) features so that the L10N teams can verify translations.
• We want to run (ui) tests for (some) of the (partial) features in automation so that we can keep our code quality and avoid regressions.
• We want to enable (some) of the (partial) features for non-release versions so that QA and other team members can test those features.

Options

From a high-level point of view we can choose between two types of feature flags:

• Runtime flags: Code decides at runtime if a feature is enabled. This is very flexible and the behavior / flags can be changed dynamically.

• Build-time flags: The decision which features are enabled is made at build time and from there on do not change.

(* Technically we could also mix both: Flags are decided at build time but there's an option to override them at runtime).

Possible solutions / Brainstorming

Simple static feature flags

We have some flags for “is this a beta build?” or “is this Klar?” in BuildConfig and AppConstants already. We could use those to build simple feature flag constants:

public class Features {
   private static final boolean BOOKMARKS = AppConstants.IsBetaBuild()
}

Switchboard only

We are going to enable/disable features via Switchboard for experiments. We could decide to not have separate feature flags but instead move every new feature (at least the ones we want to hold back) behind switchboard flags. Via Switchboard we have fine-grained controls to specify who is able to use a feature.

Gradle based flags

Gradle allows us to add additional static fields to the BuildConfig class (That's how we create a constant for the Adjust token for example). We could use this to create build time feature flags that can be enabled/disabled via various means:

• Define them in the build files (or separate ones) for specific build types and flavors
• Read them from the gradle.properties file
• Make them configurable via the command line: ./gradlew assembleFocusWebviewDebug -Pfeatures=bookmarks,cookies

Third-party libraries

There are some libraries that provide such functionality:

• https://github.com/mmarcon/android-flaggr
• https://github.com/s0h4m/toggle
• https://featureflags.io/mobile-feature-flags/

---

For now we do not have very complex requirements. I think I would start with a very simple implementation first: static flags. We can cover most of our use cases for now by limiting features to the debug version. This version is only used by developers and for screenshots and ui tests. If we want to distribute them internally we can limit it to the beta builds only (-> The beta build is only distributed internally via buddybuild. The beta on Google Play is a release version!). Right now I do not see the need for complex configuration files where we will have various permutations of features enabled for different developers/users.

If we need more complex rules soon then using Switchboard for feature flags would make sense - as we are going to add it anyways. Using a specific configuration in automation without needing to talk to our servers for downloading the experiment configuration will need some more thought though.

[pocmo]

@liuche What do you think? Are there things I missed?

[mcomella]

To add some of my intuition (which I mentioned in the Android meeting):

• We could also use this for A/B testing and backing out bad, new features
• Firefox iOS has an implementation
• It'd be great to do something simple so it’s easier to change later, when the requirements change

[pocmo]

In the engineering meeting we decided to use simple static flags for now. Later we might want to use Switchboard or mix both behind a nice interface. At this time no work is needed - so we decided to close this issue.