An emulated device is software that mimics a real mobile device — running a mobile operating system (iOS or Android) and its apps virtually, on a computer or server, instead of on physical phone hardware. The same technology has two very different uses: a legitimate one (development and quality assurance) and a fraudulent one (faking app installs and engagement at industrial scale).
The legitimate use: development and QA
Developers and QA teams routinely run apps on emulators (Android Emulator in Android Studio) and simulators (the iOS Simulator in Xcode) to test across device models, OS versions, and screen sizes without owning every physical device. This is standard, sanctioned practice — emulators are a core part of the mobile build-and-test loop. The catch for measurement: these QA sessions can pollute analytics and attribution if they aren't filtered out, inflating install and event counts with internal, non-user activity.
The fraudulent use: install farms and fake engagement
The darker side is mobile ad fraud. Fraudsters spin up large fleets of emulated devices — hundreds or thousands running in parallel on cheap cloud servers — to fake the entire user journey: a click on an ad, an "install", an app open, even scripted post-install events to mimic an engaged user. Because each emulated device can be reset to look brand new (fresh advertising ID, wiped storage), a small server farm can manufacture a huge volume of fraudulent installs that bill against a UA budget. Emulator farms are one of the cheapest, most scalable fraud techniques, which is why they remain a persistent problem — see [[ad-fraud]] for the broader fraud taxonomy.
How MMPs and fraud tools detect emulators
- Device fingerprint anomalies — emulators often expose impossible or inconsistent hardware/OS combinations (a "phone" with a desktop GPU, a model string that never shipped, mismatched build fingerprints).
- Missing or fake sensors — real phones report accelerometer, gyroscope, battery, and touch data with natural noise; emulators frequently lack these or return suspiciously clean values.
- Datacenter IPs — emulator farms run in cloud datacenters, so their traffic originates from known server IP ranges rather than residential/mobile carrier networks.
- Behavioral signatures — no real touch entropy, identical session timing across "devices", impossibly fast funnels, and clustered event patterns that betray scripting.
- Reset/new-device velocity — an implausible rate of "brand new" devices from the same source is a classic install-farm tell.
The major MMPs (AppsFlyer Protect360, Adjust Fraud Prevention, Singular Anti-Fraud) and the big self-attributing networks bundle emulator detection into their anti-fraud layers, flagging or rejecting emulator-sourced installs before they're attributed and billed. For advertisers, the practical defense is to run UA through an MMP with active fraud filtering, watch for traffic sources with abnormal emulator rates, and exclude QA/emulator traffic from production analytics with a test-device allowlist.