Play Integrity Standard Requests: Bind Verdicts to Server-Side Actions

Prepare according to the documented lifecycle

The standard-request guide describes provider preparation and token requests. Handle preparation errors and token-provider lifecycle explicitly rather than retrying indefinitely on the UI thread.

Use the project's correct Cloud configuration and the real distributed package identity.

Define a stable request representation

Choose the action fields that must be protected from substitution, such as an operation type and server-recognized transaction context. Create a deterministic representation before calculating the documented request binding value.

Do not include raw secrets or unnecessary personal data merely because the field will be hashed. The server must independently reconstruct or verify the intended binding, not trust a client-provided hash alone.

Verify before performing the operation

The verdict reference explains request details and signal fields. Integrity evidence does not replace the other checks.

Test tampering and retries

Submit a valid token with altered action data and verify rejection under your binding design. Also test an ordinary client retry so legitimate recovery does not accidentally duplicate a transaction.

Keep raw tokens out of logs. Record redacted failure categories and server transaction identifiers appropriate to your privacy model.

Roll out proportionately

Start with measurement, then enforce the policy for the intended action. Provider errors and unsupported environments should have deliberate handling rather than a silent blanket bypass.

APKLint can help inspect package and certificate metadata used in configuration. It does not generate or verify standard-request tokens, so validate the client/server protocol with actual service responses before relying on it for valuable operations.