Follow the setup chain
Use the official setup guide for the current dependency and project requirements. Pin the documented version appropriate to your integration rather than using an unbounded dynamic selector.
Check repository configuration and resolve the library through its supported distribution source. A dependency resolution failure is a build problem, not a failed device-integrity verdict.
Separate four identities
| Identity | Why it matters |
|---|---|
| Android package | Identifies the application |
| Signing certificate | Identifies the distributed signer |
| Cloud project number | Associates the service configuration |
| Backend verifier identity | Authorizes server-side verification operations |
Do not substitute a Firebase web API key for a Cloud project number or place backend service-account credentials in the APK.
Prepare the selected request flow
The standard-request documentation describes the provider preparation lifecycle and request API. Perform preparation and error handling according to that lifecycle rather than constructing a new expensive setup operation for every UI frame or tap.
Keep protected action data consistent between client and server so the verdict can be evaluated in the intended context.
Diagnose errors at the correct layer
A Gradle sync error, provider initialization error, token acquisition error and server decoding error are different failures. Record the stage and a redacted error code.
Changing the library version randomly is unlikely to fix a wrong project number or certificate registration.
Validate before enforcement
Build and install the actual release-path artifact, acquire evidence and verify it server-side. APKLint's Gradle Dependency Checker can review the declaration and its package tools can inspect identity metadata, but neither establishes that the Cloud service or backend is correctly configured. Require a complete end-to-end verification test before making the result a condition for important user actions.
Diagnose the first failing boundary before changing versions
Start from a clean build of the intended release variant and inspect the resolved dependency graph. Confirm that one supported version of the integrity library is selected and that its minimum requirements fit the application. A declared version and a resolved version can differ when constraints or transitive dependencies participate, so retain the resolution result.
The setup guide covers the library and service configuration. Keep build resolution separate from service enablement, project association and backend verifier access. Successfully compiling a manager class proves that the build can see an API; it does not prove the installed app can complete an integrity request.
Keep project numbers and credentials in different records
For a test environment, record the Android package, expected distributed certificate, Cloud project number and backend environment. Reference the backend's credential configuration by its managed identity or configuration name rather than copying secret material into the Android project. A numeric project identifier is not an API key and cannot replace verifier authorization.
Install the intended test artifact and capture the preparation outcome. If preparation fails, investigate its documented error category before changing unrelated server parsing logic. If token acquisition succeeds but backend verification fails, inspect the backend's configuration and expected project association. This staged approach avoids treating every failure as a dependency problem.
Exercise a deliberately incorrect test configuration in an isolated environment, then restore the intended values. Confirm that the diagnostic record identifies the stage without printing raw tokens or credentials. A support message saying integrity failed is less useful than a precise category such as preparation unavailable or backend verification rejected.
After an upgrade, rebuild the same variant and repeat the end-to-end test rather than stopping at a successful dependency download. Review changes to minimum SDK, API usage and error handling against the version actually selected. Keep the previous working artifact available for a controlled comparison.
Only after that chain works should the team enable the intended enforcement policy for important operations. This sequence makes the dependency change reviewable while keeping the separate question of how to interpret verified results visible.
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
