Google Play's August 31, 2026 Deadline: How to Upgrade Flutter Apps to Android API 36

If your Flutter app needs a Google Play update after August 31, 2026, check its Android target SDK now.

Google Play's current target API policy says new apps and app updates must target Android 16, API level 36, or higher from August 31, 2026. Existing phone and tablet apps need to target at least Android 15, API level 35, or Google Play will limit their availability to new users on Android versions newer than the app's target.

For a Flutter project, changing __INLINE_CODE_0__ to 36 is only the beginning. Android 16 activates target-dependent behaviour that can expose layout, navigation, large-screen, background-work, intent and plugin problems.

A sensible migration is:

Inventory
   ↓
Toolchain and dependency upgrade
   ↓
Target API 36
   ↓
Android 16 behaviour testing
   ↓
Plugin/native-code verification
   ↓
Play test track
   ↓
Production rollout

The goal is not merely to make Play Console accept the bundle. It is to make sure the API-36 build still works after Google accepts it.

What exactly changes on August 31, 2026?

Google Play applies two different thresholds.

According to Google's current target API level requirements, starting August 31, 2026:

• new Android phone and tablet apps must target Android 16/API 36 or higher
• updates to existing phone and tablet apps must target Android 16/API 36 or higher
• existing apps need to target Android 15/API 35 or higher to remain available to new users on devices running Android versions newer than the app's target API level

The platform-specific exceptions are different:

For a normal Flutter mobile application published to phones and tablets, API 36 is the update requirement that matters.

API 35 and API 36 are not interchangeable

If your existing app targets API 35, it may remain discoverable to new users under the availability rule.

But that does not mean you can submit a new phone/tablet update targeting API 35 after August 31.

For new submissions and updates:

Target API 36.

For existing-app visibility:

Target at least API 35.

That distinction matters when deciding whether an old app needs an emergency release or whether its next planned update simply needs to be migrated properly.

How do I check a Flutter app's current target SDK?

Start with the Android build configuration.

Depending on project age, inspect:

android/app/build.gradle

or:

android/app/build.gradle.kts

A current project may use Flutter-managed values:

android {
    compileSdk = flutter.compileSdkVersion

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
    }
}

Older projects may contain explicit values:

compileSdkVersion 34

defaultConfig {
    targetSdkVersion 34
}

Also inspect the actual release artifact rather than trusting one source file. Product flavours, Gradle scripts and CI variables can override defaults.

Useful baseline commands include:

flutter --version
flutter doctor -v
flutter pub outdated

The real question is:

What target SDK does the AAB you intend to upload actually declare?

Should Flutter itself be upgraded before targeting Android 16?

For most maintained projects, yes.

Current Flutter documentation supports modern Android SDK levels, and recent Flutter releases contain Android 16-related framework and engine changes. Flutter's current Android setup guide also instructs developers to install API level 36.

Trying to move a years-old application to target 36 while preserving old Flutter, Gradle, Android Gradle Plugin, Java and abandoned plugins creates several variables at once.

A safer sequence is:

1. record the current production build state
2. create a migration branch
3. upgrade to a currently supported Flutter stable release
4. run __INLINE_CODE_0__
5. update dependencies deliberately
6. update Android tooling where needed
7. get the app building cleanly
8. target API 36
9. test Android 16-specific behaviour

Avoid combining this migration with a major feature release if possible.

Install and verify the Android 16 SDK

Flutter's current Android setup guide tells developers to install an Android SDK platform with API Level 36.

In Android Studio:

Tools
  → SDK Manager
    → SDK Platforms
      → API 36

Keep the relevant build tools, platform tools, command-line tools, emulator, CMake and NDK current where your project uses them.

Then run:

flutter doctor

and make sure you have an Android 16 emulator or physical device available.

If the toolchain is not healthy, fix that before debugging app behaviour.

Why can changing __INLINE_CODE_0__ break an app that already runs on Android 16?

Android has two classes of changes:

1. changes affecting all apps running on Android 16
2. changes activated only when an app targets Android 16/API 36

Google publishes separate documentation for both.

This test:

Old target SDK + Android 16 device → works

does not prove:

Target API 36 + Android 16 device → works

Google's Android 16 migration guide recommends testing the target-dependent changes and using compatibility toggles where useful.

Those toggles let teams isolate particular Android 16 behaviours before changing the final target SDK, which is especially useful in older or complex Flutter applications.

Migration risk 1: edge-to-edge becomes unavoidable

Android 15 introduced enforced edge-to-edge for apps targeting API 35 while retaining an opt-out.

For apps targeting Android 16/API 36 on Android 16, Google says the edge-to-edge opt-out is disabled. Flutter's own edge-to-edge migration documentation reflects this.

