Introduction

When an Android app uses product flavors, each flavor can have its own google-services.json. The standard setup is to place a different file under the matching source-set directory so the Google Services Gradle plugin picks the correct configuration for each build variant.

Put the File in the Matching Flavor Directory

Suppose you have dev and prod flavors. The common layout is:

1app/
2  src/
3    dev/
4      google-services.json
5    prod/
6      google-services.json

Then define the flavors in build.gradle:

1android {
2    flavorDimensions "environment"
3
4    productFlavors {
5        dev {
6            dimension "environment"
7            applicationIdSuffix ".dev"
8        }
9        prod {
10            dimension "environment"
11        }
12    }
13}

When you build the dev variant, the plugin uses src/dev/google-services.json. When you build prod, it uses the production file.

Make Sure the Package Names Match

Each google-services.json must match the application ID of the flavor it serves. If dev adds an applicationIdSuffix such as .dev, the Firebase or Google project for that flavor must register the package name with the suffix as well.

This is where many setups fail. The file may be in the correct folder, but if the JSON contains a client entry for the wrong package name, the build or runtime behavior will still be wrong.

Support Build Types and More Complex Variants

You can go more specific if needed. For example, if a debug variant needs a different config than release, you can place files deeper in the source-set hierarchy:

app/src/devDebug/google-services.json
app/src/devRelease/google-services.json

Use that only when flavor-level separation is not enough. Most projects are easier to maintain with one file per flavor.

Verify What the Build Is Picking Up

After syncing the project, build a specific variant:

./gradlew :app:assembleDevDebug

If the plugin reports package-name mismatches or missing configuration, check:

• flavor directory name
• application ID for that variant
• package name inside the JSON file

The folder structure and the JSON content have to agree with the variant being built.

Keep Environments Separate on Purpose

Using different google-services.json files is not just a build trick. It is how you keep development analytics, push messaging, and Firebase resources isolated from production. That separation makes testing safer and keeps operational data cleaner.

Keep the Plugin Configuration Boring

In most projects, the only Gradle requirement beyond the flavor setup is applying the Google Services plugin in the app module. Avoid clever custom copy tasks unless the standard source-set layout truly cannot express your variant structure.

The less custom logic you add around configuration selection, the easier it is for future developers to understand which Google project each build variant is using.

Common Pitfalls

• Placing all google-services.json files in the app root instead of the matching flavor directories.
• Forgetting that applicationIdSuffix changes the package name the JSON file must match.
• Mixing development and production Firebase projects accidentally because the wrong file is selected.
• Creating overly specific source-set layouts when simple flavor-level files would be enough.
• Assuming a successful Gradle sync proves the right file was chosen. Always verify the actual variant configuration.

Summary

• Put each google-services.json under the source-set directory for the matching flavor or variant.
• Ensure the package name inside the JSON matches the final application ID of that build.
• Use flavor-specific files to keep development and production services isolated.
• Add build-type-specific files only when flavor separation is not sufficient.
• When builds fail, check directory names, application IDs, and JSON client entries together.