Choose the operation and supported channels
Start with a concrete protected action, such as issuing a premium download or accepting a high-value state change. Decide which integrity signals are relevant to that operation and which distribution channels you support. A product serving devices outside Google Play needs a deliberate policy for those customers.
Keep authentication and authorization independent. An integrity verdict about an app or device does not say that this account owns a particular document or may perform an administrator action. Preserve server-side ownership and role checks for every protected operation.
Use the documented verification flow
Follow the current official integration for the chosen request type, including server decoding or verification and checks against your expected application and request data. Do not accept a client-decoded verdict as authoritative. The server should interpret the verified fields itself.
Design a canonical representation of the operation being protected, then bind the integrity request to it using the mechanism appropriate to the API mode. Changing the account, amount or target object after obtaining a token should fail your application policy. Avoid hashing an ambiguous string whose fields can be reordered or omitted.
Test freshness and retry behavior
Write tests for stale, malformed and mismatched tokens, repeated requests and interrupted transactions. Distinguish protection against replay from legitimate application retries. If an operation can charge a customer or consume credits, idempotency and integrity policy need to agree on how retries behave.
Keep security state updates atomic across backend instances. Record decision categories that operators can inspect without logging raw sensitive payloads. A rollout that silently allows all token failures does not enforce the intended control, while blocking every network timeout may lock out legitimate customers.
Measure a policy rather than a slogan
Define monitored fallback, customer support and recovery for unsupported devices, service disruption and account changes. Start with enough visibility to understand real traffic before applying a strict risk policy. Review current documented quotas and implementation constraints for your actual project rather than embedding guessed limits in code.
Play Integrity can contribute to abuse control for a service. It does not hide the app interface or stop an observer from describing its public behavior. The presence of an integrity SDK alone does not demonstrate that REA cannot rebuild the application.
CloneGuard guides the trust-boundary review and can screen supported release bytes. It does not implement or operate your Play Integrity backend, obtain production verdicts, or validate all supported devices. Keep the backend test results and any unavailable device checks explicit in the release assessment.
Practical checklist
- Define operation, channels and fallback policy.
- Verify verdicts on the server.
- Test request mismatch, freshness and retries.
- Keep account and object permissions independent.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.