Can I just block all Android emulators?

Yes for offers and cashouts, as long as the detection is based on clear emulator profiles or software GPUs. Few real rewards users complete paid offers inside an emulator.

What if a real user has a phone that looks spoofed?

That is why a single mismatch should send the cashout to review rather than block it. Check the rest of the account: other devices, payout address, offer speed and history.

Are phone farms with real devices detectable?

Harder than emulators, but yes. Farms reuse hardware, wipe storage, buy cheap China-only models and complete the same offers in the same order. Linking accounts by device and payout address brings the farm together.

Does a China-only model outside China mean fraud?

No. It means the phone was imported or the user travels. It becomes meaningful when it appears together with proxies, shared devices or many similar accounts.

Emulators and phone farms on rewards apps: how to catch them without blocking real users

One computer running ten Android emulators can look like ten phones in ten homes. Phone farms go further with racks of real devices. This guide covers how both work, the hardware clues they cannot hide and a fair way to act on them.

Short answer

Catch emulators and phone farms by checking what the hardware reports against what the device claims: a phone model paired with a GPU it never ships with, default emulator profiles, software GPUs and wiped devices that reappear. Block clear emulator profiles at the offer click, send a single mismatch to review, and act on the linked cluster.

Clearest sign: An impossible model and GPU pair, such as a Pixel 8 that reports an Adreno GPU.
Emulator giveaways: Default emulator models, very old Android builds with current Chrome, software GPUs, desktop-size screens on a phone model.
Phone farms: Reuse hardware, wipe storage, buy cheap China-only models and complete the same offers in the same order.
Avoid: Banning whole brands or blocking on a single model mismatch.

Why emulators and farms target rewards apps

Mobile offers pay well. Install a game, reach level 20, earn a few dollars. Advertisers pay that much because they expect a real player on a real phone. A farm fakes the player and keeps the payout.

There are two main setups. The first is the emulator: software such as LDPlayer, Nox, MEmu, BlueStacks or Genymotion that runs Android on a PC. One strong computer can run many at once. The second is the phone farm: shelves of cheap real phones, often reset between accounts, sometimes controlled by scripts.

Both aim for the same result. Many accounts, each looking like a different person on a different device, each completing the same high-paying offers. The network reverses the conversions weeks later, often after you already paid out.

What a device claims vs what it reports

Every browser or webview tells you what it is. The user agent and client hints give a model name such as Pixel 8 or SM-S918U. That claim is easy to change. Farm tools rotate model names with one click.

The hardware is harder to fake. Through WebGL the device reports its graphics chip (GPU). Real phones ship with a known GPU. A Pixel 8 uses a Mali GPU. A US Samsung Galaxy S model uses a Snapdragon chip with an Adreno GPU. When the claimed model and the reported GPU do not match, the device is lying about what it is.

Claimed model	Reported GPU	Verdict
Pixel 8	Mali-G715	Consistent, a real Pixel 8 ships with this family
Pixel 8	Adreno 740	Spoofed, Pixel 8 never ships with Adreno
Pixel 5	Mali-G76	Spoofed, Pixel 5 ships with Adreno
SM-S918U (US Galaxy)	Mali-G710	Spoofed, US models use Snapdragon and Adreno
iPhone	Adreno or Mali	Spoofed, iPhones report an Apple GPU
Android phone	Apple GPU	Spoofed, often an iPhone or Mac pretending

Default emulator profiles

Emulators need to report some phone model. Most users never change the default, and the defaults are well known. Several popular emulators present themselves as Korean-market Samsung models (the N suffix, such as SM-G977N) or as older Asus and vivo models. Developer images report names like sdk_gphone or vbox86.

Another giveaway is the Android build. Emulators often run old Android versions, such as 5.1 or 7.1, with a build number that ships only on the emulator image. Pair that with a modern Chrome version and you have a combination real phones almost never show.

