Home » Android » Firebase 2.0 – how to deal with multiple flavors (environments) of an android app?

Firebase 2.0 – how to deal with multiple flavors (environments) of an android app?

Posted by: admin April 23, 2020 Leave a comment


I have multiple flavors of my app. How should I set this up server side? My package names are:

com.example.app (production)
com.example.app.staging (staging)
com.example.app.fake (fake)

Should this be 3 separate projects in the firebase console?

How to&Answers:

Largely it will depend on how you want your project to work. You can set all three up in the same console, or you can set up as two or more different projects. Either option is valid.

Benefits of same project:

  • Share the same billing, quotas, permissions, and services (database, storage, FCM etc).
  • Environment which is the same as production.

Benefits of different projects:

  • No risk of overwriting production data or affecting production users.

If using multiple projects, you can take advantage of the build types support which will allow you to have different google-services.json files for different versions. If using one project, the same google-services.json will work for all the varieties.

Note: as CodyMace says in the comments – remember to re-download the JSON file each time you add an app!

There are things you can do to minimise risks in either case (e.g. have dev/ stage/ prod/ keys in your Database, and have similar structures underneath), but what makes sense for you is largely about tradeoffs.

If you’re just starting out, I would suggest starting with one project while you’re in development, and once you’ve launched consider moving your development environment to a separate project. Staging could go either way.


Note I didn’t fully try this yet, but documenting it here to not lose it until I get to it.

One actually isn’t forced to use the gradle plugin, which enforces you to have a firebase project for all of your flavors and build types.

This is poorly documented, but one can find a hint at the top of the documentation for FirebaseApp and some more at https://firebase.google.com/docs/configure/

Alternatively initializeApp(Context, FirebaseOptions) initializes the default app instance. This method should be invoked from Application. This is also necessary if it is used outside of the application’s main process.

So, fetch the google-services.json as usual and from it take mobilesdk_app_id and current_key (under api_key), that should be all that’s needed for Google Analytics tracking at least. With that information run the following in your app’s Application subclass for the variants where you need it:

FirebaseOptions options = new FirebaseOptions.Builder()
FirebaseApp.initializeApp(this, options);