Android 16 Target API Deadline: What to Test Before August 31

The August 31 Google Play deadline is easy to misread as an upload setting. It is really two jobs: meet Play’s submission rule, then make sure the app behaves honestly when Android 16 turns on the behavior changes attached to API 36. A rushed targetSdk bump can clear the console and still leave a broken back gesture, a clipped edge-to-edge screen, or a tablet layout that no longer matches the screenshots in your listing.

Google’s current target API requirement says that from August 31, 2026, new mobile apps and updates must target Android 16 (API 36) or higher. The same page says an extension to November 1 will be available in Play Console later this year if you genuinely need more time. Do not plan your release around that extension: it is a contingency, not a migration strategy.

The deadline, split by app type

The API 36 floor applies to new mobile submissions and updates. Existing app visibility has a separate API 35 floor, so delaying an update can still restrict discovery on newer devices.

Do compatibility testing before you change targetSdk

Google’s Android 16 migration guide makes an important distinction. First test the published build on Android 16 for changes that affect all apps. That can reveal crashes or broken flows without changing your current target. Then update compileSdk and targetSdk, enable the targeted changes, and test the same paths again. This separates platform compatibility work from API-36 opt-in behavior.

1. Install the current release on an Android 16 device or emulator and complete the actual first-session journey.
2. Review Android 16 changes that affect every app, then record crashes, layout bugs, and SDK warnings before changing your target.
3. Update the Android toolchain and set compileSdk to 36. Upgrade the Android Gradle plugin first if your project needs it.
4. Set targetSdk to 36 in a branch, then enable targeted compatibility changes one at a time where possible.
5. Test sign-in, permission prompts, purchase and restore, notifications, shares, deep links, background work, and every screen you show in store art.
6. Run the signed release build, not only a debug build, on a phone plus a tablet or foldable if your app supports them.
7. Upload a carefully checked bundle to the right Play testing track before production.

Android 16 changes most likely to show up in a small app

Not every Android 16 behavior change applies to every product. The high-leverage check is to map the change to an app flow you own. A media picker app has different risks from a simple habit tracker; an app with a tablet layout has different risks from a phone-only utility. These are the common ones worth putting on a short test sheet.

The API 36 migration is mostly about testing your own affected flows. Edge-to-edge, back navigation, and large-screen layouts deserve visual QA because a code-clean update can still look unfinished to a customer.

For the exact conditions and temporary large-screen opt-out, use Google’s behavior changes for apps targeting Android 16 . The opt-out is described as temporary, so it should buy testing time—not become the permanent product decision.

Update the build configuration deliberately

For a conventional Gradle setup, API 36 means compileSdk = 36 and targetSdk = 36. That change can surface dependency, build-tool, and behavior issues, which is why it belongs in a release branch with a short written test plan. The Android 16 SDK documentation also notes that the Android SDK Upgrade Assistant can surface context while you make the change.

android {
  compileSdk = 36

  defaultConfig {
    targetSdk = 36
  }
}

Do a storefront QA after the build passes

A target API release is a useful moment to audit the listing with fresh eyes. If the update changes system bars, tablet behavior, permission UI, or a headline interaction, do not leave outdated screenshots presenting a different app. You do not need to rebrand the page; you need the first three frames, caption claims, and platform screenshots to remain true.

• Capture the Android 16 build with real status bars and navigation in the state customers will see.
• Check that a first screenshot still explains the app before a platform change becomes visible.
• Replace any tablet, foldable, or landscape asset that now shows clipped or artificially constrained UI.
• Keep the Google Play feature graphic campaign-safe; it should support the listing story, not pretend to be product UI.
• If you changed a core flow, revisit the video and the screenshot sequence before the production rollout.

Sources, verified 2026-08-19:

• Android Developers — Meet Google Play target API level requirements
• Android Developers — Migrate apps to Android 16
• Android Developers — Behavior changes for apps targeting Android 16
• Android Developers — Set up the Android 16 SDK