Shipping on Android: The Device Fragmentation Survival Guide

Android fragmentation breaks four things: performance on weak hardware, layout on unusual screens, graphics on specific chipsets, and behaviour across operating system versions. Deciding your minimum specification early converts an unbounded problem into a testable one. A matrix of five real devices covers most of it.

Why this matters

Android reaches most of the world's mobile players, and a large share of them are on hardware several years old.

A game tuned on a recent flagship can be unplayable on the devices that make up the bulk of its installs, and the resulting reviews arrive before anybody diagnoses the cause.

Fragmentation is manageable. It is only overwhelming when the supported range was never defined.

What fragmentation actually breaks

Four categories, in order of how often they cause problems.

1. Performance. Older chips, less memory, and aggressive thermal limits.
2. Layout. Aspect ratios from squarish to very tall, plus notches, punch holes, and rounded corners.
3. Graphics. Different GPU families with different driver behaviour, particularly around shaders and compression formats.
4. Platform behaviour. Memory management, background rules, permissions, and back navigation vary across versions and manufacturers.

Notice that art quality is not on the list. Fragmentation problems are engineering and layout problems.

Fragmentation is unbounded until you write down a floor. After that it is a test plan.

Choosing a device matrix worth testing

Five physical devices give good coverage for a casual mobile game.

Two rules. Buy the floor device first, because it drives more decisions than the rest combined. And choose the volume device from your actual install data once you have some, rather than from general market data.

Emulators are useful for layout and useless for performance and thermal behaviour. Both matter, so physical hardware is not optional.

Minimum spec, and how to set it

Set it deliberately, early, and in writing.

Base it on three things: the operating system version, available memory, and a GPU generation. Then express it as a named device so the whole team can picture it.

Three inputs to the decision.

• Your target markets. The device mix differs enormously between regions, and this should drive the floor rather than convenience.
• Your genre. A simple puzzle game can support far older hardware than a 3D title.
• The engineering cost. Every generation lower costs real optimisation and QA time.

Then enforce it. Set the minimum version in the manifest so unsupported devices cannot install rather than installing and failing, which protects your reviews.

Revisit it once a year. Floors that never move quietly become the largest constraint on the project.

Screen sizes, notches, and safe areas

Layout is the most visible failure and the easiest to fix.

• Design for a range, not a resolution. Anchor interfaces to edges and safe areas rather than to fixed positions.
• Respect the safe area for notches, cutouts, rounded corners, and gesture bars. Every platform exposes this; use it.
• Keep critical content in the centre band, which is consistent across every aspect ratio.
• Avoid the very bottom edge, which conflicts with system gestures, per Input Handling for Mobile.
• Test the extremes, not the middle. If the squarest and tallest screens work, everything between them will.

For gameplay, decide whether extra vertical space shows more of the world or is used for interface. Both are valid; deciding accidentally is not.

GPU and driver differences

The category that produces the strangest bugs.

Common failures include shaders that compile on one chipset and fail on another, texture compression formats that are unsupported on older hardware, precision differences producing visual banding, and driver-specific issues with particular rendering features.

Four practices reduce this.

1. Keep shaders simple, per Shader Basics for Devs. Complex shaders are where driver differences surface.
2. Use a widely supported compression format, with a fallback for older devices.
3. Test on at least two GPU families, which is why the matrix includes an alternative chipset.
4. Watch for precision issues on the floor device specifically, since mobile precision defaults differ.

Platform behaviour across versions

Less glamorous and a common source of one-star reviews.

• Memory pressure. Backgrounded games are killed aggressively on low-memory devices. Save state on pause, not on exit.
• Back navigation. Handle the gesture and the button correctly, including at the root of the app.
• Permissions. Request only what you need and only when you need it, since the flow differs across versions.
• Interruptions. Calls, notifications, and split screen all need graceful handling.
• Storage. Rules about where an app may write have changed across versions; use the platform-provided locations.

Save-on-pause deserves emphasis. On a low-memory device an app can be killed without further warning, and progress lost that way is indistinguishable to a player from a save bug. The techniques are in Save Systems That Do Not Corrupt.

Testing without owning 40 phones

Three approaches, used together.

Buy five. The matrix above, secondhand where possible. This is the foundation and it is not expensive.

Use a device farm for breadth. Cloud services run automated launches and screenshots across many devices, which catches layout and launch crashes well. They are weaker for performance and feel.

Use pre-release testing channels. A closed test with real players on real devices, before a wide release, surfaces the long tail you cannot buy. Watch crash reporting closely during it.

Add automated launch testing to your build process: install, launch, reach the first playable moment, screenshot, exit. Run it across the farm on every release candidate. It catches the most damaging class of bug, which is a game that will not start on a common device.

What we would do

Buy the floor device in the first week and keep it on the desk. Every performance decision becomes concrete once there is a specific phone that has to run it.

Write the minimum specification into the project plan, enforce it in the manifest, and revisit it annually.

Then automate launch testing across a device farm and read crash reporting daily from the first pre-release build. Between those two, most fragmentation problems are found before players find them.

The short version

• Fragmentation breaks performance, layout, graphics, and platform behaviour, not art.
• Five devices cover most of it: floor, volume, tall screen, alternative GPU, and flagship.
• Set the minimum specification early, name it as a device, and enforce it in the manifest.
• Anchor layouts to safe areas and test the extreme aspect ratios, not the middle.
• Keep shaders simple and test on at least two GPU families.
• Save on pause, automate launch testing on a farm, and use a pre-release channel.

Buy your floor device this week and keep it on the desk. If you want a fragmentation pass before release, send us the build.

Related reading: Unity Mobile Performance, Mobile Game QA: How It Works, and Cut Your Unity Build Size in Half.