Android app testing by people who use the app like users do
A build that passes on your development device and a Pixel emulator is not a tested build. It is a build that has been tried in the one environment you control. Android testing means running it on manufacturer software that behaves differently, on screen sizes you did not design for, through permission flows you wrote once and never revisited.
We run that testing on physical phones, and we write findings the way an engineer wants to receive them: reproduction steps, device, expected, observed.
What do we test, and what do you get back?
Every area below produces a written finding, not a verdict. A report that says "tested, looks fine" is worthless to the person who has to fix something, so the useful output is always the steps and the evidence.
Functional testing
Does each flow do what it claims? Sign-up, onboarding, the paid path, settings, and the screens that only appear once — the empty states, the offline states, the error states.
Report Pass or fail per flow, with the step sequence and the screen where it diverged from expectation.
Crash and stability testing
Where the app dies. Long sessions, backgrounding mid-flow, rotation during a network call, low battery, and the app being killed and reopened.
Report Reproduction steps, device model, Android version, and the last screen shown before the failure.
Compatibility testing
The same build on different OEM skins, screen sizes, and OS versions. This is where layout clipping, missing permissions, and manufacturer battery-killing behaviour show up.
Report A per-device summary of what passed and what failed, so you can see whether a bug is universal or specific to one manufacturer.
Network and state conditions
Slow connections, connections that drop mid-request, airplane-mode transitions, and what the app shows when an API call never returns.
Report Which condition triggered the failure and what the user would have seen.
Permissions and account flows
First-run permission prompts, denial paths, Google sign-in, password reset inside a WebView, and behaviour after a permission is revoked from system settings.
Report The exact prompt order and what happened on denial, since these paths are rarely tested by the developer who wrote them.
Accessibility basics
TalkBack labelling on primary controls, touch target sizes, colour contrast on text, and whether the app survives a font-size increase without clipping.
Report The control, the measurement or the observed behaviour, and a severity rating.
What do different manufacturers break?
Compatibility bugs are not random. Each manufacturer makes predictable changes to how Android behaves, and each one breaks a predictable class of feature. Testing across them is how you find the bugs your own phone can never show you.
| Manufacturer | Why it is in the fleet | Bug classes it surfaces |
|---|---|---|
| Samsung | High volume, One UI | Aggressive background limits, One UI theming overrides, custom permission dialogs |
| Google Pixel | Stock Android | Baseline behaviour — a bug that only reproduces here is usually your bug, not the OEMs |
| Xiaomi / Redmi | High volume, MIUI | Autostart restrictions that kill background work, notification permission defaults |
| OnePlus | OxygenOS | Battery optimisation that stops scheduled jobs, gesture navigation overlap |
| Motorola | Near-stock, wide price band | Low-RAM behaviour, older chipset performance, small screen widths |
Coverage across the fleet
- Android 11 through Android 15
- Phone form factors from compact to tablet
- ARM64 and x86_64 chipsets
- Densities from mdpi through xxxhdpi
- Dark theme and system font scaling enabled
- English and non-English locales
Coverage is allocated per campaign rather than fixed, because the right fleet depends on your app. A camera-heavy app needs different hardware from a form-based utility. The real device testing page covers how we build the matrix, and the emulator question explains why this is not something an emulator grid can replace.
The shape of a finding
A sample from a recent cycle, with the app details removed. This is the format every finding takes, whether it is a crash or a confusing screen, because the value of a bug report is in whether someone can act on it without asking a follow-up question.
Findings arrive in your OnTesters dashboard as they are submitted, not at the end of the cycle, so a fix can be written and shipped while testing is still running. Shipping at least two updates during a 14-day window correlates with an 89% approval rate in our data, against 53% for a window with no updates.
Sample finding
- Summary
- Session token is not refreshed after the app is killed and reopened, so the first API call returns 401 and the user sees an empty screen.
- Steps
- Sign in, force-stop the app from system settings, reopen, open the Orders tab.
- Device
- Redmi Note 12, Android 14, MIUI 14.0.4. Reproduces 4 of 4 attempts.
- Expected
- Orders load, or the app returns to sign-in with a clear message.
- Observed
- Blank list with no error state and no way to retry except killing the app again.
- Severity
- High — affects every returning user on a cold start.
Where Android testing and Play policy overlap
Same work, two purposes
If your account is subject to the closed testing requirement, this testing can run inside the same 14-day window. The activity that satisfies the policy is the same activity that finds bugs, which is why the two are not competing costs.
Different verdicts
Testing quality and approval are not the same thing. A thoroughly tested app can still be refused production access for questionnaire reasons, and a barely tested app can be approved. We are explicit about that distinction rather than implying testing buys a pass.
Beyond the requirement
Plenty of teams book testing with no policy obligation at all — an organization account shipping a rewrite, or a team that wants device coverage before a marketing push. The scope and the report are identical.
What do we need from you to start?
Setup takes minutes when four things are in place. Each of the four exists because its absence produced a cycle that tested the wrong thing.
A build testers can install
Either the Google Play opt-in link or a direct APK. On the closed track the release must have reached Active status — testers clicking an opt-in link on a release still in review land on an error page and assume the app is broken.
Accounts, if the app is gated
Two or three test accounts with pre-seeded data, or confirmation that sign-up is self-serve. A tester who cannot get past the login screen produces activity that never reaches the features you wanted examined.
A priority list of three to five flows
The parts of the app you are least sure about. Without it, testers default to the home screen and the most obvious buttons, and the sessions spend their time on the code you already trusted.
Anything already known to be broken
A bug you know about produces a report you will ignore, which spends a finding slot on nothing. Tell us and testers will look elsewhere, flagging it again only if the behaviour is worse than you described.
None of this requires source access or Play Console credentials. We work from whatever link or file lets a tester install the build, plus the context needed to aim the sessions rather than point them at the home screen.
Android testing, in practice
Scope, delivery, and how this differs from a QA toolchain running on your CI.
What kinds of Android apps do you test?
Any app delivered as an Android App Bundle (.aab) or APK through Google Play, including builds made with Kotlin, Jetpack Compose, Java, Flutter, React Native, Expo, Unity, Godot, Capacitor and Ionic. The framework does not change how testing works.
Do testers use emulators or real phones?
Real phones only. Every tester uses their own physical Android device with a unique Google account. We do not run emulators, virtual machines, or device farms, because they cannot reproduce thermal throttling, vendor camera drivers, manufacturer battery policy, or real radio behaviour.
What Android versions and devices are covered?
Android 11 through Android 15, across Samsung, Google Pixel, Xiaomi, Redmi, OnePlus and Motorola hardware, spanning entry-level through flagship chipsets and a range of screen sizes and densities. Coverage is allocated per campaign based on what your app actually does.
What does a bug report contain?
A one-sentence summary, numbered steps to reproduce, the exact device model and Android version, expected versus observed behaviour, a reproduction rate such as 4 of 4 attempts, and a severity level with the reason for it.
How is this different from your QA testing service?
The scope overlaps deliberately. Android app testing covers functional, compatibility, stability, permission and accessibility checks. QA testing adds a formal severity taxonomy, regression passes against previous builds, and explicit exclusions such as security auditing and legal conformance testing.
Can Android testing satisfy my Google Play requirement?
If your account is subject to the closed testing requirement, this testing runs inside the same 14-day window with the same testers, so it satisfies the policy and produces engineering findings at once. Testing quality and approval are still separate outcomes — Google reviews each application individually.
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 testers reach your build
- App testing requirements for new personal developer accounts— the closed testing obligation this testing can satisfy
- Device verification requirements for new developer accounts— account-level device checks
Approval correlations cited on this page come from our own campaign data. Device-specific bug classes are observations from campaigns run on the OnTesters tester pool.
Policy and pricing reviewed September 2026
Test the build your users will actually run
Send us a build and a short list of the flows that matter most. Findings start arriving within the first few days, on real hardware from manufacturers you do not own.