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

Almost every discussion of the Play Integrity API is really a discussion about one label, and it is not one of the labels the API returns unless you asked for it.

This page is what Google documents the API returning, the limits Google publishes about its own product, and the boundary all of it points at. Read 3 September 2026, from Google's pages rather than from a summary of them.

The three families

Google structures the response as three verdicts about three different things: 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.

Keeping them separate is worth the effort, because they fail independently and a single boolean in your backend cannot express which one moved.

What the device verdict returns by default

This is the part that surprises people. MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are optional device labels, and 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."

So an integration set up once and never revisited is reading a narrower response than the conversation about it usually assumes. If your backend has a branch for MEETS_STRONG_INTEGRITY and nobody opted in, that branch does not execute — and it does not error either.

MEETS_STRONG_INTEGRITY means two different things

Where the label is present, it does not carry one meaning. Google splits it by Android version:

"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 from that and is the practical half:

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

"Strong integrity means the device is patched" is therefore true on some devices and not on others, using the same constant. That is a design decision to accommodate, not a defect to report.

The limits Google publishes about its own product

These are Google's statements about Google's API, and they are unusually candid. 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, which is the one that reaches 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, meets that ceiling at a scale most Indian consumer apps reach easily. The quota is raisable on request; the point is that it is a number to design against rather than discover.

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."

Which rules out the obvious response to the quota, and rules it out for a stated reason rather than by assertion.

If anything still calls SafetyNet

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

And the failure has a specific shape worth knowing, because it is the string a developer greps 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)."

Our inference, and it is an inference rather than anything 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 — key attestation, Play Integrity, app attestation — produces evidence for a server. That is not a position anyone has to be argued into; it 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 from the other direction. Its mitigation for root and jailbreak detection not being implemented is explicit about 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."

Read together, the two sources say one thing. A check that runs on the device and decides on the device has the check and whoever is working on it standing on the same side of the boundary. A signal that leaves the device and is decided elsewhere does not. That is a structural argument, drawn from what the platform owner and the standards body each publish, and it needs no claim about how often anything succeeds or fails.

What this page cannot tell you

How Google reaches a verdict. The furthest any source goes is that Google evaluates the available signals. The criteria are not published, and anybody presenting a list of them is presenting something they have not read.

What to do about a verdict you do not like. That is a product decision about what your app does with a signal, and it depends on things no general page knows — what the app is, who uses it, and what the cost of a false result in either direction is.

Whether any of it is enough. No source consulted gives an effectiveness figure for any of these controls, so this page does not either. What it gives you is the shape of what is returned, the limits the vendor publishes, and where the decision belongs.