Play Integrity Checks And What A Cloud Phone Shows
What play integrity actually checks
Play Integrity API is Google’s replacement for the old SafetyNet Attestation. An app calls it, Google’s servers run a check against the device and the app install, and the app gets back a signed verdict it can send to its own backend. The verdict isn’t a single yes or no. It’s three separate signal groups: app integrity (is this the real, unmodified APK, installed from a source Google recognizes), account details (is there a licensed Google Play account tied to this install), and device integrity (does the hardware and software stack look like a genuine, unaltered Android device).
The device integrity piece is the one that trips people up, because it isn’t checking configuration. It’s checking whether the device can produce a hardware-backed attestation at all. That comes down to whether the device has a Trusted Execution Environment or StrongBox secure element, whether the bootloader is locked, whether the system partition is unmodified, and whether the device passed Google’s own certification (the same certification that lets a phone ship with Play Store and Play Protect baked in).
The three verdict tiers
Google labels the device integrity result as MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY, or MEETS_STRONG_INTEGRITY, and a device can return more than one of these at once, stacked. Basic integrity means the device isn’t obviously rooted or running on a known-bad build. Device integrity means it’s a certified device with a locked bootloader running unmodified system software. Strong integrity means the attestation was backed by real secure hardware, a TEE or StrongBox key that can’t be extracted or faked in software.
That last tier is the one apps care about most for anything sensitive: payments, account creation, anti-fraud gating. It’s also the one that’s structurally impossible to fake from software alone, because the verdict is cryptographically tied to a key that only exists inside a physical secure element. There’s no config file or system property that produces it. The hardware either has the key or it doesn’t.
Why emulators trip the hardware bar
An emulator, even a well-built one running a real Android system image, is software pretending to be a phone. It doesn’t have a TEE. It doesn’t have StrongBox. There’s no physical secure element for the attestation key to live in. So when it asks for a device integrity verdict, it either gets rejected outright or it comes back at basic integrity at best, because there’s no hardware root of trust to attest from.
Some emulator setups try to patch around this by spoofing build fingerprints, faking a certified device profile, or routing the attestation call through a real device elsewhere and relaying the result. Google has spent years closing these gaps, and the fixes tend not to last: a spoofed fingerprint gets flagged the moment Google cross-checks it against telemetry that doesn’t match a real device of that model, and a relayed attestation binds to a nonce tied to the original request, so replaying it against a different session breaks the signature. None of this is a guaranteed bypass, and treating it as one is a good way to burn accounts on apps that actually check the verdict server-side instead of just reading it and moving on.
What a real cloud phone can show that an emulator can’t
A cloud phone, in the sense we run them, is a physical Android device racked in a data center, running its stock or near-stock firmware, with remote display and input piped over the network so an operator can drive it like a local phone. It isn’t virtualized Android on a server. It’s an actual handset with an actual Snapdragon or Exynos chip, an actual TEE, and in most current mid-range and flagship models, an actual StrongBox module.
Because the hardware is real, the attestation is real. When an app on that device requests a Play Integrity verdict, the device can produce a genuine hardware-backed key signature, because there’s a genuine secure element holding the key. That’s the entire difference. It’s not a trick or a workaround, it’s just physics: the check is designed to distinguish real secure hardware from software pretending to be hardware, and a real phone is real hardware.
This matters for account work because a growing number of apps, especially fintech, delivery, and anything handling payments, gate signup or sensitive actions behind a device integrity check. An emulator farm hits a wall there that no amount of software tuning gets past. A rack of real phones doesn’t hit that wall, because there’s nothing to fake.
What still shows up even on real hardware
Real hardware clears the device integrity bar, but that’s only one signal group out of several an app can look at, and it’s not the only thing that decides whether an account survives. App integrity still checks the install source and the APK signature, so sideloading a modified client still fails that check regardless of what phone it’s on. Account details still check for a Google account with a Play Store license on that app, which is a separate requirement from the device passing hardware checks.
More importantly, Play Integrity is a device-and-install signal. It says nothing about behavior. An app’s own anti-fraud stack still watches things like login velocity, IP reputation, session patterns, how many accounts share a payment method or a device fingerprint over time, and whether new accounts are doing things real users don’t do in their first few minutes. A real phone with a clean integrity verdict sitting behind a data center IP with no browsing history and no organic app usage is still a device an app can flag on network or behavior grounds, verdict or not. Hardware integrity removes one detection vector. It doesn’t remove the rest of the stack.
How we build cloud phones for this at Multi Account Ops
We run our cloud phones on real handsets, not emulated images, specifically because of this gap. Each device keeps its stock bootloader lock state and unmodified system partition wherever the workflow allows it, because that’s what device integrity and strong integrity are actually checking. Where automation needs ADB access, we treat that as something to manage deliberately rather than leave open, since a device sitting in a persistently debuggable state is itself a signal some apps check for, separate from the Play Integrity call itself.
The devices sit behind our Singapore residential and mobile proxy pool rather than raw data center IPs, because network origin is graded independently of the device attestation, and a genuine mobile carrier IP paired with a genuine phone is a materially different picture than a genuine phone behind a hosting-range IP. Account warm-up on top of that is paced deliberately: real session lengths, real app usage patterns, time before an account is asked to do anything sensitive. None of this is about beating a specific check. It’s about not asking a device or an account to look like something it isn’t at any layer, hardware, network, or behavior.
What this doesn’t mean
None of this is a guarantee that an account won’t get banned, and we don’t sell it as one. Play Integrity passing at the strong tier tells an app one true thing: this request came from a real, unmodified, certified device. It doesn’t tell the app anything about the account’s history, the network it’s connecting from, or what it does next. Apps that combine device attestation with behavioral fraud scoring will still catch patterns that look wrong regardless of what the phone reports. Real hardware closes off one detection path. It’s the one that’s hardest to fake, but it was never the only one.
If you’re weighing cloud phones against emulator farms for work that involves an app checking Play Integrity, the honest framing is this: real hardware gets you a real hardware verdict, and that’s a meaningful, unspoofable difference for anything gated on device integrity. Everything above the device layer, network, account history, behavior, still has to be built carefully, because that’s where most detection actually happens once the hardware question is settled.
If you want to see how we set up cloud phones, proxies, and account isolation for this kind of work, take a look at Multi Account Ops.
Get new guides and videos first — join the Telegram channel.