What a Play Integrity verdict actually returns, and who it is evidence for

Most discussion of the Play Integrity API turns on one label, and you do not get that label unless you asked for it.

Everything below comes from Google's own pages, read on 3 September 2026: what the API returns, the limits Google publishes, and where all of it points.

The three families

Google structures the response as three separate verdicts: accountDetails, appIntegrity and deviceIntegrity. They answer, respectively, whether the account has a Play licence for the app, whether the binary is the one Google recognises, and what can be said about the device.

Keep them separate in your backend. They fail independently, and a single boolean cannot tell you which one moved.

What the device verdict returns by default

MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are optional device labels. The page says so in the sentence that introduces them:

"If you opt in to receive additional labels in the integrity verdict, deviceRecognitionVerdict can contain the following additional labels."

An integration set up once and never revisited is reading the narrower response. If your backend branches on MEETS_STRONG_INTEGRITY and nobody opted in, that branch never executes, and nothing errors to tell you.

What MEETS_STRONG_INTEGRITY means depends on the Android version

Where the label is present, it carries two meanings:

"On Android 13 and higher, the MEETS_STRONG_INTEGRITY verdict requires MEETS_DEVICE_INTEGRITY and security updates in the last year for all partitions of the device, including an Android OS partition patch and a vendor partition patch."

"On Android 12 and lower, the MEETS_STRONG_INTEGRITY verdict only requires hardware-backed proof of boot integrity and does not require the device to have a recent security update."

Google's own recommendation follows:

"Therefore, when using the MEETS_STRONG_INTEGRITY, it is recommended to also take into account the Android SDK version in the deviceAttributes field."

So "strong integrity means the device is patched" is true on some devices and false on others, from the same constant. Read the SDK version alongside it.

The limits Google publishes about its own product

All three sit under Security considerations on the overview page.

On what weight to put on it:

"The Play Integrity API works best when used alongside other signals as part of your overall anti-abuse strategy and not as your sole anti-abuse mechanism."

On volume, the limit that shapes architecture:

"By default, your app can make up to 10,000 total requests per day across all installs. You can request to increase your daily maximum."

An app that calls the API on every launch, or on every transaction, hits that ceiling at a scale most Indian consumer apps reach easily. Design against the number; do not discover it in production.

On caching, with the reason attached:

"Avoid caching integrity verdicts", because "Caching integrity verdicts increases the risk of proxying, which is an attack where a bad actor reuses a verdict from a good device for abusive purposes in another environment."

That rules out the obvious answer to the quota.

If anything still calls SafetyNet

"The SafetyNet Attestation API was deprecated in 2022 and fully turned down in January 2025."

The failure has a specific shape, and a string to grep for:

"The attest API returns a task that always invokes the on failure listener with an ApiException and a status code of 7 (NETWORK_ERROR)."

An inference, not something Google says: an attestation API that has been turned down and fails with a constant named NETWORK_ERROR presents in a crash dashboard as a connectivity problem. A team looking at that dashboard is looking at the right signal filed under the wrong cause.

The boundary all of this points at

Every documented Android integrity primitive produces evidence for a server: key attestation, Play Integrity and app attestation. That constraint is written into the instructions for using them.

Google's key attestation page states it as a caution before the validation steps:

"Don't complete the following validation process on the same device."

OWASP arrives at the same place. Its mitigation for root and jailbreak detection says where the decision lands:

"Combine with Attestation: Back local checks with server-verified device attestation… so the backend can act on integrity signals even if local checks are bypassed."

And its mitigation for instrumentation detection ends the same way: "Respond to Detection: Terminate, restrict sensitive functionality, or signal the backend when instrumentation is detected."

A check that runs on the device and decides on the device is under the control of whoever holds the device. Send the signal off the device and the decision leaves with it.

What this page cannot tell you

How Google reaches a verdict. Google evaluates the available signals. The criteria are not published.

What to do about a verdict you do not like. That is a product decision. It depends on what the app is, who uses it, and what a false result in either direction costs.

Whether any of it is enough. None of these sources gives an effectiveness figure for any of these controls. This page gives you the shape of what is returned, the limits the vendor publishes, and where the decision belongs.