google-services.json: Package Matching, Build Variants and Safe Handling

Match the selected application ID

Follow the Firebase Android setup guide. The client entry must match the relevant package identity, including flavor or build-type suffixes.

A package mismatch can fail processing or select the wrong environment in a poorly organized multi-app setup. Read the actual variant's application ID rather than guessing from its folder name.

Organize variant configuration explicitly

The Android build and variant guides explain source-set selection. Use supported variant-specific configuration placement where needed instead of a pre-build script that silently copies whichever file was edited last.

Understand what the file does not contain

It is not a complete export of Security Rules, OAuth configuration, App Check enforcement or billing settings. A correct file cannot prove that those backend controls are safe.

Do not add service-account private keys or other server credentials to the file. Client configuration and privileged server credentials have different trust boundaries.

Verify generated behavior

Build the intended variant, inspect its identity and perform a controlled operation against the expected Firebase app. For sign-in, also verify the certificate of the distributed build.

A successful Gradle sync is weaker evidence than a test event or request reaching the correct project.

Plan migrations as release changes

Changing Firebase projects can affect authentication users, data paths, notifications and historical reporting. Treat it as an application/backend migration with compatibility planning, not merely a file replacement.

APKLint's scanner can help inspect packaged Firebase configuration. It cannot make installed apps switch projects or validate private console state; use it to confirm what the artifact actually contains.