Device Coverage in a Google Play Closed Test: Which Android Versions and Screen Sizes to Check

You cannot test your app on every Android device, and you do not need to. What you need is a short list of the differences that actually break apps, and a way to find out which of them your testers' phones cover. This post shows how to build that plan before your 14-day closed test starts.

Why device coverage matters in a closed test

Most indie developers test on one or two personal phones and an emulator. That works until a tester opens your app on a three-year-old budget phone with a large font setting, and a button label gets cut off or a layout overlaps the navigation bar.

Your closed test is the cheapest time to find that out. The users are real, the app is not public yet, and you can still ship a fix before production. But testers will only reveal problems if you know what to look for and ask them the right questions.

The five differences that break apps most often

Instead of thinking in terms of brands and models, think in terms of these variables:

1. Android version. Behavior changes between releases. Notification permission became a runtime permission in Android 13 (API 33), for example, and newer versions are stricter about background work.
2. Screen size and shape. Small phones, large phones, tablets, foldables and windowed or split-screen modes all change your layout.
3. Memory and performance. A low-RAM phone can kill your app in the background, or make a heavy screen stutter.
4. Manufacturer customizations. Some manufacturers' skins handle battery optimization, notifications and background services differently from stock Android.
5. User display settings. Font size, display size, dark mode, and gesture versus three-button navigation all affect layout.

You do not control which phones your testers own, so the goal is to get as much spread across these five variables as you reasonably can, and to record what each tester used.

Step 1: Write down your own boundaries

Open your build file and note your minSdk and targetSdk. Your minimum version is the oldest Android release you promise to support. If you set it low, you are promising behavior on versions you may never have run.

Write a three-line note for yourself:

• Oldest Android version I claim to support.
• Newest Android version I have actually run the app on.
• Smallest and largest screen I have seen the app on.

The gaps between those lines are your risk. If you have never run the app on anything older than Android 12 but your minSdk goes lower, that is the first thing to ask testers about.

Step 2: Do an emulator pass before you upload

Emulators are not a replacement for real phones, but they are good for cheap layout checks. Before uploading your closed test build, create a few Android Virtual Devices in Android Studio:

• One at your minimum supported version.
• One at the newest version you target.
• One small-screen phone and one tablet or foldable profile if your app is meant to run on them.

On each, check the first-run flow, rotate the screen, and increase the system font size. Fixing a clipped layout now saves a tester from reporting it.

Step 3: Check your device catalog in Play Console

Play Console shows which devices your app is compatible with based on your manifest, and lets you exclude certain devices if you have a good reason. The exact screens and options can change, so check Play Console Help for the current wording before you rely on a specific menu path.

Two things to look for:

• Is the number of supported devices lower than you expected? A manifest requirement like a specific hardware feature may be excluding phones you meant to support.
• Are you excluding devices to hide a bug? That is a short-term patch. Fix the bug if you can.

Step 4: Ask testers for device details every time

A bug report without a device is much harder to act on. Make the details part of your feedback form, so testers never have to guess what you need. Ask for:

• Phone brand and model.
• Android version (found in Settings, About phone).
• Whether they use dark mode, a large font size, or gesture navigation.
• What they were doing when the issue happened.
• A screenshot if the problem is visual.

With TesterMob, testers use their own Android phones and give written feedback, so this kind of detail is easy to request in your testing instructions. Your developer page explains how the process works, and you can put the device question right at the top of your instructions.

Don't assume you can request a specific model or Android version. Testers use whatever phone they already own. If you need something particular, ask the team through the contact page rather than planning around it.

Step 5: Give testers small, specific device tasks

The default instruction, "use the app for 20 minutes a day", does not make testers look at layout edge cases. Add one small task per day or two. A few examples:

Display tasks

• Switch to dark mode and open the three main screens. Does any text become unreadable?
• Increase the font size in system settings and check one form screen.
• Rotate the phone on your longest list screen. Does scroll position or typed text survive?

Navigation tasks

• Use the system back gesture from every screen. Does it behave as expected?
• Check that no button sits behind the navigation bar or camera cutout.

Lifecycle tasks

• Switch to another app for a few minutes, then come back. Is the app where you left it?
• Open the app after the phone has been idle for a few hours.

These are quick, and a tester can finish one inside their normal session. They also produce concrete reports instead of "it works fine".

Step 6: Read the reports by pattern, not by volume

With about 12 testers, you will not have statistical coverage of anything. Treat each report as a lead, not a proof. Sort what you receive:

1. Same problem on different devices. Likely a real bug in your code. Fix first.
2. Problem on one device only. Could be device-specific. Try reproducing it with an emulator at the same Android version and screen size before deciding.
3. Problem only with unusual settings. Large fonts or a small display are still real users. Fix it if it blocks a core task.
4. Vague reports without a device. Reply and ask for the details. Do not guess.

Fixes you make based on this feedback are worth shipping as a new build during the test. See our blog for more on timing updates and handling crash reports.

When to raise your minimum version

If testing shows that your oldest supported Android version is unstable and you cannot realistically fix it, raising minSdk is a legitimate choice. It narrows your audience, so weigh that against the effort to fix. Decide deliberately and note the reason, rather than letting a hidden crash on an old version reach production.

What this will not do

A device coverage plan reduces surprises. It does not prove your app works on every phone, and it does not guarantee production approval. Google makes that decision, and its requirements can change, so check Play Console Help for the current rules. TesterMob is not affiliated with Google and cannot promise an outcome.

If you are still deciding how to get your 12 testers opted in for 14 days in a row, see pricing for the one-time $9.99 per app fee, or the FAQ for common questions.

A quick checklist

• Note your minSdk, targetSdk, and the versions you have actually run.
• Run emulators at minimum and newest versions, plus a small and a large screen.
• Review your device catalog in Play Console for unexpected exclusions.
• Ask every tester for model, Android version and display settings.
• Assign one small display or lifecycle task at a time.
• Look for patterns across devices before deciding what to fix.