Why Emulators Fail Device Checks: What Security Teams Should Know

For anti-fraud systems, the device can become a trust signal before a login, payment, or other sensitive action takes place. Google says apps using Play Integrity features see 80% lower unauthorised usage on average than other apps, which helps explain why device checks have moved well beyond simple emulator detection.

An emulator does not fail because of one obvious property. Modern integrity systems look at several layers at once, including signals tied to hardware-backed trust that a standard emulator cannot reproduce in the same way as a genuine certified Android device.

What a device check actually verifies

A device check is rarely one yes-or-no test. Play Integrity evaluates several parts of the environment and returns information that the backend can interpret according to the risk of the action being performed.

At the application level, it can indicate whether Google Play recognises the installed app and whether its package and signing certificate match the distributed version. Account and licensing information can show whether the user obtained or updated the app through Google Play. Device integrity then addresses a different question: whether the app appears to be running on a genuine Android device that meets the required security conditions.

Where emulators give themselves away

Traditional emulator detection often starts with software-level clues. Build properties may expose generic fingerprints, model names associated with virtual hardware, or combinations of values that would be unusual on a retail handset. Sensors can behave differently from physical components. Telephony data may be missing or synthetic, battery behaviour may look artificial, and GPU strings can reveal virtual rendering or architecture translation.

Those signals still have value, particularly when several of them point in the same direction. Their weakness is that many are software-visible properties. A determined attacker can attempt to modify individual values, intercept checks, or reproduce a more convincing device profile.

That is why stronger anti-fraud systems no longer depend only on a checklist of suspicious strings. The more useful question is not simply whether an environment looks like a phone from the application layer, but whether it can present security evidence rooted in trusted hardware and a verified software state.

Hardware-backed attestation changed the rules

Hardware-backed attestation makes that distinction much harder to imitate with cosmetic changes. Instead of trusting values that an application can read from the operating system, Android can use cryptographic evidence associated with secure hardware to verify parts of the device state.

On Android 13 and later, MEETS_DEVICE_INTEGRITY requires hardware-backed proof that the bootloader is locked and that the loaded Android operating system is a certified manufacturer image. MEETS_STRONG_INTEGRITY raises the bar further by requiring recent security updates, including the relevant Android OS and vendor partition patches from within the previous year.

This changes the economics of emulator spoofing. Editing a build fingerprint or changing a model string is very different from reproducing a valid hardware-backed chain of trust.

There is also an important exception that prevents the discussion from becoming too simplistic. Google Play Games for PC can return MEETS_VIRTUAL_INTEGRITY, meaning Google explicitly recognises a supported virtual environment that passes its own system-integrity and compatibility requirements. The distinction is therefore not “physical good, virtual bad". It is whether the environment can produce the type of trusted evidence expected for that platform.

A failed check is a signal, not a verdict

A weaker integrity result should not automatically be treated as proof of fraud. Legitimate users can fall outside stronger integrity requirements for reasons that have little to do with malicious activity.

A device may be running older security patches. Its bootloader may be unlocked. The software state may fall outside the conditions required for a stronger verdict even though the user is genuine. MEETS_BASIC_INTEGRITY, for example, can still appear in environments where the bootloader is unlocked or the boot state is not fully verified.

This is why mature anti-fraud systems usually benefit from graded responses instead of a single hard block. A low-risk action may be allowed with additional monitoring, while a payment, account recovery, or other sensitive operation can trigger step-up authentication, lower limits, or manual review.

Testing integrity logic where it will actually run

Security teams can test failure handling on an emulator, but that covers only part of the problem. A negative path can confirm that the backend reacts correctly when expected integrity labels are absent. It does not prove that legitimate users on certified hardware will receive the expected verdict or move through the flow without unnecessary friction.

That makes physical-device testing part of the security workflow rather than just ordinary mobile QA. Teams often need coverage across several manufacturers and Android versions, particularly when enforcement logic changes according to the operating-system generation. An internal device lab works when the required models are used frequently, while cloud device farms can broaden coverage. When a team only needs a specific physical Android model for a limited test window, android smartphone rental can be a practical alternative to purchasing another handset..

The Android SDK version should be recorded alongside every integrity result. The meaning of MEETS_STRONG_INTEGRITY is not identical across all Android releases: Android 13 and later include the recent-update requirement, while Android 12 and earlier use different criteria. Without that context, two identical-looking verdicts can be interpreted too broadly.

A practical checklist for security teams

Device integrity works best when the backend treats it as part of a broader decision process rather than a client-side gate. The implementation also needs enough telemetry to explain why legitimate users are being challenged after a release or policy change.

• Decrypt and verify integrity tokens on the server rather than trusting a client-side decision.
• Bind requests to a nonce or requestHash so a valid response cannot simply be reused in another context.
• Define enforcement rules around both the integrity label and the Android version that produced it.
• Combine device integrity with behavioural, account, and transaction signals instead of using it as the only fraud indicator.
• Track the distribution of integrity verdicts after application releases and policy changes so unexpected shifts can be investigated before they affect a large share of genuine users.

Final takeaway

Emulators fail many modern device checks because integrity systems increasingly depend on hardware-backed trust, not only on software properties that can be copied or changed. That makes device attestation much more useful for anti-fraud teams, but it does not turn every failed check into proof of abuse.

The stronger approach is to treat integrity as one risk signal, apply proportionate responses, and validate the enforcement logic on the physical Android devices where genuine users will actually encounter it.