Register the app you will build
Follow the Android setup guide. Read the application ID from the selected variant, including any debug or flavor suffix. A production package and a staging package can require separate app registrations.
Download the configuration for that registration and place it where the Google services plugin expects it for the module or variant. Do not overwrite production configuration with a development file merely to make a local sync succeed.
Keep the build layers separate
| Configuration | Role |
|---|---|
| Google services Gradle plugin | Processes app configuration during the build |
| Firebase BoM | Aligns supported Firebase Android library versions |
| Product dependency | Adds the actual Firebase product SDK |
| Firebase console settings | Enables and configures backend products |
A BoM alone does not add Authentication, Crashlytics or Firestore. Conversely, installing a product SDK does not automatically configure its backend access rules.
Add only the products you use
A dependency fragment can use a pinned BoM:
implementation(platform("com.google.firebase:firebase-bom:34.19.0"))
implementation("com.google.firebase:firebase-auth")
The BoM version is the release listed on 22 September 2026 in the official release notes. Recheck compatibility before a later upgrade. This fragment does not show the complete plugin or repository configuration.
Verify identity through one real operation
Build the intended variant and perform a controlled operation for the enabled product. Confirm the event or test user appears in the expected Firebase project and app, not simply that initialization returned without an exception.
For sign-in, verify the distributed signing certificate. For database access, test both an allowed request and a denied request under the intended authentication state.
Inspect configuration without mistaking it for security
APKLint's Firebase Config Scanner can help locate configuration and identify mismatches. It cannot inspect your private console settings or prove that database rules are restrictive. Keep setup verification, authorization testing and App Check configuration as separate release checks.
Verify a staging registration from artifact to backend
For an illustrative notes application, register com.example.notes.staging in a development Firebase project and keep the production application identity separate. Build the staging variant and inspect its final application ID. Then check that the configuration selected by the Google services plugin names the intended Firebase project and Android app. The Firebase Android setup guide explains registration and configuration processing.
Choose one enabled product for the initial verification. For Authentication, use a synthetic test account and confirm that it appears in the expected development project. For a database, write a small test record only after defining restrictive test rules, then verify it through an authorized read. Do not open the entire database to public writes to simplify this first check.
Classify setup failures before changing configuration
A missing configuration resource, a package-name mismatch, a disabled sign-in provider and a denied database request are different failures. Capture the exact error and the operation that produced it. An initialized default Firebase app does not imply that every backend product is enabled or that the current user has permission to access data. Keep initialization status separate from the product request result in development diagnostics.
If a Play-delivered test build fails while a locally signed build works, compare the distributed signing certificate and the provider's registration requirements. Re-downloading a JSON file without checking the relevant identity can leave the root cause untouched. Avoid logging user tokens or privileged credentials while collecting configuration evidence.
Finally, build from the committed configuration in CI and repeat the controlled product operation. Include a deliberately denied request, such as a second test user attempting to read the first user's private note. This verifies an access boundary rather than merely connectivity. Record the variant, application ID, Firebase project and tested product with the release evidence. Add further products one at a time so their rules, consent behavior and environment selection remain independently reviewable instead of being inferred from the first successful Firebase initialization.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
