An Android app that works perfectly on the developer’s phone and falls apart in the hands of real users is not a rare outcome. It is the default outcome, and it is the single biggest difference between building for Android and building for iOS.
The reasons are specific rather than mysterious. Here they are, along with what actually catches them.
Key Takeaway: Emulator testing catches almost none of the problems that generate one star reviews. The four that matter are OEM battery managers killing background work, memory ceilings on budget hardware, layout assumptions that break on real screen ratios, and API level spread. All four need physical devices or a device farm.
OEM Battery Managers, the Biggest One
Samsung, Xiaomi, Oppo, Vivo and others each layer their own aggressive power management on top of Android. Background work that runs faultlessly on a Pixel gets killed silently on those devices, often within minutes of the app leaving the foreground.
Users do not report this as a battery optimisation issue. They report it as your app not syncing, not sending notifications, or losing their data. The review says the app is broken, and from where they sit it is.
The mitigations are partial and worth knowing. Use WorkManager rather than raw background threads or naive services, because it is designed to survive across these conditions. Where work genuinely must continue, a foreground service with a visible notification is far harder for the system to kill. For anything time-critical, push messages rather than polling, so the server drives the work instead of your app trying to stay awake.
Then test on an actual Samsung and an actual Xiaomi. There is no substitute, and no emulator reproduces it.
Memory Ceilings on Cheap Hardware
A device with 2GB of RAM behaves nothing like the flagship on a developer’s desk. Screens that feel smooth in the office stutter or get killed outright in the field.
The usual causes are consistent. Loading full-resolution images into a scrolling list. Holding Activity references in objects that outlive them. Leaking coroutine scopes. Caching aggressively without bounds. Every one of these passes testing on good hardware and fails quietly on cheap hardware, which is what a large share of Android users actually carry.
Profiling is the only reliable answer, because these problems do not reproduce where most developers work. Android Studio’s memory profiler on a genuinely low-end device tells you more in an afternoon than a week of reasoning about it.
Screen Sizes That Are Not a List
iOS has a manageable set of screen dimensions. Android has a continuum, plus foldables that change dimensions while your app is running.
Layouts built around a fixed aspect ratio break visibly. Text that fits on the design device wraps awkwardly elsewhere. Buttons drift under the system navigation bar on devices with different insets. None of this is difficult to avoid, but all of it requires building responsively from the start rather than retrofitting after somebody complains.
Foldables deserve a specific mention because they trigger configuration changes mid-session. An app that loses state when the device unfolds looks broken in a way users notice immediately.
API Level Spread
Android users update far more slowly than iPhone users, so supporting several API levels at once is normal rather than exceptional.
Each level supported downward carries a cost in compatibility shims and testing. The decision about how far back to go should come from your analytics rather than from a number somebody typed once. If the app is new and you have no analytics, pick from your target market and revisit once real numbers exist.
Running in the other direction, Google raises the target API level requirement annually. Apps that miss the deadline stop being discoverable to new users on current devices. Every Android app needs at least one compatibility release a year purely to stay compliant, before a single feature is added. Any development proposal that ends at launch has quietly made that your problem.
Building a Test Matrix That Is Worth Having
The goal is not testing everything, which is impossible. It is testing the right small set.
Start from your own analytics if the app exists. The top ten devices usually cover a large majority of your users, and that is where physical testing belongs. If the app is new, take the equivalent list for your target market instead.
Cover the spread deliberately rather than the top of it. One current flagship, one mid-range device from two or three years ago, one genuinely low-memory device, at least one Samsung and one Xiaomi for the battery manager behaviour, and one tablet if tablets matter to you. That is roughly five or six devices doing most of the work.
Then use a cloud device farm such as Firebase Test Lab for the long tail. Automated instrumented tests running across a wide matrix in CI catch the layout and crash issues that only appear on hardware nobody owns.
The failure mode to avoid is testing exclusively on emulators. They are useful for rapid iteration and nearly useless for the four problems above.
What This Means for Your Timeline
Android testing takes longer than iOS testing, and estimates that treat them as equivalent are wrong.
It is not that Android development is slower. It is that verification is genuinely broader, and the work of confirming behaviour across a device matrix is real work that has to sit somewhere in the plan. Teams that discover this late compress testing to make the date, ship, and then spend the following month firefighting reviews.
Build it into the estimate instead. Our app development timeline guide covers where this fits in a realistic schedule.
Frequently Asked Questions
Can we skip physical devices and use only a cloud device farm?
For most projects a farm covers the long tail well, but you still want a handful of physical devices for anything involving the camera, sensors, battery behaviour or day-to-day development. Farms are excellent for automated runs and awkward for exploratory testing.
How many Android devices should we buy?
Five or six covers most needs if chosen deliberately: a current flagship, a mid-range device a few years old, a low-memory device, a Samsung, a Xiaomi and optionally a tablet. Buying twenty rarely helps more than choosing six well.
Does cross-platform development make fragmentation better or worse?
Neither, mostly. React Native and Flutter both render on the same hardware and inherit the same OEM behaviours. What cross-platform saves you is writing the fix twice. Our cross-platform overview covers where the real savings sit.
Why does our app work on Android 14 but crash on Android 10?
Usually an API introduced after your minimum level being called without a version check, or a permission model that changed between releases. Both are caught by testing on a device at your actual minimum rather than only at the top.
Is fragmentation getting better over time?
Slowly. Screen and API fragmentation has eased somewhat as the ecosystem matured. OEM battery management has not improved and is arguably worse, because each manufacturer keeps adding its own layer.
Getting This Right
Most of it comes down to whether the team you hire has shipped to real users or only built for reviewers. Ask any prospective partner which devices they test on and how they chose them, because the answer sorts the field quickly. Our Android app development in India page covers how we agree a device matrix and where physical testing ends and the farm begins. If you would rather put a Kotlin engineer inside your own team, hiring Android developers covers that route.