Device fragmentation: OS versions, screens, mid-range Androids

A web app runs in a handful of browsers on a laptop or two. A mobile app runs on thousands of different devices — different manufacturers, screen sizes, OS versions, chip speeds, and amounts of memory — and it must work on all the ones your users actually own. This is device fragmentation, and it is the first thing that makes mobile testing genuinely different (and harder) than testing a website. This lesson is what fragmentation is, why it breaks apps, and how a QA tests against it without owning a thousand phones.

What fragmentation is

Fragmentation is the enormous diversity of the devices your app must run on. It has several axes, each a source of bugs:

Operating system versions — Android especially: users are spread across many Android versions (an old phone on Android 9, a new one on Android 14), and each version behaves slightly differently. iOS is less fragmented (Apple pushes updates hard) but still spans several versions.
Screen size and density — from small, low-resolution screens to large high-density ones. A layout that looks right on the developer's phone may overflow, clip, or overlap on a smaller or larger screen.
Manufacturer customisations — Android is not one Android: Samsung, Xiaomi, Oppo, and others layer their own skins, keyboards, permission dialogs, battery managers and quirks on top. A bug can be specific to one manufacturer's build.
Hardware capability — a mid-range or budget phone has a slower CPU, less RAM, and slower storage than a flagship. The app may be fine on a fast phone and janky, slow, or crashing (out of memory) on a cheap one.

The key realisation: your users are not on the developer's phone. They are on a wide spread of devices, skewed towards cheaper, older ones — and the app must work for all of them, not just the shiny new phone the app was built and demoed on.

Why the developer's phone is the trap

Developers build and test on their device — usually a recent, capable phone, on fast wifi, in the same place every day. That single device hides a huge class of bugs:

The layout is fine on their large screen but broken on a small one.
The app is fast on their flagship but unusably slow on a mid-range phone.
A feature works on their Android version but crashes on an older one, or on a Samsung.
It runs fine with plenty of free memory but the OS kills it on a phone with little RAM.

"Works on my machine" is bad enough for web; for mobile it is acute, because the range of real devices is so wide and the developer's device is at the good end of it. A core part of the mobile QA's value is deliberately testing on the devices the users have — especially the cheaper, older, more common ones — which the developer never sees. For a product serving a broad market on mostly mid-range Android phones, testing on a mid-range Android is not optional; it is where the real experience is.

Know your users' devices, and pick a representative set

You cannot test every device (there are thousands), and you should not try. The skill is choosing a representative set based on your users' actual devices:

Get the data. Analytics tell you which devices, OS versions, and screen sizes your real users are on. Test against those, weighted by how common they are — not a random assortment, and not just the newest.
Cover the spread deliberately. Pick devices that cover: the oldest OS version you support and the newest; a small screen and a large one; a low-end (slow, low-RAM) device and a flagship; the dominant manufacturer(s) among your users. A handful of well-chosen devices covers most of the real risk.
Prioritise the low end. Because the developer already tests the high end, the QA's highest-value devices are the cheap, old, common ones — that is where the untested bugs (slowness, memory, layout on small screens, old-OS quirks) live.

So "which devices do I test on?" is answered by data about your users, not by what is available or new. A mobile-money app whose users are largely on budget Androids should be tested hardest on budget Androids.

Real devices, emulators, and device farms

How do you get access to a representative set without a drawer full of phones?

Real devices — the gold standard, and irreplaceable for some bugs (real performance on a slow chip, real manufacturer quirks, real touch behaviour, real cameras/sensors). Keep a small set of the most important real devices (especially a low-end one).
Emulators / simulators — the OS running on your computer. Great for quick checks across OS versions and screen sizes, and for automation, but they do not reproduce real performance, real manufacturer skins, or real hardware quirks — an emulator runs on your fast computer, so it will not show the slowness a real budget phone does.
Device farms — cloud services (BrowserStack, AWS Device Farm, Firebase Test Lab) that give you access to hundreds of real devices remotely. The practical way to test across many real devices without owning them — invaluable for covering the fragmentation you cannot hold in your hand.

The sensible mix: a few key real devices in hand (including a low-end one), emulators for quick breadth across OS versions and screens, and a device farm when you need to verify on real devices you do not own. The one thing to remember: an emulator will lull you into thinking the app is fast and smooth — always confirm real performance on a real, cheap device before trusting it.

Check your work

What fragmentation is. The huge diversity of devices an app must run on — OS versions (Android especially), screen sizes/densities, manufacturer skins, and hardware capability (a slow budget phone vs a flagship) — each an axis of bugs.

The developer's-phone trap. Developers test on one recent, capable device on fast wifi, hiding layout, performance, old-OS and manufacturer bugs. "Works on my machine" is acute on mobile because the real device range is so wide and skewed cheaper/older than the dev's phone.

Representative set from user data. You cannot test every device — use analytics to test the devices your users actually have, weighted by frequency; deliberately cover oldest/newest OS, small/large screen, low-end/flagship, dominant manufacturers; prioritise the low end (the untested, high-risk part).

Real vs emulator vs farm. Real devices (gold standard — real performance/quirks; keep a low-end one), emulators (quick breadth across OS/screens, but not real performance/skins), device farms (many real devices in the cloud). Mix them; always confirm real performance on a real cheap phone.

Practice

For an app you know, list the axes of fragmentation and give a concrete bug each axis could cause.
Imagine you have the users' device analytics for a mobile-money app on mostly budget Androids — choose a representative set of 5 devices to test on and justify each.
Explain why the developer's flagship on fast wifi is the worst single device to judge the app on.
Contrast what a real budget device shows that an emulator does not (name three things).
Describe how you would use a device farm to cover fragmentation you cannot hold in your hand.
Take one feature and reason about how it might break differently on a small screen, an old OS version, and a low-RAM device.

Official documentation

Android — Testing on many devices / fragmentation — Android's own testing guidance across devices.
Firebase Test Lab — Running tests on many real devices in the cloud.
BrowserStack — App live/automate (device farm) — Real-device testing across the fragmentation.

Next: low connectivity, flaky networks and offline behaviour.