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

Question

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?

Solution 1

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.

Solution 2

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()
  .setProjectId("<project_id>")
  .setApplicationId("<mobilesdk_app_id>")
  .setApiKey("<current_key>")
  .build();
FirebaseApp.initializeApp(this, options);

Comments

[ZakTaccardi]

note, I went with multiple package names within the same app approach

[CodyMace]

I didn't realize that every time you add a new "app" in other words a "staging" or "debug" version, it creates a json file for you with all of the apps together.

[Raul Pinto]

Ian Barber: Please mention @CodyMace's comment in you answer. It's significant information.

[Nico]

If you go with the first option, using 2 app in the same console, they both are going to share the same DB right?

[Nico]

@IanBarber And there is no way to share the same auth and settings (rules, etc.) between two projects?

[Ian Barber]

Touched on a little bit in firebase.googleblog.com/2016/12/… but largely no - though if you use the firebase CLI to upload rules you could use that to push identical rules to both projects.

[Choletski]

How to use multiple apps in the same project if each build flavor has different package name and you can't create one json file for all of them?

[CoDe]

If using one project, the same google-services.json will work for all the varieties. is not working. I see multiple son file available in console to download. Any suggestion how to minimise that, @IanBarber ?

[Chris McCabe]

This is unnecessary, you can just put the google-services.json in flavor folders. See here: stackoverflow.com/questions/30772201/…