Target API Level 36: A Flutter Guide to the Play Deadline

Google Play's target API level 36 rule has applied to new apps and app updates since 31 August 2026, and the extension Google offered for it ends on 1 November 2026. If your Flutter app still targets Android 15 or lower, you can't ship an update until you move to target API level 36 (Android 16). That bump also switches on three Android 16 behaviour changes that can break a Flutter UI: edge-to-edge without an opt-out, predictive back, and tablets ignoring orientation locks. This post covers what Google requires, how to check and bump targetSdk in a Flutter project, what to test, and what to do if you missed the deadline.

What the target API level 36 rule says

Google's target API level requirements page sets two separate rules. One decides whether Play accepts your upload. The other decides who can still find your existing app.

The only exception Google lists is permanently private apps that are restricted to one organisation and distributed internally.

How to check your Flutter app's target SDK version

Run this from the project root:

grep -rnE "targetSdk|compileSdk" android/app/build.gradle*
flutter --version

If the line reads targetSdk = flutter.targetSdkVersion, the value comes from your Flutter SDK. If it reads targetSdk = 34 or targetSdkVersion 34, someone pinned it, and it won't move until you change it.

To be certain, check the built artifact. apkanalyzer from the Android SDK command-line tools prints an APK's target SDK:

flutter build apk --release
apkanalyzer manifest target-sdk build/app/outputs/flutter-apk/app-release.apk

In Play Console, non-compliant apps get a warning on the Policy status page.

Change the target SDK version to 36 in Flutter

The current Flutter app template, android/app/build.gradle.kts, reads both values from the Flutter Gradle plugin:

android {
    namespace = "com.example.myapp"
    compileSdk = flutter.compileSdkVersion

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = flutter.minSdkVersion
        targetSdk = flutter.targetSdkVersion
        versionCode = flutter.versionCode
        versionName = flutter.versionName
    }
}

On Flutter 3.35 and later, flutter.targetSdkVersion and flutter.compileSdkVersion are both 36 (see gradle_utils.dart). So the cleanest fix for most apps is to upgrade Flutter and switch any pinned values back to the flutter.* properties.

If you can't upgrade Flutter this weekend, pin the numbers yourself:

android {
    compileSdk = 36

    defaultConfig {
        minSdk = flutter.minSdkVersion
        targetSdk = 36
    }
}

Older projects use Groovy in android/app/build.gradle. The same change there is compileSdkVersion 36 and targetSdkVersion 36 (or compileSdk = 36 and targetSdk = 36 on newer Android Gradle Plugin versions).

Which Flutter versions default to API 36

I checked these against the Flutter source at each release tag. The 3.27 row comes from Flutter's edge-to-edge breaking-change page, which says apps that use flutter.targetSdkVersion have targeted Android 15 since 3.27.

What changes when a Flutter app targets Android 16

Raising the number is the easy part. Google's Android 16 behaviour changes page lists what changes once you target 36. These three matter most for Flutter apps.

Edge-to-edge can't be turned off

Android 15 made edge-to-edge the default, but you could opt out with windowOptOutEdgeToEdgeEnforcement in your styles. Many Flutter apps did exactly that to avoid a redesign. For apps targeting 36, Google says that attribute "is deprecated and disabled, and your app can't opt-out of going edge-to-edge" on Android 16 devices. It still works on Android 15 devices.

Flutter's breaking-change page warns that using the opt-out on Android 16 "might cause your app to crash". Remove the attribute and fix the layout.

In practice, Scaffold with an AppBar already pads the top, and Material's NavigationBar and BottomNavigationBar already pad the bottom. The screens that break are the custom ones: a pinned checkout button, a bottom sheet, or a full-screen page with no app bar. Wrap them in SafeArea:

class CheckoutBar extends StatelessWidget {
  const CheckoutBar({super.key, required this.onPay});

  final VoidCallback onPay;

  @override
  Widget build(BuildContext context) {
    return Material(
      elevation: 8,
      child: SafeArea(
        top: false, // only pad the bottom (and sides in landscape)
        minimum: const EdgeInsets.all(16),
        child: FilledButton(onPressed: onPay, child: const Text('Pay now')),
      ),
    );
  }
}

To get the same look on Android 15 and 16, opt in from Dart and make the system bars transparent:

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge);
  SystemChrome.setSystemUIOverlayStyle(
    const SystemUiOverlayStyle(
      statusBarColor: Colors.transparent,
      systemNavigationBarColor: Colors.transparent,
      systemNavigationBarContrastEnforced: false,
    ),
  );
  runApp(const MyApp());
}

Predictive back gesture: onBackPressed is not called

For apps targeting 36 on Android 16 devices, the back-to-home, cross-task and cross-activity animations are on by default. More importantly, Google says "onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore".

Flutter's own back handling survives this. I read the embedder source: FlutterActivity registers an OnBackInvokedCallback on Android 13 and later, and FlutterFragmentActivity uses the AndroidX OnBackPressedDispatcher. Both pass the gesture to the framework. What breaks is native code: an onBackPressed() override in MainActivity.kt, or a plugin that listens for the back key. Move that logic into Dart.

On the Dart side, WillPopScope has been deprecated since Flutter 3.16, and its deprecation message says predictive back "will not work with WillPopScope". PopScope replaces it. You decide ahead of time whether back is allowed, then react afterwards:

class _EditAddressScreenState extends State<EditAddressScreen> {
  bool _dirty = false;

  @override
  Widget build(BuildContext context) {
    return PopScope<Object?>(
      canPop: !_dirty, // true = let the system animate back normally
      onPopInvokedWithResult: (bool didPop, Object? result) async {
        if (didPop) return; // the route already closed
        final bool discard = await _confirmDiscard();
        if (discard && context.mounted) {
          Navigator.of(context).pop(result);
        }
      },
      child: Scaffold(
        appBar: AppBar(title: const Text('Edit address')),
        body: TextField(
          onChanged: (_) {
            if (!_dirty) setState(() => _dirty = true);
          },
        ),
      ),
    );
  }

  Future<bool> _confirmDiscard() async {
    final bool? discard = await showDialog<bool>(
      context: context,
      builder: (context) => AlertDialog(
        title: const Text('Discard changes?'),
        actions: [
          TextButton(
            onPressed: () => Navigator.pop(context, false),
            child: const Text('Keep editing'),
          ),
          TextButton(
            onPressed: () => Navigator.pop(context, true),
            child: const Text('Discard'),
          ),
        ],
      ),
    );
    return discard ?? false;
  }
}

For nested navigators, such as tabs that each keep their own stack, use NavigatorPopHandler instead of a hand-written WillPopScope.

If you need time, Google allows a temporary opt-out: android:enableOnBackInvokedCallback="false" on the <application> or <activity> tag in AndroidManifest.xml.

Large screens ignore orientation and resizability locks

On displays with a smallest width of 600dp or more, Android 16 ignores screenOrientation, resizeableActivity, minAspectRatio, maxAspectRatio and setRequestedOrientation() for apps targeting 36. Flutter's SystemChrome.setPreferredOrientations calls setRequestedOrientation() under the hood, so a portrait lock in Dart is ignored on tablets and most unfolded foldables. Phones under 600dp are not affected, and neither are games that set android:appCategory.

Choose layouts by window width, not by orientation:

final bool wide = MediaQuery.sizeOf(context).width >= 600;
return Scaffold(
  appBar: AppBar(title: const Text('Orders')),
  body: wide
      ? Row(
          children: [
            SizedBox(width: 360, child: ordersList),
            const VerticalDivider(width: 1),
            const Expanded(child: Center(child: Text('Select an order'))),
          ],
        )
      : ordersList,
);

Rotation also means more Activity recreation. Flutter's default manifest handles orientation|screenSize|smallestScreenSize in configChanges, but check any native screens or plugins that start their own activities. As a stopgap, add <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" /> to the activity or application.

Smaller changes worth a look

• elegantTextHeight is ignored. It is a TextView attribute, and Flutter paints its own text, so I'd only expect this to matter in native views and platform views.
• scheduleAtFixedRate now runs at most one missed execution when the app comes back. This only matters for native Kotlin or Java code.
• APIs that needed BODY_SENSORS now need granular android.permissions.health permissions, for example READ_HEART_RATE. Check any health or wearable plugin you use.

How to test before you upload

My routine for a Flutter app moving to target API level 36:

1. Run the app on an Android 16 (API 36) emulator with gesture navigation, then again with 3-button navigation. Look at every screen's top and bottom edges, including sheets, dialogs and the keyboard.
2. Swipe back on each screen that has unsaved state. On the root screen, the back-to-home preview should appear.
3. Run an Android 16 tablet or foldable emulator and rotate it. Nothing should be stretched, cut off or reset. Google also documents a compat flag for this: adb shell am compat enable UNIVERSAL_RESIZABLE_BY_DEFAULT <package>.
4. Run your widget tests at a wide size too. tester.view.physicalSize = const Size(1200, 800) is enough for a first check.
5. Upload to internal testing first, then release and check the Policy status page again.

If your app uses Play Billing, check our Play Billing Library deadline guide as well, because that extension also ends on 1 November 2026.

Missed the deadline? What happens now

If your app targets 35, it stays available to everyone, but Play won't accept your next update until it targets 36. Bump the target, test, and ship. There is nothing else to request.

If your app targets 34 or lower and the extension has ended (or you never had one), Google says the app "will stop being available to all new users whose devices run Android OS versions higher than your apps' target API levels". Someone on Android 16 who follows your store link is told the app "is not available to install on their device because it was made for an older version of Android". The fix is the same: ship an update that targets 36, and the restriction no longer applies.

That announcement does set the next dates to put in your calendar. Eligibility-based subscription discounts such as student plans must disclose their rules by 27 January 2027. The Local Network permission declaration applies to apps targeting API 37 from 25 August 2027. Both are on the Policy Deadlines page.

Checklist

• targetSdk and compileSdk are 36, either through flutter.* on Flutter 3.35 or later or set by hand
• AGP, Gradle and plugins are upgraded, and a release build succeeds
• windowOptOutEdgeToEdgeEnforcement is removed, and custom bars and sheets use SafeArea
• No native onBackPressed() logic, and WillPopScope is replaced with PopScope or NavigatorPopHandler
• Layouts work at 600dp and wider in both orientations
• Health, sensor and other native plugins are checked against the Android 16 list
• Tested on Android 16 with both navigation modes, uploaded to internal testing, and the Policy status warning is cleared

If you are also on the Flutter 3.50 beta, read our Android Intent verification guide before your next release. It is a separate change, but it lands in the same part of the app.