Google Play Target API 36 in 2026: Deadline, Extension and a Flutter Upgrade Plan for Solo Developers

By giosaia (GSPTeck) · Published 2026-10-09 · Last verified 2026-10-09

Google Play's yearly target API deadline passed on August 31, 2026. If you ship Flutter apps on your own, as I do with CoinDrop, Swappr and IOU, that date decides whether your next update is accepted and whether new users on recent Android versions can still find your older apps. This guide summarizes what the rule says for 2026, what the November 1 extension means, and the practical Flutter upgrade path to Android 16 (API level 36): toolchain, Gradle config, plugins, and the Android 16 behavior changes most worth testing. Everything here is taken from Google's own documentation, checked on 2026-10-09.

What the 2026 target API rule actually says

Google's developer page Meet Google Play's target API level requirement (last updated 2026-10-01) states that starting August 31, 2026:

• New apps and app updates must target Android 16 (API level 36) or higher to be submitted. The exceptions are Wear OS and Android Automotive OS apps, which must target API 35, and Android TV and Android XR apps, which must target API 34.
• Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running a newer Android version than the app targets. An app targeting API 34 or lower is only offered to devices running the same or a lower Android version.
• Extensions: if you need more time, you can request an extension to November 1, 2026 through forms in Play Console.

Two practical readings for solo developers. First, the hard stop is on updates: an app that still targets API 35 keeps working for people who already have it, but you can't publish a bug fix until you target 36 (or until your extension runs out). Second, an app you haven't touched in two years may already be invisible to new users on current phones. The Play Console Help article on target API level requirements has the details on app availability, and Play Console flags affected apps on the dashboard.

Step 1: triage your apps

Before touching code, list every app in your Play Console and note three things: its current targetSdk, when you last published an update, and whether you expect to ship an update before November 1. That gives you three groups:

• Active apps you'll update soon: upgrade to API 36 now. If you're mid-release and need breathing room, request the extension, but treat November 1 as a real deadline.
• Stable apps with no planned update: check they target at least API 35 so new users can still install them. If not, schedule a maintenance release.
• Apps you're retiring: decide deliberately. An app that drops out of new users' reach still has existing users who may need a privacy-policy or account-deletion path. I covered those obligations in product ops after launch: Play Console and privacy.

Step 2: upgrade the Flutter toolchain and Gradle config

In a standard Flutter project, the Android SDK versions live in android/app/build.gradle.kts (or build.gradle in older projects). The Flutter Android deployment guide shows the default block, where targetSdk = flutter.targetSdkVersion and compileSdk uses Flutter's default too. Flutter manages those defaults to stay compatible with the framework and plugins, so the cleanest route is usually:

1. Run flutter upgrade on a branch, then flutter doctor, and install the Android 16 SDK platform in Android Studio's SDK Manager.
2. Check what flutter.targetSdkVersion resolves to on your Flutter version. If it's still below 36, set targetSdk = 36 and compileSdk = 36 explicitly.
3. Update the Android Gradle Plugin and Gradle wrapper to versions that support API 36. Google's Android Gradle Plugin release notes list the maximum supported API level per AGP version.
4. Read Flutter's breaking changes page for every release you skipped. Jumping several versions at once is where most surprises come from.

Step 3: plugins and dependencies

Most build failures after a target bump come from plugins, not your own code. Run dart pub outdated and upgrade the plugins that touch Android APIs first: notifications, permissions, camera, in-app purchases, ads, background work. Read each plugin's changelog for “Android 16” or “API 36” notes. Firebase plugins usually move together, so upgrade them as a set. A plugin that hasn't been updated in a long time and touches the back button, window insets or intents is a candidate for replacement.

Step 4: test the Android 16 behavior changes

Targeting API 36 opts your app into behavior changes listed in Google's Android 16 behavior changes for apps targeting 16. The ones most likely to affect a typical Flutter app:

• Edge-to-edge opt-out is going away. Android 15 enforced edge-to-edge but allowed an opt-out attribute. For apps targeting 16, that attribute is deprecated and disabled. Check every screen for content hidden under the status bar, navigation bar or display cutout. Flutter's SafeArea and MediaQuery.paddingOf are your friends; Google's edge-to-edge guide explains the system side.
• Predictive back is on by default. On Android 16 devices, the system back animations are enabled, onBackPressed isn't called and KEYCODE_BACK isn't dispatched. If you intercept back, for example with WillPopScope in old code, move to PopScope and test it. See Google's predictive back guide.
• Orientation and resizability locks are ignored on large screens. On displays with a smallest width of 600dp or more, orientation, resizability and aspect-ratio restrictions no longer apply. A portrait-locked app will be shown full-window on tablets and foldables, so make sure layouts don't break when wide.
• Safer Intents. Android 16 continues a multi-phase effort to tighten intent resolution. If you use deep links or explicit intents to other apps, re-test them. My notes on App Links and Universal Links in Flutter cover link verification.

Step 5: release carefully

Upload the new build to the internal testing track first and read the pre-launch report, which runs your app on real devices and surfaces crashes and accessibility issues. Then release to production with a staged rollout, starting small. Watch crash and ANR rates in Android vitals and Crashlytics for a couple of days before widening it; I describe my routine in a weekly Crashlytics triage cadence. If something risky needs to ship anyway, put it behind a flag, as in Remote Config kill switches, so you can turn it off without another release. After release, watch Android vitals for a jump in crash or ANR rate; our Android vitals thresholds guide for indie Flutter apps includes a 20-minute weekly check.

A note on the calendar

In recent years Google has raised the required target level each August, with an extension window into the autumn, and the 2026 rule follows that pattern. Putting a recurring reminder in early summer to bump the target, upgrade Flutter and test on the new Android release saves a lot of October stress. It's the same reason I keep backups and secret rotation on a schedule rather than waiting for an incident.

FAQ

Do I have to target API 36 right now?

To publish new apps or updates, yes, unless you've been granted an extension to November 1, 2026. Existing apps only need API 35 to stay available to new users on newer devices.

Will my old app disappear from Google Play?

Not for existing users. An app below API 35 stops being offered to new users on devices running a higher Android version than it targets.

Is changing targetSdk enough?

No. Raising the target opts you into new behaviors, so test edge-to-edge, back navigation, large screens and intents before you release.

Where do I request the extension?

In Play Console. Google says the extension forms are available there; look for the target API notice on your app's dashboard.

Sources

• Android Developers: Meet Google Play's target API level requirement
• Play Console Help: target API level requirements
• Android 16 behavior changes
• Flutter: build and release an Android app

More notes for solo developers: all GSPTeck articles.