Device Fragmentation
Device fragmentation is the variety of environments one mobile build must work in: devices from many manufacturers, several OS versions at once, screens of different sizes, shapes and densities, different amounts of memory, and user settings such as font size, language and dark mode. Each combination is a separate environment, and the same build can behave differently in each.
An example: a checkout screen tested on a large phone in portrait works. On a small phone with a larger font, the Pay button is cut off; in landscape, the keyboard covers the card field; on an unfolded foldable, the form stretches across the whole width. None of these is a logic defect, and none appears on the phones the team uses every day.
Why it matters
Users run the app on their devices, not on yours. A layout that clips on small screens, a form that empties when the phone rotates, or a crash under one manufacturer’s system layer reaches every user with that device, and it shows up as poor store reviews and crash reports clustered on certain models.
No team can test every model, so these defects are found either by a deliberate choice of devices or by users. A device matrix with written reasons turns "we tested on some phones" into a coverage statement you can defend in a release decision: which risks each device covers, and which ones the team chose not to cover.
Where fragmentation comes from
The lesson on Android and iOS covered OS versions and store builds. Android has the widest spread in everything else, because many manufacturers ship it on hardware from budget to flagship and add their own system layer. iOS runs on fewer models, but several iPhone sizes and, where the app supports them, iPads are in use at the same time.
- Screen: size, aspect ratio, pixel density, and camera cut-outs or rounded corners that take space from the layout.
- Form factor: tablets, foldables that change size when folded or unfolded, and split-screen windows that give the app part of the screen.
- Hardware: memory, processor, camera and sensors. A low-memory device ends background apps sooner, so returning to the app restarts it more often.
- Manufacturer layer (Android): modified system dialogs and keyboards, and battery optimisation that can delay background work and notifications.
- User settings: font size, display size, dark mode, language and text direction.
Screen sizes: pixels, density and size classes
Apps lay out in density-independent units, not in pixels: dp on Android and points on iOS. One dp is one physical pixel on a 160 dpi screen, so the width in dp is the width in pixels × 160 ÷ the density. A phone 1080 pixels wide at 420 dpi is about 411 dp wide; one 720 pixels wide at 320 dpi is 360 dp. iPhones draw each point with two or three pixels in each direction (@2x, @3x). The width in dp or points, not the resolution, decides how much fits on the screen.
Adaptive layouts switch at thresholds. Android’s window size classes for width are compact (under 600 dp: almost all phones in portrait), medium (600 to 839 dp: most tablets and large unfolded foldables in portrait) and expanded (840 to 1199 dp: most tablets in landscape); wider windows have their own classes. On iOS each axis is compact or regular: an iPhone in portrait has a compact width and a regular height, and an iPad app at full screen is regular in both but gets a compact width in a narrow multitasking window. Every threshold is a boundary, so apply the lesson on boundary value analysis: test 599 and 600 dp, 839 and 840 dp.
Width is not the only limit. Status and navigation bars, camera cut-outs and the iPhone’s home indicator take space, and content must stay inside the safe area; apps that target Android 15 are drawn edge to edge by default, so a target SDK update can hide a button under the navigation bar. User settings shrink the space further: Android’s display size setting changes the width in dp, and font scaling up to 200% (Android 14 and later) or the largest Dynamic Type sizes on iOS fit far less text.
- Smallest and largest width in the matrix: no clipped text, no overlapping elements, no sideways scrolling.
- Both sides of each threshold: the layout switches as designed, for example to two panes from 840 dp.
- Safe area: nothing tappable under a system bar, a cut-out or the home indicator.
- Largest font and display size: text wraps instead of being cut off, and every action stays reachable by scrolling.
Width in dp = width in pixels × 160 ÷ density (dpi)
1080 px at 420 dpi -> ~411 dp compact
1198 px at 320 dpi -> 599 dp compact (just below the threshold)
1200 px at 320 dpi -> 600 dp medium (first value of the class)
Android window size classes (width)
compact < 600 dp almost all phones in portrait
medium 600 - 839 dp most tablets and unfolded foldables in portrait
expanded 840 - 1199 dp most tablets in landscape
On an Android emulator
adb shell wm density 320
adb shell wm size 1198x2000 # 599 dp, then 1200x2000 for 600 dp
adb shell wm size reset && adb shell wm density resetOrientation and other configuration changes
On Android, rotation is a configuration change: by default the system destroys the current screen (the activity) and creates it again. Whatever the app did not save is lost: typed text, the scroll position, the selected tab, an open dialog, and a request in flight may be sent twice or its result lost. Folding or unfolding a foldable, resizing a split-screen window and changing the font size, dark mode or language trigger the same recreation, so rotation is the quickest way to test the state saving that this whole family of events depends on.
iOS keeps the screen and lays it out again for the new size and, where they change, the new size classes, so rotation defects on iOS are mostly layout defects: a hidden button, or a keyboard that covers the focused field. In landscape a phone’s height is small (the compact height class on Android is under 480 dp), and with the keyboard open only one or two fields may be visible.
Locking a screen to portrait is a product decision to record, not an assumption. WCAG 2.2 success criterion 1.3.4 Orientation (level AA) allows it only when a specific orientation is essential. And for apps that target Android 16, the system ignores orientation and resizability restrictions on screens with a smallest width of 600 dp or more, with exceptions such as games, so a portrait-only app still appears in landscape on tablets and unfolded foldables.
- Rotate twice on every screen with input: text, selections, scroll position, dialogs and the current step survive.
- Rotate while Pay or Submit is in flight: the action is sent once and its result is shown.
- Landscape with the keyboard open: the focused field and the submit action stay reachable.
- Where the app locks orientation on phones, the lock holds; with system auto-rotate off, the app keeps the user’s orientation.
Choosing a device matrix
A device matrix is the written list of environments the team tests on, how deeply each is tested, and why each is there. Build it like any test design: first define the coverage items, the values of each dimension that must be tested at least once, and only then choose the devices that cover them.
- Data: active users by OS version, model, manufacturer and screen class from analytics, the store consoles and crash reports. For a mobile website, server logs give the browser and device type from User-Agent strings, but Chrome on Android now reports a fixed Android version and model, so take those from analytics. A new app starts from its target market.
- Coverage items: newest and oldest supported OS on each platform, the smallest width in real use and each larger size class you support, a low-memory device, the leading manufacturers, the largest font size and each text direction.
- Devices: prefer devices that cover several items at once, then add the models with the most sessions and any model with a cluster of crashes.
- Tiers: Tier 1 real devices run the critical journeys and the regression set every release; Tier 2 emulators, simulators or device farm devices run a smoke set every release; Tier 3 runs before major releases.
- Settings: spread language, orientation, font size and theme across the devices with pairwise selection instead of testing every combination.
- Upkeep: write down why each device is there, and review the matrix every quarter and after a new OS version, a new minimum version or a new market.
Worked example: a food delivery app
The app supports Android 10 (API 29) and later and iOS 17 and later, runs on iPhone only (no iPad version), and is used in Arabic and English. Illustrative data for the last 90 days: 55% of sessions on Android, three quarters of them on manufacturers A and B; 18% of Android sessions on devices with 4 GB of memory or less; smallest widths in use 360 dp on Android and 375 points on iPhone; 6% of Android sessions on foldables and tablets; 70% of sessions in Arabic; and a crash cluster on manufacturer B’s phones when users return from the payment page.
Five devices cover every coverage item at least once, as the figure shows. The budget phone D3 does the most work, and as a manufacturer B phone it is where the "return from payment" scenario runs first. Wider screens are covered only by the foldable on the device farm: an accepted risk at 6% of Android sessions, written into the matrix. For settings, four two-valued parameters across five devices give 5 × 16 = 80 full combinations; a pairwise set covers every pair of values in as few as 10 runs.
- D1 and D2: the newest OS on each platform and the models with the most sessions; D1 is also manufacturer A.
- D3: the oldest supported Android, low memory, the smallest Android width and manufacturer B with its crash cluster.
- D4: the oldest supported iOS and the smallest iPhone width.
- D5: the newest Android, medium and expanded widths, and a window that changes size while the app runs.
| Coverage item | D1Android, maker A · newest · Tier 1 | D2iPhone · newest iOS · Tier 1 | D3Android budget, maker B · Android 10 · Tier 1 | D4smallest iPhone · iOS 17 · Tier 2 | D5Android foldable · newest · Tier 2 |
|---|---|---|---|---|---|
| Most sessions | covered | covered | not covered by this device | not covered by this device | not covered by this device |
| Newest OS version | covered | covered | not covered by this device | not covered by this device | covered |
| Oldest supported OS version | not covered by this device | not covered by this device | coveredAndroid 10 | coverediOS 17 | not covered by this device |
| Smallest width in use | not covered by this device | not covered by this device | covered360 dp | covered375 pt | not covered by this device |
| Medium and expanded widths | not covered by this device | not covered by this device | not covered by this device | not covered by this device | covered |
| Window resized while the app runs | not covered by this device | not covered by this device | not covered by this device | not covered by this device | coveredfold, unfold |
| Low memory (4 GB or less) | not covered by this device | not covered by this device | covered3 GB | not covered by this device | not covered by this device |
| Manufacturers A and B | coveredmaker A | not covered by this device | coveredmaker B, crash cluster | not covered by this device | not covered by this device |
| Settings: language, orientation, font size, theme | pairwise runs | pairwise runs | pairwise runs | pairwise runs | pairwise runs |
- covered by this device
- covered on every device by the pairwise set of settings
Illustrative data from the worked example. A row with no covered cell would be a coverage gap: add a device, or accept the risk in writing.
Device matrix: food delivery app (illustrative data, last 90 days)
ID Device OS Runs on Tier
D1 Android mid-range, maker A newest Android real device 1
D2 iPhone, standard size newest iOS real device 1
D3 Android budget, maker B, 3 GB Android 10 (oldest) real device 1
D4 iPhone, smallest (375 pt) iOS 17 (oldest) device farm 2
D5 Android foldable newest Android device farm 2
Tier 1: critical journeys + regression set, every release
Tier 2: smoke set of critical journeys, every release
Tier 3: other models above 1% of sessions, before major releases
Settings: language × orientation × font size × theme, pairwise across D1..D5Common mistakes
- Testing only on the team’s own phones, which are usually recent, large and fast, with the default font size and English.
- Choosing devices from general market rankings instead of your own users’ data.
- Checking rotation only visually, never whether typed input, open dialogs and requests in flight survive it.
- Ignoring user settings: the largest font, display size, dark mode and right-to-left change a screen more than a different model does.
- Counting devices instead of coverage items: five similar flagship phones cover less than three well-chosen ones.
- Keeping a matrix with no reasons and no review date, so it still lists last year’s devices.
The QA perspective
Build the matrix with the people who own its inputs: the product owner decides supported OS versions, markets and form factors; developers know which screens adapt to size classes or lock orientation; whoever owns analytics and crash reporting supplies the data. Ask early: which is the oldest OS we support and why, do we support tablets and foldables or only allow them, and is portrait-only essential on this screen? Record the answers next to the matrix.
In test reports, state the devices and tiers each test ran on and the coverage items not covered this release. In bug reports, give the model, OS version, orientation, font and display size, language, and whether the device was real or emulated. When a defect appears on one device, try another device of the same class: if it reproduces, the defect belongs to a screen class or a setting, not to one model.
Practice exercise
Choose a device matrix for a clinic booking app
A clinic booking app supports Android 11 (API 30) and later and iOS 17 and later; on Android it also installs on tablets. Illustrative data: 60% of sessions on Android, mostly from two manufacturers; a quarter of Android sessions on devices with 4 GB of memory or less, mostly on Android 11 and 12; 5% of Android sessions on tablets; 65% of sessions in Arabic. Users report that the booking form "sometimes" loses the selected time slot.
The team can keep four real devices and has access to a device farm. Choose the matrix and list the first checks you would run.
- List the coverage items.
- Choose four real devices that cover as many items as possible, and use the device farm for the rest.
- Check that every coverage item is covered at least once.
- Write the first four screen and orientation checks, starting with the reported defect.
Show the model answer
Coverage items: newest Android and newest iOS; Android 11 and iOS 17; the smallest phone width in use on each platform; medium and expanded widths (an Android tablet in portrait and landscape); 4 GB of memory or less; the two leading manufacturers; the largest font size on each platform; Arabic and English.
Tier 1, real devices: R1, manufacturer A’s most used model on the newest Android, in Arabic; R2, an iPhone on the newest iOS, in Arabic; R3, a 4 GB manufacturer B phone on Android 11 with the smallest Android width in the data and the largest font, in English; R4, the smallest iPhone in the data on iOS 17 with the largest Dynamic Type size. Tier 2, device farm: an Android tablet in both orientations. Every item is covered; the tablet only in the farm, an accepted risk at 5% of Android sessions that the matrix records.
First checks: on R3, select a time slot, rotate twice, then leave the app and return, also with Don’t keep activities on; the slot must stay selected, because a recreated screen or an ended process that does not restore state is the likely cause of "sometimes". On R1 and R2, landscape with the keyboard open keeps the Book button reachable. On R3 and R4, the largest font clips no time slot and the form scrolls. On the tablet, the medium layout in portrait and the expanded layout in landscape work, and the slot survives rotation.
Frequently asked questions
How many devices does a device matrix need?
There is no fixed number. The matrix is big enough when every coverage item is covered by at least one device and the combinations that carry most of your sessions run on real devices. A small team can often cover the main items with four or five well-chosen real devices plus emulators, simulators or a device farm.
Can emulators and simulators replace real devices for fragmentation testing?
For screen sizes, densities, OS versions, orientation, font size and language they are fast and accurate enough for most checks, and they make thresholds such as 600 dp easy to reach. They do not reproduce manufacturer system layers, real memory pressure, performance, cameras or sensors, so the devices that represent those risks must be real. The mobile testing guide covers device strategy in depth.
Should I test landscape if the app is portrait-only?
Yes. Check that the lock holds on phones and that nothing breaks where it does not apply: split-screen and foldables change the window anyway, and apps that target Android 16 are not kept in portrait on large screens. Also ask whether portrait-only is essential, because WCAG 2.2 criterion 1.3.4 otherwise expects content to work in both orientations.
How often should the matrix change?
Review it on a fixed rhythm, for example every quarter, and whenever a new OS version ships, the minimum supported version changes, the app enters a new market, or crash reports cluster on a model the matrix does not cover.
References
- Certified Tester Mobile Application Testing (CT-MAT)ISTQB's specialist syllabus on mobile testing: app types, device and platform challenges, test types and tools.
- Core app quality guidelinesGoogle's baseline quality criteria for Android apps — visual experience, functionality, performance, privacy and security — with the tests used to check them.
- Web Content Accessibility Guidelines (WCAG) 2.2The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
Practise with Mutqan tools
Generate a minimal pairwise (all-pairs) test set from parameters and their values.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Generate boundary values (min-1, min, min+1, nominal, max-1, max, max+1) for numeric and length constraints.
Parse User-Agent strings into browser, version, engine, OS, device type and bot detection.
Generate high-level test scenarios covering functional, negative, security, usability and compatibility angles for a feature.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.