Typical regressions include:

• buttons behind the navigation area
• app bars under the status bar
• bottom sheets too close to gesture areas
• full-screen screens gaining unexpected spacing
• custom platform views using incorrect insets
• authentication or splash screens appearing vertically shifted

Review screens using:

• custom __INLINE_CODE_0__ positioning
• manually placed floating controls
• full-screen video/images
• bottom navigation
• __INLINE_CODE_0__
• custom Android activities
• native platform views

Use __INLINE_CODE_0__ where the design genuinely needs protected content, but do not wrap the entire application blindly.

A good rule is:

Backgrounds may extend edge-to-edge; essential content and controls must respect the actual system insets.

Migration risk 2: predictive back changes navigation assumptions

For target-36 apps on Android 16, predictive back behaviour becomes more important and older interception patterns can fail.

Google's target-36 behaviour changes says legacy back handling changes for affected apps. Flutter has also moved toward ahead-of-time navigation APIs for predictive back.

Flutter's predictive-back migration guide replaces older __INLINE_CODE_0__ patterns with APIs such as __INLINE_CODE_1__.

Search older Flutter projects for:

WillPopScope

and test flows such as:

• unsaved forms
• checkout/payment
• onboarding
• wizards
• nested navigators
• in-app browsers
• modal routes
• confirmation dialogs

Do not test only an AppBar back button.

Test the actual Android back gesture, nested routes and dialogs.

Migration risk 3: large-screen restrictions may no longer save a phone-only layout

Android 16 changes how orientation, resizability and aspect-ratio restrictions behave on large displays for apps targeting API 36.

Google says restrictions can be ignored on displays with a smallest width of at least 600dp. A temporary compatibility opt-out exists for API 36, but it is not a permanent design strategy.

That matters because users may run a "phone app" on:

• tablets
• foldables
• ChromeOS
• desktop-style Android windows
• split-screen

Common Flutter problems include:

• portrait-only assumptions
• overly wide forms
• fixed-column grids
• dialogs stretched across large displays
• hard-coded dimensions
• dashboards with huge empty areas
• camera/game layouts that depend on forced orientation

A simple responsive model is often enough:

Compact
→ phone layout

Medium
→ constrained-width content

Expanded
→ multi-column or rail layout

The app does not need a complete tablet redesign to pass the migration. It needs to remain usable when Android stops protecting old layout assumptions.

Migration risk 4: plugins are part of the Android app

Many Flutter packages contain native Android code.

High-risk categories include:

• camera
• maps
• push notifications
• geolocation
• background services
• Bluetooth
• NFC
• WebView
• payments
• analytics
• deep links
• biometrics
• media
• storage/file handling
• platform views

Run:

flutter pub outdated

Then review the changelog and Android support state of important native plugins.

A healthy upgrade loop is:

Identify native-risk plugin
        ↓
Read migration notes
        ↓
Upgrade
        ↓
Build
        ↓
Test the actual feature

Do not stop testing because the application reaches the home screen.

Migration risk 5: Android 16 changes can affect all apps

Google's Android 16 changes affecting all apps contains behaviour changes that apply even before the target SDK reaches 36.

Depending on the app, these can affect runtime, background scheduling, companion-device flows, virtual-device environments, accessibility or dependencies that use platform internals.

For Flutter teams, problems can originate from:

Dart app code
Flutter framework/engine
third-party native plugin

That is why both Android 16 runtime testing and API-36 targeted testing matter.

What about 16 KB page-size support?

This is a separate Google Play compatibility requirement, but an API-36 migration is a good moment to verify it.

Google Play has required qualifying new apps and updates targeting Android 15/API 35 or higher to support 16 KB memory page sizes since November 1, 2025.

This matters mostly when the application includes native code or native libraries. Flutter itself and plugins can contribute __INLINE_CODE_0__ libraries.

Google's current 16 KB page-size guidance explains the requirement and testing process.

If a native library is incompatible, the fix may be updating a plugin or native dependency rather than changing Dart code.

A safe Flutter API-36 migration sequence

Step 1: preserve a known-good baseline

Record:

• Flutter/Dart version
• Java version
• Gradle/AGP version
• compile and target SDK
• plugin versions
• signing setup
• last reproducible production build

Use a dedicated migration branch.

Step 2: upgrade the toolchain

Run:

flutter doctor -v
flutter pub get
flutter analyze
flutter test

Fix build and analysis failures before changing application behaviour.

Step 3: update dependencies

Prioritise plugins containing Android native code. Avoid blind major-version upgrades.

Step 4: target API 36

Follow current Flutter project conventions and confirm the final release artifact declares API 36.

Avoid old Gradle snippets copied from outdated tutorials.

Step 5: test target-dependent changes

At minimum test:

