The value of Play Integrity comes from binding evidence to the correct Android application and operation, rather than merely obtaining a token. Server verification remains central to the design.
Evaluation approach
The application requests evidence. The backend verifies the result and compares it with the expected application, request and distribution conditions. Verdicts do not replace user authorization. The request type also affects integration behavior.
Application example
For a sensitive operation such as adding a recipient, bind the evidence to that request. Interpreting the result only inside the application and sending a safe label to the server is insufficient.
Limits and considerations
Handle service errors, unevaluated conditions and negative integrity verdicts separately. Assess the needs of distribution outside the store independently.
Designing server verification
Do not reduce a Play Integrity result to one permission field inside the application. The server should assess the expected package and request context, then interpret verdict fields through its own policy. Check official documentation for feature enablement and support requirements.
Observe a new policy against normal traffic before enforcing it for every user. Investigate empty or unevaluated results. Evidence of transaction integrity does not remove account authorization or business-rule checks.
Technical assessment
Distinguish server decision states
A single success flag can confuse operational failures with risky transactions. Adapt this example matrix to the application's business impact.
| Condition | Server behavior | Test evidence |
|---|---|---|
| Expected evidence and correct transaction binding | Continue account and business authorization. | Only the authorized operation completes. |
| Request content mismatch | Do not accept the evidence for this action. | Changed amounts or recipients are rejected. |
| Evidence unavailable | Apply the defined outage policy. | Service errors remain distinct from attack events. |
| Adverse environment result | Restrict or step up according to risk. | Decision and user impact are correlated. |
A client-supplied safe label cannot replace verified platform evidence. Raw tokens need not be logged. Transaction identifiers, policy versions, result classes and limited verification context provide a better starting point for many support cases.
Before enforcement, observe results by device and application version. Understanding unsupported conditions can reduce false blocks. Use observation to improve rules rather than as a reason to disable them indefinitely.
Checks and decisions
- Verify request binding
- Write the failure policy
- Test the actual distribution package
Define evidence freshness separately for registration, sign-in and payment flows.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.