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
| Server check | Purpose |
|---|---|
| Token verification | Establish provider-authenticated evidence |
| Expected app identity | Associate evidence with your app |
| Request binding | Associate evidence with this action |
| User authorization | Check access to the resource |
| Idempotency/business rules | Prevent duplicate or invalid operations |
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.
Specify the exact bytes covered by the request hash
For an illustrative test transaction, the client and server can agree on an ordered JSON array containing an operation label, a server-issued context identifier, currency and an integer minor-unit amount. The following is one application's proposed representation, not a format imposed by Play Integrity:
["reserve","test-context-42","USD",1250]Encode that exact compact representation as UTF-8 with no added newline before hashing. In this example, use SHA-256 and lowercase hexadecimal output. The expected digest is fdd234b8a077635056585c939e4d50ba48fd2f4fed0e44d807593983960c4bc2. Validate the field types and allowed values first. An amount of integer 1250 and the string "1250" produce different bytes, and an uncontrolled locale-formatted decimal can differ between platforms. The server must derive the expected fields from the operation it is authorizing.
The standard-request guidance explains content binding through requestHash. Use the documented digest representation consistently. Do not accept a client-supplied hash as the server's expected value, because doing so skips the independent comparison that binds evidence to the intended action.
Change one protected field per test
Compute the agreed digest for the example, then change the amount to 1251, the currency to EUR and the context identifier to another test context in separate cases. Each representation should have a different digest. These local checks validate deterministic serialization and hashing; they do not generate or verify a real Play Integrity token.
In the actual test integration, present verified evidence for one representation alongside altered action data and confirm refusal before the protected operation. Also test an unauthorized account using otherwise correctly bound data. Content binding does not decide ownership or eligibility.
Give legitimate retries their own operation identity. If the first response is lost after the server completes the action, recovery should find the existing outcome rather than perform the action twice. Keep this idempotency rule distinct from the integrity provider's replay protections.
Version the representation when its meaning changes. A later client adding a field should not silently disagree with an older server about which fields are protected. Test the supported version combinations and reject ambiguous or unsupported encodings with a clear, non-sensitive error category.
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
