Play Integrity on Android: Client Request, Server Verdict and Decision

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.

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.