Google Play target API level deadlines: why an app nobody touched can stop reaching new users

What Google Play requires today

The rule is about one number in your build: the target SDK version, also called the target API level. It tells Android which version's behaviour your app has been tested against. Android's developer docs explain why it matters: some platform changes only apply to apps that declare support for them through that setting, so a low target keeps an app on older rules.

As of today, the Play Console Help page on target API level requirements says that from August 31, 2026, new mobile apps and app updates must target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users. Wear OS, Android Automotive OS, Android TV and Android XR apps have their own, lower levels on the same page. Google offered an extension to November 1, 2026, requested through Play Console, and that date has now passed.

The one exception listed is permanently private apps, restricted to users in a specific organisation for internal distribution.

How an untouched app quietly loses new users

Nothing breaks on the day. That is the problem.

Google's page says an app that targets a lower level stops being available to new users on devices running a newer Android version than the app targets. People who already installed it keep access, and can still discover, reinstall and use it. So your current users see no change, your reviews stay put, and the app looks fine from your own phone. Meanwhile anyone who buys a new phone running a recent Android version cannot install it from the store.

The second trap comes later. Updates must meet the higher level for new apps and updates. If your app has drifted two versions behind, even an urgent one-line bug fix cannot ship until the target is raised and the app is tested against the behaviour changes in between. A small fix becomes a migration, on a deadline you did not choose.

My rule: raise the target every year as planned work, so it is never bundled with an emergency. On the current page, the last two deadlines both fell on August 31. I would put the upgrade in the calendar for the spring and check the page again then, since Google sets each year's levels and dates.

The yearly upkeep checklist I would run

This works for a Flutter app or a native one. In Flutter, the Android target lives in the Gradle file of the app module, and the plugins you use bring their own native Android code that must support the new level too.

• Read the Play Console Help page on target API levels and note the new level and date for your app type.
• Check Play Console for policy warnings and Notifications about your app's target level.
• Update Flutter, or your Android Gradle tooling, to a version that builds against the new API level.
• Update every plugin and SDK, and confirm each one supports the new target. Android's docs say to work with any SDK provider that does not.
• Raise targetSdkVersion and read Android's behaviour change page for every version you are crossing.
• Test permission flows by denying each permission and checking the app does not crash.
• Test push notifications, background work and file sharing, which the behaviour changes often touch.
• Ship the build to a closed or internal test track first, then roll out to production.
• Review your Data safety answers in the same release, in case updated SDKs collect something new.
• If you will not maintain the app any more, decide whether to unpublish it, which Google's page names as an option.

Who does this work, and what it costs

My Launch ($999), Growth ($1,699) and Scale ($2,500) packages cover building and publishing the app. Ongoing maintenance is not included, and that includes the yearly target upgrade. I say this up front because an Android app is never finished for good: Google raises the bar on a schedule you do not control.

If your app has fallen behind, send me the repository and the Play Console warning. I will tell you how many Android versions it has to cross, which plugins need replacing and what the work involves, so you get a fixed scope before anything starts.