In 2026 an Android app should target Android 16 (API level 36) because Google Play requires it for new apps and updates from 31 August 2026, and it should support Android 14 as its minimum unless your own analytics show a meaningful share of users on older devices. Those are two different decisions. The target version is a compliance deadline set by Google; the minimum version is a commercial judgement about who your users are and what each extra old version costs you in testing and workaround code. This article separates them, gives the 2026 numbers, and explains what became of the Android release it was originally written about.
Two settings, two different questions
Every Android app declares two version numbers, and owners routinely treat them as one.
- Target SDK The version of Android your app is built and tested against. It tells the operating system which behaviour rules to apply. Google Play sets a floor for it and moves that floor every year.
- Minimum SDK The oldest version of Android your app will install on. Nobody mandates it. It decides how many devices can run the app and how many old-version quirks your team has to code around.
Raising the target is not optional and does not shrink your audience. Raising the minimum does shrink it, by a measurable amount you can read off your own analytics, in exchange for a smaller test matrix. Keep the two decisions apart and both become easy.
The target version: what Google Play requires in 2026
Google's published requirement, effective 31 August 2026, is exact: "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher."
For apps already in the store, the same page says: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level." An app left on an older target does not disappear, but it stops being installable by people on new phones, which for most consumer products is the same thing as disappearing. Google also states that an extension to 1 November 2026 can be requested for apps that need more time.
The practical consequence: an app that has not shipped an update since mid-2025 is now behind a moving wall, and the update that catches it up is not a formality. Each new target level enforces new behaviour around permissions, background work, notifications and storage, and code written for Android 12 or 13 frequently breaks under Android 16 rules until it is revisited. That is the work, and it recurs every year. It is one of the standing costs in what it costs to run an app after launch.
The minimum version: read your own numbers first
The global picture in 2026 is more fragmented than most owners expect. StatCounter's June 2026 figures put Android 16 at about 23.6 percent of Android web traffic. Android 17 was released on 16 June 2026 and was on roughly one percent of phones by August, according to an August 2026 report by a security news publication, which also found that only about 56.7 percent of Android phones were running a version still receiving security updates, meaning Android 14 or later. Android 13 reached end of life on 2 March 2026 and, per heise, still held about 13.9 percent share at the end of 2025.
Two things follow. First, the global figures are not your figures. Australian consumer apps skew towards newer devices than the world average, and a business-to-business app deployed on company-issued phones may skew newer still. Pull the Android version breakdown from your own analytics before deciding anything. Second, "supported by Google" is a reasonable default for your minimum, because a device that no longer receives security patches is a device you cannot fully vouch for when it handles your users' data.
The default we recommend for a consumer app starting or updating in 2026 is a minimum of Android 14 (API level 34), which covers the supported population, with Android 13 included only where analytics show it still carries a share you cannot afford to lose. Android 12 and below should be a deliberate exception with a business reason attached, not an inherited setting nobody has looked at.
What each extra old version actually costs
There is no licence fee for supporting an old version. The cost is in three places, and it compounds.
- Testing Every supported version is another row in the device matrix for every release. Quality assurance on real devices is the discipline that keeps our first-time store approval rate at 98 percent across 100+ shipped products, and the matrix is what that discipline costs.
- Workaround code Features that behave differently on old versions need branches, fallbacks and sometimes duplicate implementations. That code has to be maintained after the version it exists for has left your audience.
- Constrained design An interface that must also work on a five-year-old device cannot use what newer versions offer, so the whole product is held to the oldest supported baseline.
Unsupported-version debt is one of the patterns we see in rescue work. When we rescued the Move With Us platform, which serves 200,000+ users, crash rates reduced 50 percent and app performance improved 40 percent, and a large part of that was retiring code paths that existed for devices the audience had long since replaced. The fix was not clever; it was removing what nobody used.
What this article said in 2017, and what became of it
This post was first published on 22 August 2017, the day Google released Android 8.0 Oreo. It celebrated notification dots, a redesigned settings menu, Google Play Protect and, almost in passing, the new limits on what apps could do in the background.
The background limits were the part that mattered. Oreo's restrictions on background execution and implicit broadcasts were the first of a long series of constraints that every subsequent version has tightened, and they are the reason a target-version update is real engineering work rather than a version bump. Notification dots became ordinary. Play Protect became the baseline of Android security tooling. The cookie-brand partnership and the eclipse-day launch event are trivia. The decision that outlived the article is the one owners still get wrong: not which Android is newest, but which versions your product should stand on.
A practical policy for 2026
- Target Android 16 now It is required for any update after 31 August 2026, and the behaviour changes it enforces are easier to absorb in a planned release than in an emergency one.
- Set the minimum from your analytics Default to Android 14; add Android 13 only for a share you can name; treat anything older as an exception with a reason.
- Review both once a year Google moves the target floor annually and the installed base moves with it. A version policy set in 2024 is already wrong.
- Budget the update as engineering Permissions, background work, notifications and storage rules change with every target level. Plan a test pass on real devices, not a recompile.
If you are choosing between building for Android at all or starting with iOS, that is a different question, answered in Android vs iOS: choosing the right platform. The version decision also depends on whether the app is native or cross-platform, because the frameworks set their own floors. And a target-version update is a common reason an app is rejected at review when it is left too late.
If your Android app has not shipped an update in the last twelve months, it is almost certainly behind the 31 August requirement. Our custom app development team can audit where it stands and what the update involves. Book a discovery call.