Testing Android Apps Across Different Screen Sizes and Resolutions

Android does not have one screen, it has a spread: compact phones, tall 20:9 displays, tablets, foldables, notched devices, and split-screen windows that change size while your app is running. A layout that looks perfect on the team's phone can overlap, clip, or waste half the space elsewhere. This guide covers how to prepare layouts for that spread and how to test them efficiently.

Why layouts break

Screens differ along several axes at once: physical size, pixel density, aspect ratio, and window size. On top of that sit cutouts, display holes, the system bars, and font scale settings. Most layout bugs come from assuming one axis, a fixed height here, a single width there, when the next device varies all of them together.

Build for a range first

Testing finds problems, but design choices reduce how many there are to find. These habits cut the majority of screen-size defects before any device is involved.

• Use flexible containers such as ConstraintLayout instead of fixed pixel positions.
• Let content scroll rather than squeezing everything into one viewport.
• Size things in dp, text in sp, and never hardcode pixel heights for text rows.
• Provide tablet layouts or width-based resource qualifiers such as sw600dp where the phone layout genuinely does not fit.
• Handle window insets so content clears cutouts, status bars, and gesture navigation.
• Avoid fixed-width labels and buttons that break when text expands.

The states to cover

• Portrait and landscape on the same screen
• Split-screen and pop-up view, where the window can be dragged to extreme sizes
• Cutout and hole-punch displays with content running edge to edge
• Tablet and foldable layouts, including the half-open posture where your app sits at an angle
• Largest system font size combined with the narrowest width you support
• External display or desktop mode, if your app can be dragged onto one

How to run the pass

1. 1

   Sweep with previews and emulators

   Android Studio device previews let you flip through sizes without launching anything. Follow with an emulator run over your matrix, including at least one tablet profile and one foldable, watching for clipping and overlap rather than functionality.

1. 1

   Drag windows by hand

   Multi-window behavior cannot be judged from a static screenshot. Put the app in split-screen and drag the divider to its extremes. Text should reflow, lists should resize, and controls should stay reachable at every width.

1. 1

   Rotate with state

   Rotate every screen in your core flows. The layout must reflow, and data entered before rotation should still be there afterward.

1. 1

   Confirm on real hardware

   Emulators render layouts accurately, but real devices reveal density quirks, OEM fonts, and cutout handling. If tablets are part of your audience, test on a real tablet before release.

Running this sweep across a proper device spread takes real time, which is why teams with a wide audience often include it in AppsTestLab's Android App Testing service, where the matrix covers phones, tablets, and foldables on every release candidate instead of whenever the calendar allows.