Register the actual Android app
Follow the Flutter App Check guide and confirm the Firebase app, package identity and intended Android provider. Debug, locally signed release and Play-delivered builds may have different signing identities.
App Check and Firebase Authentication serve different roles. App Check contributes app/device authenticity signals; Authentication identifies a user. Backend authorization still decides what that user may access.
Initialize before protected requests
Ensure Firebase initialization and App Check activation happen in the documented order before the app starts requests to enforced products. An early repository call can otherwise race ahead of provider setup.
Keep platform selection explicit. An Android Play Integrity setup does not automatically configure the corresponding Apple or web provider.
Test the real distribution paths
| Build path | Appropriate check |
|---|---|
| Emulator/development | Controlled debug provider setup |
| Play internal testing | Real provider and distributed signing identity |
| Production release | Provider success, metrics and supported devices |
| Alternate distribution | Provider configuration and eligibility for that channel |
Do not assume a sideloaded test behaves exactly like a Play-delivered build.
Observe before enforcing
The App Check overview explains product support and limitations. Review request metrics and legitimate-client failures before enabling enforcement for each protected service.
Test older supported app versions as well. Enforcement can block real users whose installed version has not integrated App Check yet.
Keep debug access out of production
Debug tokens are sensitive development credentials. Store them outside public source and logs, revoke unnecessary registrations and verify that the release uses the intended provider.
APKLint's Firebase Config Scanner can help inspect packaged configuration, but it cannot validate a live attestation result or see enforcement settings. The acceptance test is a legitimate request accepted through the real release path, plus a controlled invalid request rejected by the protected backend.
Put protected repositories behind initialization
For a Flutter notes app, define startup as an explicit sequence: initialize Flutter bindings, initialize the intended Firebase app, activate App Check using the selected platform provider, and only then allow repositories to start protected requests. Follow the Flutter App Check integration for the API supported by the installed plugin version. A widget that activates the provider after a repository has already started cannot reliably protect that first request.
Represent initialization failure in application state. Show a recoverable loading or unavailable view and avoid constructing a request loop that repeatedly runs every time the widget rebuilds. Keep a single initialization owner rather than activating competing provider configurations from several screens.
Test a cold start through the delivered build
Install the actual test-track artifact, stop the app process and start it with synthetic account data. Capture the order of initialization and the first protected request through safe diagnostic events. Verify that the request reaches the intended Firebase project with the production provider path. Repeat with an offline start and a later network recovery so the retry path is observed too.
Check any background entry point separately. A foreground startup sequence is not evidence that a background isolate or handler initializes the services it uses. Follow the supported plugin and background-execution model for the feature, and keep its request timing in the test record. Do not copy an initialization snippet into every callback without understanding whether that callback has an independent lifecycle.
For rollout, compare supported old app versions and each distribution channel before enabling enforcement on a product. Use the provider's documented eligibility settings for the actual channel rather than assuming a locally installed APK behaves like a Play-delivered release. Finally, send an authorized request for another test user's private resource with a valid app token and confirm that user authorization still rejects it. That demonstrates the separate responsibilities of app attestation and resource access. Keep raw attestation and user tokens out of logs while preserving enough decision categories to diagnose startup, provider and authorization failures.
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
