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.
Sources and further reading
Reference review: 22 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.



