Android target API 36 is due Aug 31, 2026 (API 37 is next): the Play Store migration checklist

Summary. From August 31, 2026, Google Play requires every new app and every app update to target Android 16 (API level 36) or higher, according to Google's official target API level requirement page, last updated July 15, 2026. Wear OS and Android Automotive OS apps must target Android 15 (API level 35), and Android TV and Android XR apps must target Android 14 (API level 34). Existing apps that stay below API 35 will stop being discoverable to new users on newer devices, though anyone who already installed keeps the app. You can request an extension to November 1, 2026 through Play Console. The real work is not bumping one line in Gradle. It is Android 16's adaptive layout rules: on large screens 600dp and wider, API 36 apps can no longer lock orientation or aspect ratio, and the edge-to-edge opt-out is gone. A portrait-locked app that costs $25 in one-time Play Console registration can still get pulled from new-user discovery if it misses the target. This guide gives the exact requirements per form factor, what breaks, and a migration checklist you can run before the deadline.

The date matters, but the behavior changes are what will cost you time. Bumping targetSdkVersion to 36 is a one-line change. Making a portrait-only phone app behave correctly when it suddenly fills a tablet in landscape is a design and QA job. Start there, not with the manifest.

What changes on August 31, 2026

Google runs this on an annual clock. Each year, new apps and updates have to target an API level that is roughly a year old, so the platform's security and privacy changes actually reach users. August 2024 required API 34 (Android 14). August 2025 required API 35 (Android 15). August 2026 requires API 36 (Android 16). The requirement is not the same for every device type, and getting the form factor wrong is a common mistake.

Two rules run in parallel, and people confuse them. The submission rule governs what you can upload: after August 31, 2026, the Play Console will reject a new app or an update to an existing app if it targets below the level above. The availability rule governs discovery: an existing app you never update still has to sit at API 35 or higher, or Google Play stops offering it to new users whose devices run a newer Android version than the app targets.

New app, app update, and existing app are three different things

The policy uses three terms precisely, so match your situation to the right one before you plan.

The most important line is the fourth one. If you have a live app that you do not plan to update, it is not automatically safe. Once it falls below API 35, new users on devices running a newer Android release will see a store message that the app is not available for their device. Users who already installed it keep it, can re-install it, and can use it on any Android version the app supports. So the deadline bites hardest on discovery and growth, not on your current install base.

What actually breaks in Android 16

Here is where a one-line target bump turns into real engineering. Android 16, targeted at API 36, makes support for all orientations, all aspect ratios, and full resizability the baseline on large-screen devices, defined as any display whose smaller dimension is 600dp or wider. For an app that was designed portrait-only and locked that way, this is a behavior change you will see immediately.

Apps that were previously letterboxed on a tablet or a foldable will now fill the display in landscape. There is no longer a supported way to restrict an API 36 app to portrait or to a fixed aspect ratio on those large screens. The Android team has been explicit that ignoring orientation and resizability can distort layouts that assumed a narrow portrait window: stretched components, off-screen animations, and controls that land in the wrong place. If your app locks orientation with android:screenOrientation or sets a maxAspectRatio, those signals are ignored on large screens once you target API 36.

There is a temporary escape hatch. Declaring the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property opts your app out of the API 36 large-screen behavior for now. Treat it as a stopgap, not a fix. Google's direction is set: the February 2026 Android Developers post on Android 17 confirms the same resizability and orientation expectations extend to the next release, so the opt-out is buying you one cycle, not a permanent exemption.

The second change is edge-to-edge drawing. Android 15 already pushed apps toward drawing behind the system bars, and Android 16 removes the old opt-out for apps targeting API 36. Your app is expected to draw edge-to-edge and keep the status bar and navigation bar contrast legible using WindowInsets rather than assuming a fixed system-bar height. If you hard-coded insets or assumed the app owned the whole window, budget time to fix it.

The migration checklist

Run these steps in order. Most teams underestimate steps 4 and 5, which are QA-heavy, not code-heavy.

1. Confirm your current target. Check targetSdkVersion (or targetSdk) in your module-level Gradle file, or android:targetSdkVersion in the manifest. If you are already at 35, the phone and tablet availability rule is satisfied; you still need 36 to ship any update.

1. Update your SDKs and libraries first. Bump compileSdkVersion to 36 and update third-party SDKs, because an old dependency that does not support API 36 will block the build. Check each SDK's release notes or the Google Play SDK Index before you touch your own code.

1. Set the target to 36 and read the behavior-change list. Set targetSdkVersion to 36, then work through Google's "behavior changes for apps targeting Android 16" page. Not every change applies to every app; identify the ones that touch features you actually ship.

