Choose the request flow intentionally
The Play Integrity overview describes available approaches. The standard-request guide explains preparation and request binding for that flow.
Choose based on the protected action, latency and supported behavior. Do not mix code from standard and classic request tutorials without understanding their different APIs and replay considerations.
Keep protected decisions on the server
The app sends the token and relevant action context to your backend. The server validates and interprets the response, then decides whether the requested operation is allowed.
An app-side “passed” flag is not trustworthy evidence. Neither is a JSON payload merely decoded by the client.
Read the verdict by component
The verdict documentation distinguishes app, account and device-related information and optional signals. Missing or unevaluated fields need explicit handling.
| Outcome type | Design question |
|---|---|
| Expected app identity | Does package/certificate match this release? |
| Device signals | Which level is required for this action? |
| Account/licensing context | Does this distribution path support the assumption? |
| Provider or request error | Retry, remediate or restrict which operation? |
Avoid a universal block rule
A policy suitable for a valuable server transaction may be too strict for a public help page. Measure legitimate-user impact before enforcing new restrictions broadly.
Use bounded retries and clear user-facing recovery where appropriate. Never compensate for integration errors by accepting arbitrary client tokens.
Test the distributed build
Exercise the Play-installed test artifact and relevant alternative distribution paths. Verify both successful and deliberately invalid requests on the backend.
APKLint can help compare package and certificate metadata, but its Firebase Config Scanner is not a live Play Integrity verifier. Keep actual verified verdict samples, redacted of credentials, and the server decision policy with the release documentation.
Trace one action through all four integration stages
Choose a synthetic protected action, such as reserving a test item. Record provider preparation, token acquisition, backend verification and the final reservation decision as distinct stages. Give the action a correlation identifier that does not contain a credential. This makes a setup failure distinguishable from a verified request that the business rules correctly refuse.
Follow the standard-request contract when that is the selected flow. Keep the request representation stable between the client and backend. A token for a different item should not be accepted merely because both requests came from a recognized application.
Alter the action after obtaining evidence
In the authorized test environment, obtain evidence for reservation A, then send it alongside altered reservation B data. Confirm that the backend rejects the binding mismatch before creating a reservation. Repeat with the correct data and an account that lacks permission for the item. That case should fail the application's authorization rule independently of integrity evaluation.
Test a network interruption after the server may have accepted the reservation. The client cannot infer that no reservation exists merely because it did not receive the response. Use the operation's own idempotency and reconciliation design to avoid creating a second reservation during recovery. Integrity evidence is not a replacement for a transaction identity.
Keep the application's retry behavior bounded. Show whether the operation is pending, rejected or completed and provide the appropriate recovery action. A disabled button that remains indefinitely after a provider error is a product defect even when the backend's security decision is correct.
Compare the observed outcomes with the verdict definitions for the configured app. Preserve version and distribution context with the test record. A debug-installed artifact can differ from the intended Play-installed release, so label that evidence accurately instead of treating either installation path as interchangeable.
Finally, confirm that the protected server endpoint enforces the same checks when called without the app's normal UI. The backend should require its documented evidence and account authorization, regardless of whether a client displays an integrity success badge.
Sources and further reading
- Android Developers: Play Integrity API overview
- Android Developers: Standard integrity requests
- Android Developers: Integrity verdicts
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
