BASIC vs DEVICE vs STRONG: Play Integrity verdicts explained
What the Play Integrity API is
The Play Integrity API is Google's replacement for SafetyNet Attestation, which was shut down in January 2025. An app asks Google Play services for an integrity token; Google inspects the device, the app binary and the account, and returns a signed verdict that the app's backend can trust. Developers use it to decide whether to allow a login, a payment, a multiplayer session, or nothing at all.
The verdict has several sections, but the one everybody in the rooting community talks about is deviceIntegrity, a set of labels describing how trustworthy the device is.
The three device verdicts
| Label | What it requires | Rough meaning |
|---|---|---|
MEETS_BASIC_INTEGRITY | The device passes basic system integrity checks. It may be uncertified, rooted, or running a custom ROM. | "This is at least an Android device." |
MEETS_DEVICE_INTEGRITY | A Google Play certified device running Google Play services, with hardware-backed signals on Android 13 and newer since Google's 2025 changes. | "This looks like a stock, certified phone." |
MEETS_STRONG_INTEGRITY | Everything above plus hardware-backed proof of boot integrity (verified boot, locked bootloader) and a security update from within the last year. | "The hardware itself vouches for this phone." |
The labels are cumulative: a device with STRONG also has DEVICE and BASIC. A fourth label, MEETS_VIRTUAL_INTEGRITY, exists for approved emulators. An empty list means the device failed everything.
Google has been tightening these definitions. In 2025 it moved the DEVICE verdict on newer Android versions onto hardware-backed signals and formalised the "recent security update" requirement for STRONG. In practice that means STRONG is decided by key attestation: the attestation certificate chain must be rooted at Google, not revoked, and its extension must say verified boot passed with a locked bootloader and an acceptable patch level.
Where rooted devices land
Unlocking the bootloader breaks verified boot, so the hardware truthfully reports an unlocked, unverified device. Left alone, a rooted phone therefore fails DEVICE and STRONG and usually keeps BASIC. The community stack addresses each layer:
- Hiding root (deny list, unmounting, hiding the manager app) protects BASIC and keeps app-side detection quiet.
- Fingerprint spoofing with PlayIntegrityFix or PlayIntegrityFork makes the software side look like a certified build. On older checks this alone reached DEVICE; on Android 13+ with hardware-backed signals it is not enough by itself.
- Attestation spoofing with TrickyStore and a keybox rewrites the certificate chain so the hardware appears to attest a locked, verified device. This is what unlocks DEVICE on newer checks and STRONG everywhere, and it only works while the keybox is not revoked.
Put differently: BASIC is about hiding, DEVICE is about looking certified, STRONG is about a trusted attestation chain. A keybox is the ingredient for the last one.
Which apps check what
Developers choose the level. Most apps that use the API at all accept DEVICE: streaming services, many games, some payment apps. A smaller group insists on STRONG: a number of banks, Google Wallet tap-to-pay, some enterprise and government apps, and anti-cheat systems in competitive games. Play Store's own "device is certified" state relates to DEVICE.
Because the requirement is per app and can change with an update, "which integrity do I need?" has no universal answer. If an app works with DEVICE today and stops after an update, it may have moved to STRONG.
How to check your verdict
- Play Integrity API Checker (or a similar app) calls the real API and shows the three labels. Run it once after changing your setup.
- Key Attestation shows the underlying certificate chain and whether it is trusted or revoked. If STRONG is missing, this app tells you why: revoked keybox, untrusted chain, or unverified boot state in the extension.
- The Play Store settings page shows "Device is certified" or not, which tracks DEVICE.
Do not loop these checks. Every call attests through your keybox and shortens its life; see making a keybox last longer.
Common confusions
- "Green checker, bank still fails." Play Integrity is one input. Apps also look at the app-integrity and account sections of the verdict, run their own root detection, or use a different attestation provider. Fix root hiding first, then re-test.
- "STRONG yesterday, DEVICE today." Your keybox was revoked. Swap it for the newest Strong one in the repository.
- "My keybox is valid until 2040." Certificate expiry is unrelated to revocation. Only Google's status list decides.
- "Old phone, no updates, can it reach STRONG?" Only if the attested security patch level is recent; TrickyStore's
security_patch.txtexists for exactly this. See the setup guide. - "Do I need a keybox for DEVICE?" Increasingly yes on Android 13+, because DEVICE now leans on hardware-backed signals. A software keybox (TrickyStore's built-in one) often suffices for DEVICE; STRONG always needs a real, unrevoked one.
Need a keybox that is valid right now?
The keybox repository lists every published keybox and checks each one against Google's revocation list on every page load. AlwaysStrong fetches the newest one automatically.
Sources and further reading
- Android Developers, Play Integrity API – Integrity verdicts
- Android Developers, Play Integrity API overview
- Android Developers Blog, Making Play Integrity API faster, more resilient, and more private (2025 verdict changes)
- Android Developers, Key attestation
- XDA, How to pass Strong Integrity on Android