Play Integrity: Device Integrity vs Account Integrity — What Each Signal Means

Google's Play Protect system uses two types of checks to determine whether an app is trustworthy: device integrity and account integrity. These signals are presented separately in the Play Integrity verdict, which can be confusing for developers trying to balance security with a good user experience. This article explains the differences between device and account integrity labels, how to use them together to create risk tiers, and best practices for handling these tiers without harming the user experience.

Device integrity labels describe the physical characteristics of the device running the app. There are three relevant labels:

1. MEETS_BASIC_INTEGRITY: The device passes basic checks but can't prove much more. This includes emulators and many custom ROMs.

2. MEETS_DEVICE_INTEGRITY: The device is a genuine, Play Protect-certified device that has passed Google's device checks.

3. MEETS_STRONG_INTEGRITY: The device has hardware-backed attestation, including verified boot, locked bootloader, and hardware key attestation. This is the strongest signal, but not all legitimate devices can achieve this level of security.

Account integrity labels focus on the relationship between the app and the user's Google account. There are three relevant labels:

1. LICENSED: The account legally acquired the app through Play (installation, purchase, or valid entitlement).

2. UNLICENSED: The account has no Play entitlement for the app, which could be due to piracy, sideloading, testing on an unmanaged account, or enterprise distribution.

3. UNEVALUATED: Play couldn't evaluate the licensing at the time (transient state, account issues, or Play services problems). This should be treated as an unknown, not a guilty verdict.

To create a more nuanced approach to security, developers should combine these signals into risk tiers rather than using a simple AND combination. The suggested tiers are:

1. Tier 0 - Trusted: Both device integrity and account integrity are satisfied (MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY, and LICENSED). This represents the ideal scenario and grants full access to all features.

2. Tier 1 - Caution: Basic device integrity or an unknown account integrity, but the app is recognized. Normal use is allowed, but high-value actions like purchases, payouts, or account changes require additional verification (such as email OTP or re-authentication).

3. Tier 2 - Restricted: The app is unlicensed, or there is no device integrity label at all. Access is limited to read-only or demo mode. For paid apps, this should be a prompt to acquire the app legally from Google Play, rather than a strict block.

4. Tier 3 - Hostile: The app is tampered or repackaged, regardless of other signals. Sensitive actions should be blocked for this category.

When implementing these tiers, it's crucial to avoid over-relying on device integrity labels alone. The Play Integrity system already incorporates many indicators of rooted or emulated devices, so relying solely on client-side checks can lead to false positives and a poor user experience. Instead, use the Play Integrity labels as the primary source of truth and supplement with client-side telemetry if necessary.

Proper user communication is essential when restricting access based on these signals. Instead of generic error messages, provide clear explanations and guidance for each tier. For example:

"Sorry, we couldn't verify this installation. To access all features, please install the app from Google Play. If you need help, click here to contact support."

Always log the exact Play Integrity labels encountered during the verification process, so support teams can diagnose and resolve any issues. This not only improves the user experience but also provides valuable data for debugging and improving the verification process.