Android emulator

Emulation runs Android as a guest on a server or desktop, usually on QEMU or VirtualBox with hardware acceleration through KVM or HAXM. Everything the guest reports about hardware is produced by the hypervisor: sensors, radios, battery, GPU and network adapter are all synthesised by software that was written to make apps run, not to imitate a phone. For development and functional testing this is exactly right — an instance boots in seconds, resets to a clean snapshot, and costs nothing to run twenty at a time.

The signals that give it away

Detection is not one clever check but a stack of cheap ones, most of which need no permission:

• Properties — ro.kernel.qemu=1, ro.hardware set to goldfish or ranchu, ro.product.model containing sdk_gphone or "Android SDK built for x86", ro.build.tags=test-keys in build.prop.
• Files and devices — /dev/qemu_pipe, /dev/socket/qemud, /dev/socket/genyd and /dev/socket/baseband_genyd on Genymotion, /data/bluestacks.prop on BlueStacks.
• CPU — /proc/cpuinfo naming an Intel or AMD part, or Build.SUPPORTED_ABIS listing x86_64 first, often alongside an ARM translation layer such as libhoudini or libndk_translation.
• GPU — GL_RENDERER returning "Android Emulator OpenGL ES Translator", "SwiftShader" or "llvmpipe" instead of an Adreno, Mali, PowerVR or Xclipse part.
• Sensors — a current handset enumerates 25 to 40 sensors; emulators typically expose fewer than ten, with accelerometer variance of exactly zero because nothing is holding the device.
• Battery — dumpsys battery reporting 100 percent, AC charging and a temperature of exactly 25.0 °C on every read, forever.
• Radio — no baseband, therefore no genuine IMEI, no carrier registration and no signal-strength history.
• Network — a hypervisor OUI in the MAC address, and an empty or single-entry BSSID scan whose RSSI never moves.

Running the checks

• adb shell getprop ro.kernel.qemu ro.hardware ro.product.model — three properties, one answer.
• adb shell cat /proc/cpuinfo — look at the model name line.
• adb shell dumpsys battery — then wait an hour and run it again.
• adb shell dumpsys sensorservice — count the enumerated sensors.
• adb shell ls /dev/socket/ — the hypervisor-specific sockets are named after their vendor.

Why property patching does not close the gap

Every emulator stack marketed for stealth patches the obvious properties, and that handles the first bullet in the list above. It does not touch the rest. The GPU string comes from the graphics driver, the sensor list from a hardware abstraction layer that has no sensors behind it, the battery curve from a model that does not discharge, and the CPU from silicon that is genuinely x86. Patching those means writing convincing physics, which nobody does — a battery that discharges realistically has to discharge at a rate that matches the screen brightness, the workload and the ambient temperature it also claims.

Attestation closes the argument independently. Google’s Play Integrity API asks the hardware keystore for a signature; an emulator has no hardware keystore, so it cannot return MEETS_DEVICE_INTEGRITY regardless of what its properties say. Even Google’s own emulator running Play Store system images reaches basic integrity at best.

When an emulator is the right tool

For building and debugging an app, an emulator is usually better than hardware: faster to reset, easier to script, free to run in parallel, and snapshot-restorable to a known state before every test run. CI grids run on emulators for exactly these reasons, and paying for physical devices to run unit and UI tests is a waste of money.

The trade-off appears only when the thing being measured is the device itself — QA validating hardware-specific behaviour such as camera pipelines, sensor fusion or thermal throttling, or any workload where an app scores the environment it runs in. Then the synthetic values stop being a convenience and become the whole problem. That distinction is why device farms on real hardware exist alongside emulator grids rather than replacing them, and why the honest question is never "emulator or real device" in the abstract but "which signal does this workload depend on".

One more difference matters at scale: an emulator instance is disposable, and a real device is not. Disposability is a feature for testing and a liability for anything that needs a device to be the same device next week — which is the requirement behind device isolation.