Emulator vs real device testing: what the emulator misses

An Android emulator running a Google Play system image will install your app, receive push messages and follow a fake GPS route across town. Ask the Play Integrity API about it, though, and the best verdict it can get is MEETS_VIRTUAL_INTEGRITY. It will never return MEETS_DEVICE_INTEGRITY, the label Google reserves for genuine, certified phones.

That verdict sums up the whole topic. The emulator copies Android faithfully. It doesn’t copy any phone that any of your users own.

My rule is emulators on every commit and real phones before every release. The rest of this piece explains where that line comes from.

What it is

The Android Emulator ships with the SDK and runs an Android system image as a virtual device on your computer. You pick the image: plain AOSP-based, “Google APIs” (with Google Play services), or “Google Play” (with the Play Store too).

A real device is a retail phone. It runs its manufacturer’s build of Android on its own chipset, with its own radios, sensors and SIM, on a carrier network.

How it works

The emulator runs the system image with hardware virtualisation on your own CPU, which is why Google recommends images that match the host: x86_64 images on Intel and AMD machines, arm64 images on Apple Silicon. Its network traffic goes out through your computer’s connection. Inside the emulator, 10.0.2.2 is an alias for the host’s loopback interface.

What it can simulate is a long list, and the extended controls panel is where most of it lives:

Location: single points, or whole routes played back from a GPX file at the speed you pick.
Cellular: network type from GSM up to 5G, signal strength, and voice and data states such as roaming or denied.
Battery charge level and whether a charger is connected.
Incoming calls and SMS messages.
Virtual sensors. Rotating the virtual device moves the accelerometer and magnetometer readings together, and separate sliders cover temperature, proximity, light, pressure or humidity.
Ten virtual fingerprints, a virtual camera scene for ARCore, and extra displays.

For quick resets there are snapshots, so a clean device boots in seconds instead of from scratch.

That list is from Google’s documentation of the extended controls. It covers a lot of Android. It covers none of the manufacturer, carrier or hardware layers below.

Why it matters

Manufacturer builds

Samsung, Xiaomi, Oppo and the rest ship their own versions of Android. The permission dialogs look different and use different text, the notification settings move, and most of them add battery management on top of Android’s own Doze and App Standby.

You can test stock Doze on an emulator. The Android docs give the commands:

adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

What you can’t test there is a manufacturer’s own background restrictions, because the emulator doesn’t run that manufacturer’s build. Automation scripts feel this too. A selector written against a Pixel-style system dialog finds nothing on One UI.

Carrier networks

The cellular panel changes what Android reports: network type, signal bars, roaming. The packets still leave through your office Wi-Fi with your office’s public IP. The emulator’s -netspeed and -netdelay options can slow things down, but a bandwidth profile isn’t a mobile network.

Things you only see on a real SIM:

Carrier NAT and the carrier’s DNS.
Handover between Wi-Fi and mobile data in the middle of a request.
An IP address that geolocates to a mobile carrier in the right country, which matters to any app or API that treats datacenter and office IPs differently.
A real SMS, from a real sender, to a real number. The emulator can inject a fake incoming SMS, which is fine for testing your UI and no use for testing whether an OTP provider delivers.

Push and background work

On Google APIs and Google Play images, Firebase Cloud Messaging works. The Doze docs say high-priority FCM messages are delivered even in Doze, with temporary network access. On a real phone, the manufacturer’s battery saver and the user’s own battery settings sit on top of that. If your app depends on a notification arriving on time, the emulator can confirm that your code handles the message. It can’t tell you whether the message arrives on the phones people actually carry.

Device integrity

This is the one that most often blocks a test outright. From Google’s Play Integrity verdict definitions:

MEETS_DEVICE_INTEGRITY means a genuine, certified Android device. On Android 13 and higher, that requires hardware-backed proof that the bootloader is locked and the OS is a certified manufacturer image.
MEETS_VIRTUAL_INTEGRITY is the emulator label: an emulator with Google Play services that passes system integrity checks.
An emulator that doesn’t pass, or a phone showing signs of root or hooking, gets an empty device verdict.
MEETS_STRONG_INTEGRITY on Android 13 and higher also needs security updates within the last year.

So if your app, or a third-party app you’re automating, gates a feature on device integrity, the emulator can’t reach that feature. A real phone isn’t automatically enough either, since rooting it or unlocking the bootloader breaks the verdict. One more trap: a sideloaded debug build gets UNRECOGNIZED_VERSION in the app verdict, because its signature doesn’t match Play’s records. Test integrity flows with a build installed from a Play testing track.

Performance and hardware

Your laptop’s CPU and GPU are far faster than a mid-range phone, and the emulator never gets thermally throttled after ten minutes in a warm pocket. Frame drops and ANRs that show up on a budget phone often never appear on the emulator. If your app ships native code, the emulator on an x86 machine may run a different ABI build, or translate ARM code, rather than executing the arm64 libraries your users get.

Then there’s the hardware nobody simulates properly: the real camera pipeline, NFC, pairing with a real Bluetooth accessory, the touch panel itself.

Common misconceptions

“A Google Play image is as good as a certified phone.” It isn’t. It gets MEETS_VIRTUAL_INTEGRITY at best, and apps that require device integrity will treat it accordingly.

“The cellular controls simulate a carrier network.” They change what Android reports about the network. The traffic still leaves through your host’s connection.

“One real phone covers it.” One Pixel tells you how your app behaves on a Pixel. The manufacturers your users have (your analytics will tell you which) each need their own check.

“Real devices are too flaky for CI.” Most of that flakiness is setup: animations left on, screens that sleep, adb connections over congested Wi-Fi, two tools fighting over the same phone. It’s fixable. The ADB over Wi-Fi guide covers the connection side and the uiautomator2 vs Appium comparison covers the framework side.

When emulators are fine, and when you need a real phone

Emulators are the right tool for unit and instrumented tests on every commit, an API-level matrix, layouts across screen sizes and densities, Espresso suites, and anything you want to reset to a clean state in seconds. They cost nothing per device, and you can run a dozen in CI.

Reach for real phones before a release, on the models your users actually have. You also need them for anything gated on Play Integrity, anything that depends on a carrier, an SMS or where an IP address sits, push reliability and background work under manufacturer battery rules, performance on low-end hardware, and apps that refuse to run on emulators at all. For watching those runs live, scrcpy mirrors a real phone to your desktop over USB or the network.

Where to go from here

If you’d rather not buy, charge and rack the phones yourself, cloudf.one rents real Android phones in Singapore that you control from the browser, each on a persistent Singapore mobile IP. That’s our product; the same team writes this site.

For the source material, see Google’s pages on the emulator’s extended controls, Play Integrity verdicts and testing with Doze and App Standby.

Written by Xavier Fok

disclosure: ADB Handbook is published by the team that runs cloudf.one. The cloudf.one link in this article goes to our own product and is marked sponsored. Last reviewed by Xavier Fok on 2026-09-11.