Play Integrity verdict semantics

1. What the API returns

A Play Integrity API call returns an integrityToken whose decoded payload contains four fields that the relying party can act on [1, 2]:

• deviceIntegrity — an object whose deviceRecognitionVerdict array carries the verdict labels describing the device’s integrity state. Possible values: MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY, MEETS_STRONG_INTEGRITY, and an optional MEETS_VIRTUAL_INTEGRITY for emulator scenarios.
• appIntegrity — declares whether the calling APK matches the Play-distributed signature: PLAY_RECOGNIZED, UNRECOGNIZED_VERSION, or UNEVALUATED.
• accountDetails — declares whether the calling user has a Play licence for the app: LICENSED, UNLICENSED, or UNEVALUATED.
• requestDetails — echo of the request hash and timestamp, scoped to the calling package and the operator-supplied request hash.

The token is signed with a key Google publishes. The relying party verifies the signature, checks the request hash matches the request they originated, and only then trusts the payload.

2. What each device-integrity verdict requires

The three primary device-integrity tiers describe escalating demonstrations [2]:

• MEETS_BASIC_INTEGRITY — the app is running on an Android device that is not in a blatantly compromised state. Roughly: the device is not obviously a stripped-down emulator, the binary is not known-malicious, and basic OS hygiene applies. Many emulators and lightly modified devices still meet this bar.
• MEETS_DEVICE_INTEGRITY — the device profile matches a Google Play-certified device profile, runs a verified boot, and passes Compatibility Test Suite checks. This is the modal verdict on a healthy production user-base.
• MEETS_STRONG_INTEGRITY — the verdict is recent and was evaluated with a hardware-backed key chain. The device must have a trusted execution environment or a StrongBox-class keystore, must be running on a recent security patch level, and must be Play Protect certified.

A device-integrity result is a list: a STRONG-meeting device also returns DEVICE and BASIC. An operator looks for the strongest verdict that is present and decides accordingly.

3. Freshness, quota, and the operator’s policy

Google does not publish a fixed expiry on a verdict. The documentation [1] recommends generating a fresh token close to the high-value action, warns against caching tokens for reuse, and notes that token freshness is the relying party’s policy decision.

Two practical constraints shape that policy:

• Quota. Standard requests have an app-wide daily budget; classic requests are capped lower [3]. Calling Play Integrity on every event is not feasible at production scale; calling it too rarely creates large unobserved gaps.
• Latency. A standard request typically completes in hundreds of milliseconds, with cached tokens turning over faster on subsequent calls. A classic request — the slower, one-shot variant intended for sensitive flows — takes longer and consumes more quota.
• Request binding. Standard requests bind via requestHash — an operator-constructed hash the signed token echoes back. Classic requests bind via nonce, matching the field SafetyNet originally used. The two fields serve the same purpose; the name change reflects the API’s redesign.

The operator chooses where on this curve to sit, and the choice appears in the operator’s risk-tier policy: high-value flows demand fresh STRONG verdicts; low-value flows accept a cached DEVICE verdict from the same session.

4. What Play Integrity does not claim

Play Integrity is a checkpoint. It speaks about the device at the moment of the call. It does not, by design, do the following — and the documentation [2] is explicit about each:

• It does not assert continuous device trust between calls. The verdict is point-in-time; what runs in the inter-call interval is described in the the-play-integrity-gap article in the prior theme.
• It does not bind a verdict to a transaction body. The request hash is operator-supplied and scoped to the calling package; it is the operator’s responsibility to construct a hash that meaningfully covers the action they want to protect.
• It does not replace credential authentication. Play Integrity is orthogonal to FIDO2, EMV, or PSD2 SCA. It runs alongside those mechanisms, not in place of them.

These are not gaps; they are the boundaries the API explicitly draws. Operators that take the boundaries at face value, and build the layer above accordingly, get the most value out of the checkpoint.

Scoping caveat: Play Integrity requires Google Mobile Services. It does not run on AOSP-only devices, on Huawei HMS handsets, or in markets / custom-ROM contexts where GMS is absent. Operators serving non-GMS markets need a different attestation surface (and EEI is operative on those devices regardless of GMS).

Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — is the layer that signs the inter-call interval Play Integrity deliberately does not.

5. Cross-references

• Sibling articles in this theme: app-attest-and-device-check, safetynet-legacy (Play Integrity is the replacement for the deprecated SafetyNet Attestation API [4]), hardware-attestation
• Theme 1: the-play-integrity-gap
• Architecture: /architecture/runtime-coherence
• Comparison: /eei-vs-attestation

6. External references

[1] Google. Play Integrity API — Overview. developer.android.com/google/play/integrity/overview. Cited 2025-10-30.

[2] Google. Play Integrity API — Verdicts and remediation. developer.android.com/google/play/integrity/verdicts-and-remediation. Cited 2025-10-30.

[3] Google. Play Integrity API — Standard vs Classic requests. developer.android.com/google/play/integrity/standard. Cited 2025-10-30.

[4] Google. SafetyNet Attestation API deprecation timeline. developer.android.com/training/safetynet/deprecation-timeline. Cited 2025-10-30.