1. Fix large-screen layouts. Test on a tablet or foldable emulator at 600dp and wider. Remove orientation and aspect-ratio locks, or add PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY as a temporary measure while you redesign. Verify that portrait-first screens still work in landscape without stretching or clipping.

1. Fix edge-to-edge and insets. Confirm content draws correctly behind the system bars, that nothing important sits under them, and that bar contrast stays readable. Replace any hard-coded system-bar heights with WindowInsets handling.

1. Regression-test permissions and background work. Walk through the behavior changes for every Android version between your old target and 16, not just 16 itself. Foreground service, notification, and permission rules tightened across API 31 through 35, and skipping intermediate versions is how teams ship crashes.

1. Roll out with a staged release. Use a Play Console staged rollout and watch Android vitals for new ANRs and crashes on Android 16 devices before going to 100 percent.

1. If you cannot finish in time, file the extension. Non-compliant apps receive a policy warning in Play Console with a link to the extension form on the Policy status page. That buys distribution to November 1, 2026, not a permanent pass.

Who can take the extension, and what it does

The extension is a genuine safety valve, but a narrow one. If your app will fall below the target and you plan to update it, you can request more time and keep full distribution to all Google Play users until November 1, 2026. Google surfaces the form through the app's policy warning in Play Console, on the Policy status page, so you do not go hunting for it; the notification arrives for impacted apps. There are also standing exceptions, most usefully permanently private apps restricted to users in a specific organization for internal distribution, which sit outside these requirements entirely. Enterprise-only apps distributed through managed Google Play are the typical case there.

What comes after API 36

Plan for this to recur every year. Google has not published a dated requirement for API 37 yet, but the cadence is fixed and the direction is public. API 34 was required in August 2024, API 35 in August 2025, and API 36 in August 2026, which puts API 37, tied to Android 17, on track for roughly August 2027. Android 17 is already in the release list, and the February 2026 Android Developers post confirms it continues the adaptive-layout push that Android 16 started. The lesson for any team maintaining an app is to treat the target-API bump as an annual maintenance line item, not a fire drill. Teams that keep within one release of the latest API level spend a day each year; teams that fall three levels behind spend a sprint.

India-specific considerations

For India's large base of app studios, agencies, and in-house product teams, the deadline lands on top of tighter account rules. A Google Play developer account is still a one-time $25 registration fee with no annual charge, but in 2026 Google requires stronger identity verification and two-step verification before an account can upload, and personal accounts must run a closed test with at least 12 testers before the first public release. That raises the cost of leaving a compliance sprint to the last week, because a blocked or unverified account cannot ship the update that meets the target. For agencies maintaining many client apps on Google Play, the practical move is to inventory every app's current target level now, sort by how far below API 36 each one sits, and schedule the large-screen redesign work first, since that is the part that cannot be rushed. If your apps handle personal data, remember that India's Digital Personal Data Protection Act 2023 obligations apply independently of Play policy, so treat the migration as a chance to review permissions and data handling at the same time.

FAQ

How eCorpIT can help

eCorpIT runs Android target-API migrations end to end, from auditing every app's current level to redesigning portrait-locked screens for large-screen adaptive layouts and shipping a staged rollout that holds up on Android 16 vitals. We handle the QA-heavy parts that a one-line Gradle change hides, and we keep your apps discoverable through each annual deadline. If you are facing the August 31 cutoff across one app or a whole portfolio, talk to our senior engineering team through our Android and Kotlin app development service or reach us at /contact-us/. For related work, see our guide to enterprise mobile app development, our foldable and large-screen adaptive app development service, and the earlier Google Play call-log permission migration.

References

1. Meet Google Play's target API level requirement (Android Developers, updated July 15, 2026)

1. Target API level requirements for Google Play apps (Play Console Help)

1. Behavior changes: apps targeting Android 16 or higher (Android Developers)

1. The future is adaptive: changes to orientation and resizability APIs in Android 16 (Android Developers Blog)

1. App orientation, aspect ratio, and resizability (Adaptive Apps, Android Developers)

1. Prepare your app for the resizability and orientation changes in Android 17 (Android Developers Blog)

1. Get started with Play Console, including the one-time $25 registration fee (Play Console Help)

1. Google Play developer fee 2026: $25 and the 12-tester rule (IconikAI)

1. Google Play target API level requirements for Android apps, 2026 (Median.co)

1. Android 16 releases and versions (Android Developers)

1. Your Android app has until August 31 to target API 36 (Stora)

_Last updated: July 29, 2026._