In this guide
An emulator is a good first pass. It is quick and free, and you can run it in the same window as your editor. But it is a model of a phone, and the details a model leaves out are the ones that real users meet. This applies to every app, however it was built. It matters a little more when you did not write each line yourself, because you have less of a feel for where it might be fragile.
What a real phone shows
- Speed and heat. A screen that is smooth on your computer can stutter on an older or cheaper phone. Scroll long lists, open the heaviest screen, and use the app for ten minutes.
- Permissions. Camera, location, notifications, storage: tap "Allow", then tap "Don't allow", then turn it off later in system settings. Does the app explain itself and still work?
- The keyboard. Does it cover the input field? Does the right keyboard type appear for email or numbers? What happens when you close it with the back gesture?
- Interruptions. A call, a notification, switching apps, rotating the screen, a lock screen timeout. Return to the app: is your input still there?
- Real connections. Weak signal, switching from Wi-Fi to mobile data, airplane mode. See testing offline behaviour.
- Touch and size. Are buttons easy to hit with a thumb? Does text fit on a small screen and in large system font sizes?
- Install and update. Install the release build fresh, then update over an older build. Does data survive?
You cannot check any of this convincingly from a desktop.
A short device plan
You do not need a drawer of phones. Cover differences, not quantity. This table has no market-share claims on purpose; pick from what you can reach.
| Slot | Why | Where to get it |
|---|---|---|
| Your own phone | Daily use, real habits | You have it |
| An older or cheaper phone | Shows speed and memory limits | A friend, family, a second-hand one |
| A phone with a different screen size | Layout problems | Same |
| A different OS version | Behaviour and permission dialogs differ across versions | Same, or a tester |
| One person who is not a developer | Finds the steps you stopped seeing | Ask |
Which models and versions to prioritise is covered in which Android devices you should actually test on.
When you cannot get the devices
Ask testers. Private, structured feedback from people on their own phones gives you devices you do not own, and the report includes model and OS version. Ask for it explicitly in your test brief.
For Google Play, the closed-test requirement already puts your app in front of other people's phones. See the closed-test requirements (DE) and what counts as 14 days (DE). Use those days for real feedback, not just a counter.
A 30-minute pass
- Install the release build on one real phone.
- First launch, sign-up, main flow, end to end.
- Deny each permission once, grant it once.
- Interrupt the app three ways: call or notification, app switch, rotation.
- Switch on airplane mode mid-flow.
- Write down each problem with steps, expected, actual, device. Then use the prompt template if you fix with an assistant.
Where AppReviewX fits
AppReviewX gives you private, structured feedback from other developers on their own phones. One feedback you write earns one credit, credits buy feedback on your app, and new accounts start with 0 credits. For Android there are test groups with 12 testers over 14 days in a row for the Google Play requirement.
Related: Vibe coding hub, how to test before launch, launch checklist.