Korean Samsung model on a US or European IP. Possible for a traveller, common for an emulator.
Very old Android build plus current Chrome. Real phones that old rarely get new Chrome builds.
Software GPU such as SwiftShader or llvmpipe. A phone with no real graphics chip is a virtual machine.
Desktop-size screen on a phone model, or a phone that reports a mouse and no touch.

China-only phone models abroad

Some phones are sold only in mainland China. OPPO and OnePlus models with codes like PJx, Xiaomi models ending in C, vivo models ending in A and Huawei or Honor models ending in -AN00 or -AL00 are examples. These models are cheap to buy in bulk and common in phone farms.

A China-only model connecting from the United States is not proof of fraud. People travel and import phones. But when many accounts on your site report China-only models from US, UK or Canadian IPs, it is a strong sign that the traffic comes from a farm and the IPs come from a proxy.

Device resets and storage wipes

Farms know that sites store a device ID. So they wipe the app data, clear the browser or reset the phone before each new account. A new ID appears, and the site thinks it has a new device.

The reset removes the stored ID. It does not remove the hardware. The same GPU, screen size, Android build and installed fonts come back each time. A device whose storage is empty but whose hardware traits match a device you saw an hour ago has almost certainly been wiped.

Empty storage, familiar hardware. Flag it and link it to the earlier device.
Many accounts per hardware profile in a short time, each on a fresh ID.
Identical offer order across those accounts, a sign of one script or one worker.

Act without blocking real users

Device signals are powerful but not perfect. Browser fingerprints can be faked, and cheap phones sometimes report strange values. A fair policy uses these signals to slow the money down, not to punish on a single clue.

Block at the offer click only for clear emulator profiles and software GPUs. Real players on real phones are not affected.
Review, do not block, on a single model mismatch. Put the cashout in a queue with the evidence.
Act on the cluster. If ten accounts share one spoofed profile, decide on all ten together.
Keep an allowlist. Testers, staff and known good users on unusual hardware should not be flagged every week.
Measure first. Run the checks without blocking for a few days and see how many cashouts they would affect.

How CashoutGuard automates it

The CashoutGuard JavaScript collector reads the model, GPU, screen and build. Your server calls /v1/evaluate at signup, offer click, conversion and cashout, and gets a 0 to 100 score with reasons.

device_spoofed when the claimed model and the GPU cannot belong to the same phone.
emulator_profile for default emulator models and emulator-only Android builds.
emulator_or_vm and automation_detected for virtual machines and scripted browsers.
device_market_mismatch for China-only models outside China.
storage_cleared_reappeared and device_shared_with_accounts for wiped devices and shared hardware.

The fraud rings view links accounts by device, payout address, email and IP, so a farm shows up as one cluster. New sites start in shadow mode, so you can see the results before anything is blocked. Read the docs or compare plans on the pricing page.

Native Android apps: checks a browser cannot do

A rewards app built for Android can see more than a web page. The CashoutGuard Android SDK runs inside your app and checks the phone itself: emulator properties and files, a rooted system, hooking frameworks such as Frida and Xposed that fake what the app reads, a debugger, location-spoofing apps and a VPN running on the device even when the IP looks residential.

It also gives each phone an ID that survives uninstalling and reinstalling the app, derived from the Android ID and salted with your key so it is useless to anyone else. A farmer who resets the app to create a new account comes back as the same device, and the new account is linked to the old ones.

Check	Reason code	Why it matters on a rewards app
Emulator properties, files and hardware	`emulator_or_vm`	Emulator farms run paid installs and playtime offers around the clock
Rooted phone	`device_rooted`	Root lets an app fake its device ID and location; weak alone, strong with other signs
Frida, Xposed or Substrate in the app	`automation_detected`	Hooks rewrite what your app sees, including every other check
VPN running on the phone	`ip_vpn`	Unlocks offers for richer countries even when the exit IP looks residential
Same phone after a reinstall	`device_shared_with_accounts`	One person, many accounts, one payout at a time

Integration is one call before each payout: the app collects a request_id at signup, offer click and cashout, and your server asks /v1/evaluate. See integrations for the Kotlin code.

2026-09-28