Emulator and Device Farm Detection for Rewards Apps

How do rewards apps detect emulators and device farms?

Rewards apps detect emulators and rooted devices with platform attestation: Google’s Play Integrity API on Android and Apple’s App Attest on iOS, both checked on your server. They detect phone farms, which often run on real phones that pass attestation, with server-side patterns: many accounts per device or network, activity faster than a person could manage, the same offers completed in the same order, and several accounts cashing out to one destination. Then they hold new and risky earnings before cash-out, so a reversal cancels a reward that never left the site.

This guide is for owners of rewards apps, games with an earn screen, and rewards websites. It explains what each signal proves, what it does not prove, and how to act on it. It does not describe how abusers get around detection.

Emulators, rooted devices and phone farms

Three different setups get lumped together as “device fraud”. They need different checks, so it helps to keep them apart.

All three aim at the same thing on a rewards app: being paid many times for what is really one person. That is why device checks belong next to the account checks in Stop multi-accounting and VPN abuse and the sign-up checks in Stop fake sign-ups on a rewards site, not in place of them.

What the Google Play Integrity API attests

Google’s Play Integrity API overview says the API helps you check that requests come from “your genuine app, installed by Google Play, running on a genuine and certified Android device”, and that it uses hardware-backed security signals. Your app asks for an integrity token, sends it to your server, and your server reads the decrypted verdict. The integrity verdicts reference lists what is inside (checked on November 5, 2026):

Baseline checks, before anything else

• Request details: the package name, the request hash (standard requests) or nonce (classic requests), and a timestamp. Google says to check these match the original request first, which stops a token from one request being replayed for another.
• App integrity: PLAY_RECOGNIZED means the app and certificate match what Google Play distributes. UNRECOGNIZED_VERSION means the certificate or package name does not match Play records, a sign of a modified or repackaged app.
• Account details: LICENSED means the user installed or updated your app from Google Play. UNLICENSED covers sideloaded copies.

Device labels

• MEETS_DEVICE_INTEGRITY: a genuine and certified Android device. On Android 13 and higher there is hardware-backed proof that the bootloader is locked and the system is a certified manufacturer image.
• No label at all: Google says this means signs of attack such as API hooking, system compromise such as root, or an app not running on a physical device, such as an emulator that does not pass Google Play integrity checks.
• MEETS_BASIC_INTEGRITY (opt in): the device passes basic system checks, but the bootloader may be unlocked and the device may not be certified.
• MEETS_STRONG_INTEGRITY (opt in): a genuine certified device with a recent security update. On Android 13 and higher that means security updates within the last year.
• MEETS_VIRTUAL_INTEGRITY: only for apps released to Google Play Games for PC, an approved emulator with Google Play services. A rewards app on phones should not expect it.

Optional signals that matter for farms

• Recent device activity: how many integrity tokens your app requested on that device in the last hour, in four levels. Google suggests it for finding hyperactive devices and says high-volume abusers commonly generate valid attestations on real devices and hand them to bots on rooted devices and emulators.
• Device recall (beta): three bits you set per device, stored on Google’s servers, that survive a reinstall or device reset. You could use one to mark “already claimed the welcome bonus”.
• App access risk: whether apps are running that could capture the screen, show overlays, or control the device. Remote control and automation tools show up here, though verified accessibility services are excluded.
• Play Protect verdict: whether Play Protect is on and has found harmful apps.

Google is direct about the limits. The overview says the API “works best when used alongside other signals” and not as your sole anti-abuse mechanism, recommends a range of server responses such as allow, allow with limits, and deny, warns against caching verdicts, and sets a default of 10,000 requests per day across all installs, which you can ask to raise (checked on November 5, 2026). It also suggests running the API without enforcement first, so you see what your real users return before you block anyone.

What Apple App Attest and DeviceCheck attest

On iOS the tools live in Apple’s DeviceCheck framework, which has two parts.

App Attest