• edge-to-edge
• predictive back
• large-screen/resizable behaviour
• affected intents/security flows
• relevant background work

Step 6: test native integrations

Use a product-specific feature matrix:

Step 7: build and upload to a test track

For a standard Flutter release:

flutter build appbundle --release

Use Play internal or closed testing before production.

Step 8: test older supported Android versions too

API-36 behaviour is most visible on new Android versions, but Flutter/toolchain/plugin upgrades can regress older versions.

A production migration therefore needs both:

new Android behaviour testing
+
backward compatibility testing

Can Google Play grant an extension?

Google's target API documentation says developers can request an extension for existing apps that need more time, with the extension covering availability requirements until November 1, 2026.

Do not treat this as the default release strategy.

The August 31 submission requirement should be planned as the real deadline. An extension is more useful for older existing apps facing availability issues while remediation is underway.

If your business expects Android releases during September or October, finishing the API-36 migration now is much safer.

What if the Flutter app has not been updated for years?

An old app needs a maintenance audit before anyone promises this is a one-line change.

A migration may combine:

old Flutter
+
old Gradle/Java
+
abandoned plugins
+
deprecated Android APIs
+
legacy navigation
+
old permissions
+
target SDK jump

Before estimating the work, inspect:

• Flutter/Dart age
• Android Gradle Plugin compatibility
• abandoned packages
• native Android modifications
• Firebase/Google SDK age
• signing/release access
• reproducibility of the current build
• current Play Console warnings

For neglected applications, the deadline often reveals maintenance debt rather than creating it.

How is this different from Android developer verification?

These are separate Google requirements.

An app can pass one and fail the other.

For example:

API 36 ✅
Developer/package registration ❌

or:

Developer verification ✅
API 34 ❌

Treat both as release-readiness checks, not as one policy.

A two-deadline Android release checklist

Application compatibility

• target API 36 for phone/tablet updates
• Android 16 tested
• edge-to-edge verified
• predictive back verified
• tablet/foldable behaviour checked
• native plugins updated and tested
• 16 KB native-library compatibility checked where relevant

Distribution identity

• Play Console ownership known
• Android developer verification status checked
• package names registered where required
• signing keys/fingerprints understood
• outside-Play distribution included in the verification plan

This is a stronger release posture than treating each Play warning as a separate emergency.

FAQs

What target SDK does Google Play require after August 31, 2026?

For normal Android phone and tablet apps, new apps and updates must target Android 16/API 36 or higher. Existing apps need API 35 or higher to remain available to new users on Android versions newer than the app's target.

Does upgrading Flutter automatically make my app target API 36?

Do not assume so. Current Flutter releases support modern Android targets, but project configuration, flavours, old templates or CI overrides can affect the actual release artifact. Verify the AAB.

Can I just change __INLINE_CODE_0__ from 35 to 36?

The project may compile, but targeting API 36 activates Android 16 behaviour changes. Test edge-to-edge, predictive back, large-screen behaviour and native integrations.

Why does my Flutter layout change after targeting Android 16?

Android 16 removes the edge-to-edge opt-out for target-36 apps running on Android 16. Screens that relied on system bars reserving space may need proper inset handling.

Is __INLINE_CODE_0__ a problem for Android 16?

Older __INLINE_CODE_0__ navigation patterns do not support predictive back the same way as Flutter's newer ahead-of-time APIs. Flutter recommends migration toward __INLINE_CODE_1__ and related navigation APIs.

Is August 31 also the developer-verification deadline?

No. The Google Play target API deadline is August 31, 2026. Android developer verification begins its initial enforcement phase on September 30, 2026.

Conclusion

The August 31 Google Play deadline is not difficult because __INLINE_CODE_0__ is complicated to put in Gradle.

It matters because targeting API 36 activates newer Android behaviour.

For maintained Flutter apps, the path can be straightforward:

Upgrade
→ target API 36
→ test Android 16 behaviour
→ verify plugins
→ publish through a test track

For neglected applications, the same deadline can reveal years of dependency and release-process debt.

The correct finish line is not "Play Console accepted the bundle."

It is:

The API-36 build behaves correctly after Play Console accepts it.

Need to get an existing Flutter app ready for Android 16 and Google's 2026 Play requirements? Softotic's mobile app development service can handle Flutter/Android migration and release testing, while custom software development can support backend or integration changes exposed during the upgrade.

Sources and references

• Android Developers: Meet Google Play's target API level requirement
• Android Developers: Behavior changes for apps targeting Android 16 or higher
• Android Developers: Behavior changes affecting all apps on Android 16
• Android Developers: Migrate apps to Android 16
• Flutter: Set default SystemUiMode to edge-to-edge
• Flutter: Android predictive back migration