Play Integrity verdict freshness and the inter-call gap

1. What a Play Integrity verdict establishes

A Play Integrity API call returns an integrityToken whose payload contains a deviceIntegrity object carrying a deviceRecognitionVerdict array — values drawn from MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY, and MEETS_STRONG_INTEGRITY — and an appIntegrity object carrying an appRecognitionVerdict (PLAY_RECOGNIZED, UNRECOGNIZED_VERSION, UNEVALUATED) describing whether the calling APK matches the Play-distributed signature. Google’s own documentation describes the verdict as a signal about the device “at the time the integrity token was generated” [1]. The verdict is signed by Google and verifiable server-side; it is what the operator’s backend treats as authoritative.

The verdict speaks about that moment. It does not speak about moments before, after, or between.

2. The freshness window

Play Integrity does not declare a numeric expiry on the verdict itself. Google recommends generating a fresh token close to the “high-value action” the operator wants to protect, and warns against caching tokens for reuse [1]. In practice, operators define their own freshness window: a configured number of minutes within which a prior verdict is accepted as still authoritative.

The freshness window is therefore a policy decision on the operator’s side, not a property of Play Integrity. It exists because calling the API on every event would burn the project’s quota and add latency to user-facing flows. The standard request flow is designed for higher-volume calls with on-device token caching; the classic flow [3] is designed for one-shot, higher- value operations with a per-app daily quota. Operators trade verdict-freshness against quota and latency on whichever flow they have selected.

Scoping caveat: Play Integrity requires Google Mobile Services. It does not run on AOSP-only or non-GMS Android distributions (Huawei HMS, certain regulated markets, custom ROMs without GMS). Operators serving non-GMS markets need a different attestation surface or accept that Play Integrity is not available on those devices.

3. What runs in the inter-call interval

Between two successive integrityToken() calls, the device executes a sequence of events that are part of the transaction flow but are not visible to Play Integrity. Typical events on a payment flow:

• the user supplies a credential — passcode, biometric prompt, unlock gesture
• the application assembles the transaction payload (amount, beneficiary, idempotency key)
• the device may swap network: cellular ↔ Wi-Fi, primary SIM ↔ secondary, captive-portal interception
• a retry handler re-emits a previous request after a partial failure
• the application restarts after a process death and resumes from persisted state

Each of these events is a runtime occurrence with security implications. None is reported to Play Integrity. The next call will report device state at its moment of invocation; the trajectory between the two moments is not part of the report.

4. Operational implications

Two implications follow.

The first is a policy choice the operator must make. Calling Play Integrity often costs quota, costs latency on every protected event, and still does not produce a continuous verdict — it produces a denser sequence of point-in-time verdicts with shorter gaps between them. The gaps shrink; they do not close. The operator chooses where on this trade-off curve to sit.

The second is what the gap actually contains. The events listed in §3 are observable by mechanisms that operate inside the runtime — process state, syscall surface, IPC traffic, framework callbacks — and that produce signed evidence at each significant moment. Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — is not a substitute for Play Integrity; it is the layer that covers the interval Play Integrity does not observe. The trust basis declared by Play Integrity at the verdict moment is carried forward in every subsequent signed event until the next verdict is requested. This is the relationship documented at /architecture/runtime-coherence and shown in the bookend diagram on /eei-vs-attestation.

5. Cross-references

• Sibling articles in this theme: the-fido2-submission-gap, the-emv-execution-gap, the-behavioural-session-gap
• Architecture: /architecture/runtime-coherence, /architecture/threat-model
• Comparison: /eei-vs-attestation
• Glossary: /glossary — Runtime Coherence, Evidence Token, Trusted Runtime Primitive

6. External references

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

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

[3] Google. Play Integrity API — Classic requests. developer.android.com/google/play/integrity/classic. Cited 2025-09-12.