Use it only for controlled development
Follow the Android debug-provider guide for emulator, local or CI workflows that cannot use the normal production provider. Keep development Firebase projects separate where practical.
A debug token registered in a production project deserves the same careful access review as another development exception into that project.
Separate build configurations
| Build | Provider expectation |
|---|---|
| Local development | Explicit controlled debug provider |
| CI integration test | Managed secret and restricted registration |
| Play test release | Intended production provider |
| Public production release | No accidental debug-provider dependency or activation |
The Play Integrity provider setup is the relevant Android production reference when that provider is selected.
Keep tokens out of source and reports
Do not commit tokens to Gradle files, Dart/JavaScript configuration, screenshots or public issue trackers. CI logs can expose them even when the source repository is private.
Use the CI secret store and limit who can register or revoke debug credentials. Revoke tokens that are no longer needed or that may have been exposed.
Test the release separately
A debug build successfully reading Firestore proves only that its configured debug path was accepted. It does not establish production certificate, provider or enforcement correctness.
Install the distributed test release and verify protected requests without relying on a registered debug token.
Audit the exception lifecycle
Record token owner, purpose, environment and revocation trigger. Avoid accumulating permanent anonymous development exceptions.
APKLint's Firebase Config Scanner can identify some configuration clues, but it cannot enumerate registered debug tokens in your private project or prove that all release paths avoid them. Combine package inspection with build-source review and actual provider tests.
Give a CI debug credential a bounded purpose
For an integration-test job that cannot use the production attestation path, create an explicitly approved debug-provider registration in a development project. Associate it with the job owner, environment and revocation condition. Supply the credential through the CI secret mechanism and redact it from command output, screenshots and uploaded test reports. The Android debug-provider documentation describes the supported development and CI workflow.
Keep registration separate from source configuration. The build can select a debug-provider dependency or factory for an appropriate development variant without committing the token itself. Review generated resources and packaged source-derived strings so a secret injected for testing does not accidentally become a release resource. Inspect the release runtime dependency graph as well as the provider initialization code; a development-only convention can otherwise leak through a shared build configuration.
Prove that a release does not rely on the exception
Build the intended release through its normal distribution path and verify protected access using the production provider. Use an environment where the test is not made successful by the development debug credential. Record the package identity, certificate context and provider result without recording the raw token. A debug request accepted by Firebase demonstrates that the exception works, not that production attestation is configured correctly.
Also test revocation of a disposable debug registration in the development environment. After the relevant token lifecycle and refresh behavior, confirm that the revoked credential no longer provides accepted debug access. Do not assume revocation retroactively erases every already issued token immediately; follow the documented lifecycle and inspect the resulting request decisions.
When a developer leaves the project or a CI job is replaced, review the corresponding registration instead of leaving an anonymous permanent exception. If a token appears in a public log, treat it as exposed and revoke it through the authorized project workflow. Keep the incident record limited to the token identifier or purpose and the actions taken. This lifecycle prevents a convenient test setup from becoming an untracked route into protected services while preserving a reproducible way to run legitimate automated tests.
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
