Physical hardware only
Real device testing, on phones people actually carry
Every tester on our platform runs your build on their own phone — the one in their pocket, on their network, with their settings, their font size, and their dark mode preference. That is the only configuration where the bugs that reach your users live, and it is the one configuration a virtual device cannot reproduce.
We do not run emulators, virtual machines, or device farms. Not as a policy stance, but because they solve a different problem: emulators give you repeatability, and real devices give you the truth.
- Manufacturers
- Samsung, Google Pixel, Xiaomi, Redmi, OnePlus, Motorola
- Android versions
- Android 11, 12, 13, 14 and 15
- Chipsets
- ARM64 and x86_64, spanning entry-level through flagship
- Screens
- Compact phones through tablets, mdpi to xxxhdpi densities
- Device age
- Handsets in current use, including models two to four generations old
- Locales
- 80+ countries, with non-English locales available for localisation checks
The fleet at a glance
How does physical hardware differ?
Developers who move from emulator-only testing to real hardware usually describe the same experience: a first round of bugs that were always there and had simply never been visible.
Silicon decides what works
Chipset architecture and vendor drivers change what the camera, the GPU, and the audio stack will actually do. A rendering path that is smooth on a flagship can stutter on the mid-range phone most of your users own. Emulators run one architecture.
Heat changes behaviour
Sustained use makes phones warm, and warm phones throttle. Frame rates drop, background work is deferred, and long-running processes get killed. None of this exists in a virtualised environment, which is why "it worked on my machine" has an Android-specific meaning.
Manufacturer software rewrites the rules
OEM skins impose their own background limits, notification behaviour, autostart policies, and permission dialogs. A feature that works everywhere in theory can be silently blocked on one manufacturer, and the only reliable way to find out is to run it there.
Networks are not ideal
Real conditions include weak signal, mid-request drops, captive-portal Wi-Fi, and carrier-specific behaviour. Testing on a stable connection tests the one network state your users will complain least about.
Why are emulators not a substitute?
Emulators are excellent at some jobs: running fast, running in CI, running a specific API level on demand, and never being unavailable. If your goal is regression coverage on every commit, they are the right tool and nobody should talk you out of them.
They are the wrong tool for discovering how your app behaves on hardware you do not own. A virtual device has no thermal budget, no vendor camera driver, no manufacturer battery policy, and no real radio. It cannot get warm and start dropping frames. It cannot decide that your background service has used enough power for today.
There is a separate, practical reason this matters on Google Play specifically: installs from virtual devices do not behave like installs from real ones, and Google's policy on the closed testing requirement is written around real opted-in testers. We cover that distinction in our article on whether emulators count.
What we cannot test
Being specific about limits is more useful than another paragraph about thoroughness. Four things are outside our scope.
- Carrier field testing, radio certification, or anything requiring operator-side access. That is a lab service, not a tester marketplace.
- Hardware we do not own. We cannot promise a specific Bluetooth peripheral, a particular payment terminal, or a niche wearable.
- iOS and iPadOS. We are an Android service and do not test TestFlight builds.
- Compliance certifications such as PCI DSS, HIPAA, or accessibility conformance to a legal standard. We test and report; we do not certify.
Bug classes that only appear on hardware
These six account for most of what our testers find that developers had not seen before. Each one was reported with reproduction steps and the device it occurred on.
Autostart and background work silently disabled
A push notification or scheduled sync stops arriving on one manufacturer because the OEM kills background processes by default. The code is correct; the platform is not cooperative.
Layout clipping under system font scaling
A user increases their system font size and a button label pushes past its container. Invisible on any device left at the default setting.
Camera and media behaviour on older hardware
A capture flow that works on a recent flagship produces rotated, low-resolution, or unreadable output on the mid-range hardware most of the market carries.
Permission flows after revocation
The app handles the first grant correctly and mishandles what happens when a permission is revoked from system settings and the user returns to the app.
Dark theme and contrast failures
Hardcoded colours that are unreadable once the user switches to dark mode, which a surprising number of devices now enable by default.
State loss on process death
The app is killed in the background and the user returns to an empty screen or a lost form. Rare on a device that is always plugged in and never under memory pressure.
How is the device spread chosen?
A fixed device list would be neat to advertise and wrong for most apps. What matters is that the spread covers the hardware your users have, so we ask what your app does before allocating testers.
A camera app is matched against devices with different sensor generations. A game gets hardware across the performance range, including the mid-range phones where frame rate problems actually surface. A form-heavy business app gets screens small enough to break a layout. The tester pool is the same; the selection changes.
- Tester devices and Android versions are verified before a cycle starts.
- Findings always name the exact model and OS version, so a fix can be verified on the same hardware.
- Replacements keep the same device profile where possible, so coverage does not degrade mid-cycle.
- Every tester uses a unique Google account on their own physical device.
Three device matrices, worked through
What coverage means in practice depends entirely on the app. These are three real allocations from recent campaigns, and the reasoning behind each one.
A camera and photo-editing app
Allocated fleet
Two older mid-range Xiaomi or Redmi devices with different sensor generations, one Samsung flagship, one Pixel for the stock camera pipeline, and one low-end Motorola for storage and memory pressure.
What it surfaces
Rotated EXIF data in exported images, downscaling that only appears above a certain megapixel count, and save failures when storage is nearly full — none of which reproduce on a device with a clean pipeline and free space.
A casual game
Allocated fleet
Weighted toward mid-range hardware rather than flagships, spread across chipsets, with longer sessions per tester than a utility app would get.
What it surfaces
Frame rate drops and input lag that only appear once the device is warm, missing assets on low-memory devices, and touch target problems on compact screens where the controls overlap.
A field-service app used on the move
Allocated fleet
Small-screen phones, one older Android version for permission behaviour, and mixed manufacturers so background restrictions are represented.
What it surfaces
Data lost when a request is interrupted by a network transition, background sync refused by an OEM power policy, and forms that clip badly once the user increases their font size.
Device coverage questions
What the fleet covers, what it does not, and how coverage is decided for a specific app.
Do your testers use real devices or emulators?
Real physical devices only. Each tester uses their own Android phone or tablet with a unique Google account. We do not use emulators, virtual machines, device farms, or automation scripts.
Which manufacturers and Android versions are in the fleet?
Samsung, Google Pixel, Xiaomi, Redmi, OnePlus and Motorola hardware across Android 11, 12, 13, 14 and 15 — on ARM64 and x86_64 chipsets, at screen sizes from compact phones to tablets, and across 80+ countries.
Why is real device testing better than an emulator grid?
Emulators are excellent for fast, repeatable regression coverage in CI. They are the wrong tool for discovering how your app behaves on hardware you do not own, because a virtual device has no thermal budget, no vendor camera driver, no manufacturer battery policy and no real radio. It cannot get warm and start dropping frames.
What can you not test?
Carrier field testing and radio certification, specific third-party hardware such as particular Bluetooth peripherals or payment terminals, iOS and iPadOS, and formal compliance certification such as PCI DSS, HIPAA or accessibility conformance. We test and report; we do not certify.
How is the device spread chosen for my app?
We ask what the app does before allocating testers. A camera app is matched against different sensor generations, a game against hardware across the performance range including mid-range phones, and a form-heavy business app against screens small enough to break a layout.
Are findings tied to the specific device?
Always. Every finding names the exact model and Android version, so you can verify a fix on the same hardware. Replacements keep the same device profile where possible so coverage does not degrade partway through a cycle.
Written and maintained by
Afrin Asha
Founder, OnTesters
Android developer and QA specialist. Built OnTesters after working through Google Play’s 12-tester closed testing requirement on real devices.
Platform figures on this page come from campaigns run through OnTesters. Read how the platform works or see the guides library.
Sources
- Set up an open, closed, or internal test— how installs reach real devices
- App testing requirements for new personal developer accounts— the policy that requires real opted-in testers
- Device verification requirements for new developer accounts— account-level device and identity checks
Device-specific bug classes are drawn from findings reported across OnTesters campaigns. The tester pool details describe our platform, not Google policy.
Policy and pricing reviewed September 2026
Put the build on hardware you do not own
Twelve testers on physical phones across manufacturers, Android versions and screen sizes, with findings reported against the exact device each one occurred on.