Apple’s guide to establishing your app’s integrity says you cannot rely on your app to check itself, because a compromised app can falsify the results. Instead the app creates a key pair in the Secure Enclave, Apple certifies that the key belongs to a valid instance of your app on Apple hardware, and the app signs sensitive requests with that key. Your server checks every attestation and assertion against a one-time challenge it issued. Practical details from Apple’s pages:

• Not every device supports the service, so your app checks isSupported and your server must handle devices that cannot attest. Apple says the value is false on a Mac, including iOS apps running on Apple silicon.
• Keys survive app updates but not a reinstall, device migration, or restore from backup.
• The attestation records how the app was distributed, for example App Store, TestFlight, or a development build.

Apple’s page on assessing fraud risk adds the signal most useful against farms: your server can request a risk metric, the approximate number of attested keys for your app on that device over the past 30 days. Apple says to look for a low number. A device that keeps generating new keys may be one compromised device serving many fake app instances.

DeviceCheck bits

The same framework lets your server set and read two bits per device, stored by Apple. Apple’s example is marking a device that has already used a promotional offer or that you found to be fraudulent. You decide what the bits mean and when to reset them, for example when a phone is sold.

Apple is as clear as Google about the ceiling: “No single policy can eliminate all fraud”, and App Attest “can’t definitively pinpoint a device with a compromised operating system.” Treat its result as one input to a risk score.

Server-side checks that catch phone farms

A farm of real, unmodified phones passes attestation. What it cannot hide is that one operator runs it, so the evidence shows up in your own data. Store the device ID your app generates, the network, and the payout destination with every account, and look across accounts, not one at a time.

Reversals are the feedback loop. When an advertiser finds fraud, the result is taken back, and if you have already paid the user you lose twice. What is a reversal rate? shows how to track it per user, and How to prevent referral fraud covers farms that pass earnings up a referral chain.

Detecting emulators on a rewards website

A web page cannot call Play Integrity or App Attest, so a rewards website has weaker device evidence. Browser signals, such as screen size, graphics details and time zone, can show that a “phone” visitor is really a desktop browser pretending to be one, or that many accounts share one setup. They are probabilities, not proof: many people own the same phone model, and privacy browsers change their values on purpose. What is device fingerprinting? explains why, and the privacy rules that apply.

That makes the server-side patterns above, payout matching, and holds even more important on the web. If your property has both an app and a site, consider letting cash-outs happen in the app, where attestation is available.

What to do when a check fails

Do the check where the money moves: sign-up, the welcome bonus, opening the earn screen, and above all cash-out. Then answer in tiers instead of a single yes or no.

1. Allow: a genuine app on a device with full integrity, no linked accounts. Normal hold rules.
2. Allow with limits: basic integrity only, an unsupported device, or one soft signal. Let the user earn, but no welcome bonus and a longer hold.
3. Review: several signals together, such as a linked payout destination plus high velocity. Pause cash-out and look by hand.
4. Deny: an unrecognized app version, a device you already flagged, or a confirmed farm. Block earning and record it with device recall or a DeviceCheck bit.

Honest limits of emulator and farm detection

• Real phones pass. Attestation proves the device and app are genuine, not that the person is a separate, honest user. A rack of unmodified phones looks clean to Play Integrity and App Attest.
• Verdicts can be relayed. Google itself warns that abusers generate valid attestations on real devices and feed them to bots. Content binding (the request hash), short token lifetimes and recent device activity reduce this, but do not end it.
• Coverage gaps. Play Integrity depends on Google Play, so phones sold without it, and apps installed from other stores, return weaker verdicts. App Attest is not available everywhere either. A fail is often “could not check”, not “fraud”.
• Many honest users look odd. Shared family devices, students on one campus network, and people who reinstall often all trip single signals. Act on combinations.
• Detection is late by design. Some fraud only shows when an advertiser reverses a result days later. That is the job of the hold, not of the device check.

For the wider picture of bots, click farms and fake sign-ups, read Ad fraud and bot traffic, and for attribution fraud on Android, Click injection and SDK spoofing explained.

Frequently asked questions