Build variants select wrong Firebase projects.
Quick solution:
app/src/staging/google-services.json
When an Android continuous integration pipeline compiles multiple product flavors or build variants, the Google Services Gradle plugin can inadvertently bind production credentials to staging builds or vice versa, causing unexpected data leakage or runtime initialization failures. This issue typically surfaces when developers rely on a single global configuration file or misconfigure directory structures for variant-specific JSON credentials, leading to mismatched client package names during compilation.
How the Plugin Chooses the Matching Client
Understanding the matching mechanism requires examining how the Google Services Gradle plugin processes files during compilation. According to the official documentation on the Google services Gradle plugin and configuration, the plugin reads the package name from your merged manifest and searches the module directories for a matching google-services.json file. If it finds a mismatch between the application ID and the client_info section of the JSON, the build fails or silently binds incorrect analytics and messaging endpoints.
When managing multiple environments, teams often run workflows like Automating Android Ci Workflows With Github to streamline builds, but automated runners require strict separation of environment variables. Treating a successful compile and a live Firebase integration check as different evidence is essential. A clean compile only proves that syntax and dependencies are valid; it does not confirm that the compiled binary communicates with the intended remote project backend.
Where Variant-Specific JSON Files Live
Source sets in the Android Gradle plugin determine where configuration files reside. The build system evaluates source directories in a specific order, falling back to the main source set if a variant-specific file is missing. The supported directory layout mirrors standard Android source sets:
-
app/src/main/google-services.json(fallback for all variants) -
app/src/staging/google-services.json(used exclusively by the staging flavor) -
app/src/production/google-services.json(used exclusively by the production flavor)
As outlined in the guide on Firebase multiple project configuration, separating projects cleanly prevents accidental cross-environment data contamination. Placing files directly in flavor-specific folders ensures that the build engine merges the correct API keys and project numbers without requiring custom shell scripts to copy files into place during CI execution.
Verifying the Intended Project in CI Pipelines
Running automated builds in continuous integration environments introduces the risk of executing tests against incorrect or synthetic configurations. Compile-only checks never masquerade as integration tests. To prove that your test exercised the intended project, inspect the generated build artifacts rather than trusting the build log alone.
Examine the generated values file located in your build output directory, typically found at app/build/generated/res/google-services/{variant}/values/values.xml. This file contains the compiled string resources such as google_app_id and project_id that the application reads at runtime.
Execution Checklist
- Verify that each application ID matches its expected client before initiating tests.
- Inspect generated project resources in the build output directory to confirm environment bindings.
- Ensure compile-only checks are never treated as full integration tests for messaging or authentication.
- Keep untrusted pull-request jobs isolated from production service credentials.
Top comments (1)
picking the wrong Firebase project silently is the worst kind of CI bug.