Play Integrity explained for teams running phone-use agents

If you run an AI agent that taps and types on a real Android phone, sooner or later an app will behave differently on your agent’s device than on your own personal handset. Sometimes it refuses to log in or hides a feature. Very often the reason is Play Integrity, Google’s API that lets an app ask “is this a genuine device running a genuine copy of my app?” before it trusts a request.

I’m Xavier Fok, a Singapore-based operator, and I run phone-use agents on real hardware. This article is the plain-language version of what Play Integrity is, what it checks, and what it means for your setup. It is an explainer, not a bypass guide; the goal is to understand the signal so you can plan your device fleet sensibly.

What it is

Play Integrity is an API from Google Play that an Android app developer calls to get a signed statement about the environment their app is running in. Google’s documentation on the Play Integrity API describes it as a way to check that interactions and server requests come from your genuine app binary running on a genuine Android device.

It replaced the older SafetyNet Attestation API. Google announced SafetyNet’s deprecation and pushed developers to migrate, and as of September 2026 Play Integrity is the supported path. If you read older forum posts about “passing SafetyNet”, that is the previous generation of the same idea.

The important thing to understand is who is asking. Your agent does not call Play Integrity. The app you are driving does. The app’s developer decides whether to use it, which signals to request, and what to do when the answer is bad. Banking apps, games, ticketing apps and anything with fraud exposure tend to lean on it.

How it works

The flow has four steps, and it helps to picture them as a conversation between the app, Google Play, and the developer’s own server.

• the app asks Google Play Services for an integrity token, and includes a value that ties the token to one specific request
• Google Play evaluates the device, the app and the Google account, then returns an encrypted, signed token
• the app sends that token to its own backend
• the backend decodes the token, reads the verdicts, and decides whether to serve the request

The developer’s backend makes the decision, not the phone, so the check cannot be argued with locally.

Google documents two request styles. The standard request is designed for frequent checks, where the app prepares a provider in advance and then requests tokens quickly, binding each one to a hash of the action being protected. The classic request is a heavier call meant for occasional, high-value moments, and it uses a nonce the server generates to stop replay of old tokens. Both styles exist so a developer can tie a token to one action, such as a payment or a login, instead of accepting a reusable pass.

The verdicts

The decoded token contains several verdict fields. The verdicts reference is the source of truth and is worth reading in full, but the main ones are:

• device integrity: whether the device looks like a genuine, certified Android device. Labels include MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY, each stricter than the last
• application integrity: whether the app binary is the one Google Play recognises, or a modified or repackaged version. Values include PLAY_RECOGNIZED and UNRECOGNIZED_VERSION
• account details: whether the user’s account has a Play licence for the app, with values like LICENSED and UNLICENSED
• optional extras: developers can opt into further signals such as a Play Protect verdict or a recent device activity level

There is also a virtual integrity label, MEETS_VIRTUAL_INTEGRITY, used for Google-sanctioned Android emulation environments such as the one Google Play Games uses. It is not a general pass for any emulator.

Google has tightened what the device labels require over time, including using hardware-backed evidence on newer Android versions. Because that can change again, check the verdicts page for current wording before relying on any label. Everything here is as of September 2026.

What the token cannot tell an app

The token does not say “this is a bot”. It does not describe who is operating the phone or whether a human is holding it. It reports on the device and the app binary. That distinction is the source of a lot of confusion, covered below.

Why it matters

Four reasons to understand this.

• it decides which devices are usable for a given app. If the app you are automating requires a strong device verdict, an unmodified certified phone can satisfy it and an emulator or a rooted, modified device generally will not. Answer that before you buy hardware, not after
• it explains failures that look like bugs. An agent that works on your personal phone but gets stopped at login on a test device may not have a bug in its logic at all. The app may have looked at the token and declined to proceed
• it shapes your test environment. Many teams start on emulators because they are cheap and scriptable. That is fine for developing agent logic. It is a poor guide to how a production app will treat the same flow on a real handset, so plan a real-device stage
• it is a signal you can read on your own apps. If you build the app your agent drives, you can request the token in a test build and see exactly what your own backend receives. That is the cleanest way to learn what your agent’s devices look like from the server’s side

For the wider picture of what you can and cannot do on a phone with an agent, I keep a how-to on setting up ADB for a phone-use agent, which covers the control layer that sits underneath all of this.

Common misconceptions

Four wrong takes come up often.

“Play Integrity detects bots”

It does not. It attests to device and app state. A phone-use agent running on a genuine, unmodified, certified phone with the genuine app installed can produce a perfectly healthy token, because the token is not about behaviour. Apps that want to stop automation use other signals on top: rate limits, behavioural analytics, account risk scoring. Those are separate systems and each site’s terms apply. I would not treat a good Play Integrity verdict as permission to do anything the app’s terms forbid.

“An emulator is the same as a phone”

For attestation purposes it usually is not. Standard emulators generally do not satisfy the stricter device labels, which is why the virtual label exists as a narrow exception for approved environments. If a flow matters to you, test it on the kind of device your users actually hold.

“It is a one-time check at install”

It is not. The developer chooses when to call it. Some apps check at login, some at each sensitive action, some only occasionally. A token is tied to a request, so an app that checks only at install and an app that checks at every payment behave very differently. When an agent is blocked mid-flow rather than at login, this is one of the first things to consider.

“Passing means the whole app will work”

A good verdict is one input. The developer’s backend can still refuse you for a dozen other reasons: an unlicensed account, an outdated app version, a region restriction, an expired session. Debug the specific failure before assuming attestation is the cause.

Where I land on running agents around it

My own view, as an operator, is simple. Treat attestation as a property of the hardware you choose, not something to fight. Use unmodified, certified devices, keep them on current Android and Play Services versions, and run your agent only against apps and accounts you are entitled to automate. That keeps you on the honest side of both the technical check and the terms of service.

Two practical notes from my own setup. First, isolation still matters. An agent controlling a phone can do real damage if it goes off script, so I keep it contained, and my write-up on how to sandbox a computer-use agent covers the thinking that carries over. Second, if you need real Android hardware and do not want a drawer of handsets, cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. It is Singapore-only, so it only fits if your work is meant to run from a Singapore device. I mention it because “real phone” is the property attestation cares about, not to suggest any product changes what an app’s backend decides.

Where to go from here

If this was your first pass at Play Integrity, these are the follow-ups I would read next.

• the control layer: how to set up ADB for a phone-use agent walks through connecting and driving a device before you worry about what the apps make of it
• containment: how to sandbox a computer-use agent covers limiting what an agent can touch when it is acting on your behalf
• state between runs: how to persist browser sessions for AI agents is about keeping logins alive properly instead of re-authenticating every run
• network path: how to route a Playwright agent through a mobile proxy explains the connection side, which is a different layer from device attestation

The full index of guides is at /blog/. And if you want to go to the primary source, start with Google’s Play Integrity overview and read the verdicts page slowly. It is the one document that tells you what an app can and cannot learn about your device.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-30.