In this guide
"Support Android 8 and up" is advice repeated so often that it sounds like a rule. It is not a rule. The minimum version your app supports (often called minSdk) is a decision with a cost on both sides, and it should come from your own data and risk.
Google Play also sets requirements for the API level your app must target when you publish a new app or an update. That is a different setting from the minimum, and the required level and deadlines change over time, so read the current table on Google's target API level page before you plan a release.
What the choice actually trades
- A lower minimum reaches more devices, but means more old behavior to test, more compatibility code, and fewer modern features you can use directly.
- A higher minimum is simpler to build and test, but some people cannot install the app at all.
Neither is right in general. This is why a made-up percentage from a blog post is useless to you. Your audience is not the average audience.
Step 1: find your own numbers
Look at what you have, in this order:
- Your current users, if the app is already live. In Play Console, the Statistics page can break your users down by Android version (use the "View by" option in the report configuration), and your analytics tools may show it too. Menu names change, so check the console's current help.
- Your target audience, if you are not live yet. A banking app for older phones in one country differs from a game for recent hardware. Write down who they are and what they use.
- Your testers. They tell you what phones real people hold. Ask them in the test form.
- Public distribution figures, from Google's own pages, as rough background only. Google's public distribution dashboard describes devices on Google Play, not your users, and points to the Reach and devices report in Play Console for version breakdowns. Check the date on any figure, and treat numbers as unknown until you have looked them up yourself.
Step 2: list what you give up
For each candidate minimum version, write two lines:
- Users lost: the share of your users, or your guess, on versions below it.
- Work saved: features, libraries, testing time and bug risk you avoid.
If you have no data, write "unknown" and move on to the next step. An honest unknown is better than an invented figure.
Step 3: check what your libraries require
Your dependencies set their own minimums. A library you need may rule out an old version for you. Check each one before you decide.
Step 4: decide with a worksheet
Copy this and fill it in:
| Question | Your answer |
|---|---|
| Is the app live? Do I have real version data? | |
| Lowest version my users run | |
| Share of users below my candidate (or unknown) | |
| Features I need that require a newer version | |
| Libraries with a higher minimum | |
| Devices I can test on | |
| Decision and date |
Decide, write down the reason, and set a date to review it, for example with each major release.
Step 5: test what you promise
Whatever minimum you choose, you must run the app on it. Test on the lowest and the newest version at least. Emulators help here, because you can create old versions without owning the phone. See which Android devices to test on for covering real hardware.
Raising the minimum later
You can raise it when the share of users on old versions is small and the cost of keeping them is high. Check your data first, and say so in your release notes. Existing users on unsupported versions may stay on the old app version, so confirm what happens in the store's current rules.
Related
- Hub: Android app testing: devices, versions and checks
- Testing Android screen sizes: phones, tablets and foldables
- Android dark mode testing checklist
Testers on AppReviewX use phones and system versions you do not own, and tell you privately and in a structured way what broke. See how AppReviewX works.