We recently [announced](https://android-developers.googleblog.com/2024/12/making-play-integrity-api-faster-resilient-private.html)
that we strengthened the Play Integrity API verdicts to make them faster,
more resilient against attacks, and more private for users along with other
security improvements.

## Summary of changes

You can find a detailed summary of the changes and frequently asked questions
later in this document. The verdict changes in May 2025 were as follows:

| **What** | **What's changed** | **Estimated impact\*** | **Which devices** |
|---|---|---|---|
| **Changes that impact all developers making Play Integrity API requests** ||||
| **Device verdict response: meets-device-integrity** | Required to have a hardware-backed, positive [verified boot](https://source.android.com/docs/security/features/verifiedboot) verdict | Minimal impact because Play Integrity API already uses hardware-backed security signals on Android 13 or later devices (\~0.4%) | Android 13 and later |
| **App integrity response: App recognition verdict** | No change | Minimal impact, this will mirror the change in the device verdict (\~0.4%) | Android 13 and later |
| **Account details response: Play license verdict** | Requesting app must be installed or updated by Google Play | Minor decrease in licensed responses (\~2.5%) | Android 6 and later |
| **Changes that only impact Play Console developers and Play SDK Console developers using optional features** ||||
| **Device verdict response: meets-basic-integrity** | Required to have Android Platform Key Attestation but the boot state can be verified or unverified | Minor decrease in basic responses (\~0.4%) | Android 13 and higher |
| **Device verdict response: meets-strong-integrity** | Required to have a security update in the last year | Decrease in strong responses (\~14.5%) | Android 13 and higher |
| **All optional signals (except device attributes)\*\*** | Requesting app must be installed or updated by Google Play | Decrease in % of responses that include optional signals (\~7%) | Android 13 and higher |

*\*All of the estimated impact percentages mentioned earlier were based on
averages and different apps may have seen smaller or larger changes depending
on their install base.*

*\*\*The optional signals (except device attributes) are:
`meets-basic-integrity`, `meets-strong-integrity`, recent device activity,
device recall (beta), Play Protect status, and app access risk.*

## Frequently asked questions

### Overview

#### What is the Play Integrity API?

The Play Integrity API helps you assess the trustworthiness of user's app's
environment by obtaining information about the device, app, and user, so you can
detect and respond to potential abuse and attacks.

#### What signals does Play Integrity API provide?

The Play Integrity API includes the identity of the requesting app, whether the
requesting app was installed by Google Play, and whether the device is a genuine
and [certified Android device](http://android.com/certified). These
signals are provided by default. You can read these signals on your app's
backend server and decide whether and how your app should respond. Google Play
developers can opt-in to receive additional signals in their Play installs to
see even more information.

#### What is Android Platform Key Attestation?

[Android Platform Key Attestation](https://developer.android.com/privacy-and-security/security-key-attestation)
allows apps to verify the state of the device and obtain a strong signal of
hardware-backed boot integrity. It depends on a key that's provisioned by Google
in the device's hardware-backed keystore. Play Integrity API already uses key
attestation to obtain hardware-backed security signals on some devices and will
now integrate them more deeply on all devices running Android 13 or later.

### Verdict changes

#### What changes were made to the Play Integrity API verdicts on Android 13 or later devices?

Play Integrity API now requires hardware-backed security signals for all
integrity verdicts:

- The `meets-device-integrity` device recognition verdict is an indication that the device the app is running on is a genuine and certified Android device. This verdict will require the device bootloader to be locked and the loaded Android OS to be a certified device manufacturer image.
- The `meets-strong-integrity` device recognition verdict is an indication of a genuine and certified Android device with a recent security update. This verdict will require `meets-device-integrity` and security updates in the last year for all [partitions of the
  device](https://source.android.com/docs/core/architecture/bootloader/version-info-avb), including an Android OS partition patch and a vendor partition patch. This condition might change in the future.
- The `meets-basic-integrity` device recognition verdict is an indication that the check happened on a physical Android-powered device. The device bootloader can be locked or unlocked, and the boot state can be verified or unverified. It may not be certified, in which case Google cannot provide any security, privacy, or app compatibility assurances and cannot guarantee that the device is not acting as a proxy, such as for a virtual instance of Android. This also means that rooted devices are eligible to return `meets-basic-integrity` so long as key attestation is present.

These changes don't impact Play Integrity API on Play Games for PC which will
continue to return `meets-virtual-integrity`.

#### Why were the Play Integrity API verdicts changed on Android 13 or later devices?

Play Integrity API was partially using hardware-backed security
signals on Android 12 and lower. By requiring hardware-backed security on
Android 13 and higher, Play Integrity API verdicts are more resilient against
attackers, more performant for apps, and more private for users. Developers
can expect the following improvements on devices running Android 13 or later:

- Reduction in device signals that need to be collected and evaluated to generate the default verdict on Google servers by \~90%. Optional signals will continue to require additional signals to be collected.
- Improvement in verdict latency by up to 80% for worst-case standard requests and up to 80% for all classic requests to obtain the default verdict. Optional signals can increase the latency.
- Consistent level of reliability and support for all Android form factors with key attestation including mobiles, tablets, foldables, TV, Auto, Wear OS, and ChromeOS.
- A greater differentiation between each device label in the device recognition verdict: `meets-strong-integrity`, `meets-device-integrity`, and `meets-basic-integrity`.

| **Note:** After the new verdicts launched for all developers in May 2025, we expect performance improvements to be seen gradually, while we remove or transition legacy dependencies for all default and optional signals.

The Play Integrity API verdict on Play Games for PC is not being changed and
will be the same on Android 12 and earlier as it is on Android 13 and higher.

#### How can I update my app's backend logic for integrity verdicts to take Android SDK version into account?

If you want to use different logic on your app's backend server based on the
Android SDK version, you can use the new device attributes field in the verdict.
Here's an example of doing this:  

### Kotlin

```kotlin
val deviceIntegrity =
  JSONObject(payload).getJSONObject("deviceIntegrity")
val sdkVersion =
  if (deviceIntegrity.has("deviceAttributes")) {
    deviceIntegrity.getJSONObject("deviceAttributes").getInt("sdkVersion")
  } else {
    0
  }

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}
```

### Java

```java
JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
int sdkVersion =
  deviceIntegrity.has("deviceAttributes")
    ? deviceIntegrity.getJSONArray("deviceAttributes").getInt("sdkVersion")
    : 0;

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}
```

#### How can I use the old `meets-strong-integrity` label definition across all Android SDK versions?

You can achieve this by updating your app's backend logic to use
`meets-strong-integrity` when it's a pre-Android 13 device and
`meets-device-integrity` when it's an Android 13 or later device using the new
device attributes field in the verdict that contains Android SDK version. Here
is an example of doing this:  

### Kotlin

```kotlin
val deviceRecognitionVerdict =
  if (deviceIntegrity.has("deviceRecognitionVerdict")) {
    deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
  } else {
    ""
  }

val deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}
```

### Java

```java
JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
String deviceRecognitionVerdict =
  deviceIntegrity.has("deviceRecognitionVerdict")
    ? deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
    : "";

String deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}
```

Because it's also a hardware-backed signal, the device attributes field is most
reliable on devices running Android 13 and higher.

#### What other verdict changes were made?

We continually invest in making existing signals in Play Integrity API more
reliable and we periodically launch new features to help developers deal with
emerging threats and new use cases. Other verdict improvements that we've made
include:

- **Play licensed response:** In order to return a Play licensed response, Play Integrity API now always requires the requesting app to be installed or updated by Google Play. This fixes some edge cases and makes the response easier to interpret for developers.
- **Optional signals availability:** All optional signals available to developers using Google Play Console or the Play SDK Console (except device attributes) now require the requesting app to be installed, or updated, by Google Play on Android 13 or later. This includes `meets-strong-integrity`, `meets-basic-integrity`, recent device activity, device recall (beta), the app access risk verdict, and the Play Protect verdict. We standardized all other Play Integrity API requests to receive the device check (with the `meets-device-integrity` label only), the installer check, the app integrity check, and device attributes (if enabled).
- **Verdict changes for specific devices:** Play Integrity API is automatically changing device verdicts in more scenarios to protect apps earlier across all Android SDK versions, such as when there is evidence of excessive activity or key compromise. This includes the ability for Play to fallback to other signals to generate temporary device verdicts for users when hardware-backed signals are unavailable. Developers are recommended to use the [in-app Play remediation dialogs](https://developer.android.com/google/play/integrity/remediation) or to point users to the [Play Store app](https://support.google.com/googleplay/answer/7165974) to fix integrity verdict issues. In time, these dialogs will deal with more scenarios and include specific guidance for users telling them what they need to fix based on their specific device or account.

#### How do I report issues with integrity verdicts?

To report issues with responses from Play Integrity API, whether the issue is
with the historical verdicts or the new ones, following the instructions on the
[support page](https://developer.android.com/google/play/integrity/additional-tools#get-support).

### Availability

#### What does Play Integrity API require to work?

Play Integrity API requires that Google Play Store and Google Play services be
installed on a device, this includes Android devices and Google Play Games for
PC. Classic requests require Android 4.4 (API level 19) or later and standard
requests require Android 5.0 (API level 21) or later. On devices running
Android 13 (API level 33) and later, the Play Integrity API will now have the
same level of reliability and support across all Android form factors with key
attestation including mobiles, tablets, foldables, TV, Auto, Wear OS, and
ChromeOS.

#### Why does Play Integrity API have different verdicts for different devices?

Play Integrity API provides multiple device verdicts to accommodate developers
with different use cases and risk tolerances and to make it possible to have a
tiered enforcement strategy. For example, when the app and device is more
trusted, a developer might streamline their user verification steps; whereas,
when a device is unknown, the developer might require additional user
verification before performing protected or sensitive actions. This can be an
effective way to reduce abuse and attacks.

#### What is a certified Android device?

A certified Android device (also known as a Play Protect certified Android
device) is a device running predictable software that has passed hundreds of
Google's compatibility tests, adheres to the Android security and permissions
model, and that shipped with the Google Play Protect suite of anti-malware
features. When Play Integrity API is able to verify that a device is a genuine and certified Android device, it will return the
`meets-device-integrity` response in the device recognition verdict.

#### What is a `meets-basic-integrity` device?

Play Integrity API also returns an optional response in the device verdict,
`meets-basic-integrity`. If a device only returns the `meets-basic-integrity`
verdict without `meets-device-integrity` or `meets-strong-integrity`, it means
the Android OS cannot be verified but key attestation is present. This
indicates that the check happened on a physical Android-powered device, but
Google cannot make assurances about the device's security, privacy, or app
compatibility and cannot guarantee that the device is not acting as a proxy,
such as for a virtual instance of Android. Depending on developers' use cases
and risk tolerances, they can decide how they want their app to run on these
devices.

#### Can any developer use the Play Integrity API?

Yes, any Android developer can make Play Integrity API requests to receive the
default integrity verdicts. Usage is capped at 10K requests per day regardless
of distribution channel. Developers publishing their apps on Google Play in
addition to any other distribution channels can also request to increase their
daily quota.

#### Can any developer use Android Platform Key Attestation?

Yes, any Android developer can use Android Platform Key Attestation to obtain a
key attestation record, which they can verify with the public certificate of
Google's attestation root key. Play Integrity API brings developers the benefits
of key attestation and additional features without all the complexity of having
to integrate with key attestation themselves.

### Enforcement

#### How do developers use the Play Integrity API verdicts?

It's up to developers to decide whether and how to use the Play Integrity API
verdicts. Some developers collect the signals for internal anti-abuse analysis,
while other developers will make decisions about how their app behaves based on
the verdict. For example, developers could decide to require that less trusted
devices perform additional user verification steps while creating an account;
or they could decide that less trusted devices should play together on the same
multiplayer server.

#### Does Play Integrity API block users or devices?

No, the Play Integrity API does not block access to any functionality itself.
It is an optional developer service that provides signals and developers choose
how to act on those signals.

#### What should users do if their device is failing Play Integrity API device checks?

Users can go to the Play Store app on their device, open the Settings menu,
scroll down to About, and then look under Play Protect certification. If there
is something wrong with their device's Play Protect certification, there will be
a button that users can press to try to fix the issue. This will refresh the
device's certification status and provide specific guidance on what needs to be
fixed.