Google Play API 36 Deadline Passed: What Now?

Google Play's August 31, 2026 deadline has passed, and if you're still seeing a compliance warning on the Policy status screen in your Play Console, you're not alone. In this post I walk through, step by step, how the Google Play target API 36 deadline extension process works today (as of 2026-09-08), which apps are still at risk, and what breaks when you raise your targetSdkVersion to 36.

💡 Pro Tip: Don't panic — your existing users aren't having the app taken away from them. The only thing at risk is that new users on devices running a newer Android version won't be able to find you on Play. First check the Policy status screen in Play Console, then follow the order laid out in this post.

Table of Contents

• What Exactly Is the Requirement: New App or Update
• What Happens If You Missed August 31
• How to Request an Extension in Play Console
• Behaviors That Break When You Move to targetSdk 36
• Edge-to-Edge and Foreground Service Requirements
• Testing and Staged Rollout Plan
• The Next Wave: API 37 Timeline
• FAQ
• If I miss the Google Play API 36 deadline, will my app be removed?
• How do I get a target API 36 extension, and what's the final deadline?
• Which apps can stay on API 35?
• What breaks when I raise targetSdkVersion to 36?
• What order should I follow before raising targetSdk?
• Conclusion
• Sources

What Exactly Is the Requirement: New App or Update

According to Google's official Play Console Help page, starting August 31, 2026, both new apps and updates submitted to existing apps must target Android 16 (API level 36) or higher. This rule applies to every new version submitted to Play — it's not just "new apps"; every update you push to an app already live in production has to meet this requirement too.

The rule has exceptions, and knowing them saves most developers an unnecessary migration scramble:

• Wear OS and Android Automotive OS apps: Android 15 (API level 35) or higher is enough.
• Android TV and Android XR apps: Android 14 (API level 34) or higher is enough.
• For phones, tablets, foldables, and standard Android Auto companion apps, the floor is always API 36.

Rather than memorizing these exceptions one by one, laying out which category depends on which floor in a table makes the decision easier:

If you have an app that targets multiple form factors (e.g. phone + Wear OS module), you need to make sure each module carries the correct targetSdkVersion in its own manifest — two different floors can be valid at the same time within a single project.

There's a concept that gets mixed up here: targetSdkVersion versus minSdkVersion. minSdkVersion determines the oldest Android version your app will support, and it's entirely unaffected by this requirement — you don't need to raise your minSdk. targetSdkVersion, on the other hand, is your app's promise to Android about which version's behavior rules it operates under. So without narrowing your existing device support at all, you're only moving the behavior layer the app is compiled and tested against up to 36.

What Happens If You Missed August 31

If it's September today and you still have an app live with an old target API, know this first: your app has not been removed and will not be removed. Existing users still have the app; they can keep downloading and updating (the old version).

The actual restriction operates on two layers:

1. You can't submit a new version. After August 31, any new version targeting API 35 or below is rejected by Play. So even if you wanted to push a bugfix update today, you'd first need to bring targetSdk up to 36.
2. Risk of invisibility to new users. According to the official Play Console source, existing apps must target API 35 or higher to remain visible to new users on devices running an Android version newer than their own target API level. An app that doesn't meet this threshold stops being visible and usable to new users on those devices — your existing user base isn't affected, but your new-user flow gets cut off.

In practice, this removes the "will I get pulled right now" fear but raises the "am I losing new users every day" concern.

How to Request an Extension in Play Console

According to Google's official Play Console Help page, only apps that are out of policy compliance receive a policy warning and notification in Play Console; the extension form is also reached through the detail page for that warning or issue on the Policy status page. According to independent sources that track Play policy, the action on this detail screen carries the label "Request more time."

An approved extension pushes the compliance date back to November 1, 2026. But there's a nuance that absolutely needs to be clarified here: this is not an "always-open window you can apply to whenever you want." Independent sources closely following Play policy note that extensions are not guaranteed for every app — meaning approval isn't automatic for every account or every app.

If, when you open Play Console today, the "Request more time" option no longer appears, this is the most realistic path: focus directly on the targetSdk 36 migration instead of waiting for an extension. Because the only guaranteed way out is to actually ship a version of your app that targets API 36.

When checking this screen on your own account, look at two things: the status of the warning (active or cleared) and whether an extension form is open on the detail page. Once both are clear, deciding your next step gets easier.

There's a common mistake here: assuming the extension is "a general form open to every developer, fillable whenever you want." But the official source says the form only reaches affected apps via notification. So if your account has never received a notification, that may mean this form isn't open (yet, or at all) for you — in that case, focusing directly on the migration instead of waiting doesn't cost you time.

It's healthier to frame the extension process not as an "escape route" but as a buffer that adds extra time to your migration process. Because no matter what the date is, the single point you eventually have to reach is the same: a version in production targeting API 36 that's been tested against the behavior changes.

Behaviors That Break When You Move to targetSdk 36

Bumping targetSdkVersion to 36 doesn't give you a compile error, but there are several behaviors that break silently at runtime. According to Android 16's official behavior changes page, at the top of the list is predictive back: on devices running Android 16+ with an app targeting API 36, system back animations (return to home, cross-task, cross-activity) are on by default. If you're still relying on the old onBackPressed() contract, it no longer gets called, and KeyEvent.KEYCODE_BACK isn't dispatched either.

• OnBackPressedDispatcher: the API that lets you manage back-button behavior through registered back callbacks instead of onBackPressed(); you need to move to this model for predictive back animations to work.
• Three-button navigation expansion: according to the Android Developers Blog's Android 16 announcement, Android 16 extends predictive back navigation to three-button navigation too; users who long-press the back button see a slice of the previous screen before actually going back.

1// Old pattern (won't work on API 36):
2override fun onBackPressed() {
3    if (isEditing) { cancelEdit() } else { super.onBackPressed() }
4}
5 
6// New pattern: register a callback with OnBackPressedDispatcher
7val callback = object : OnBackPressedCallback(true) {
8    override fun handleOnBackPressed() {
9        if (isEditing) cancelEdit() else {
10            isEnabled = false
11            onBackPressedDispatcher.onBackPressed()
12        }
13    }
14}
15onBackPressedDispatcher.addCallback(this, callback)

Skipping this migration doesn't crash the app, but the back button/gesture behaves inconsistently for the user — this is especially noticeable on editing screens with custom back behavior (forms, editors, media players).

The second break point is media access. Per the definition on Android 16's behavior changes page, when an app targeting SDK 36 or higher requests photo and video permission on a device running Android 16 or higher, users who prefer to limit access to selected media see the photos the app already owns pre-selected in the photo picker. The user can deselect these pre-selected items, and when they do, the app's access to those photos and videos is revoked. So code in your selected-media flow that assumes once-accessed content stays permanently accessible needs to be revisited to account for this model where access can be revoked by the user.

Third, large-screen and foldable device behavior: according to the official statement, on apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions are no longer enforced on screens with a smallest width of 600dp or greater. So even if you define a restriction like screenOrientation="portrait" in your manifest, the app fills the entire window on these screens — you need to actually test your layout in landscape and split-screen mode, or you may run into cropped or overflowing UI. The same source also defines a temporary escape hatch: you can opt out of this behavior with the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property; but this opt-out won't be valid for apps targeting API level 37.

There's an item that's often assumed to belong on this list but actually didn't arrive with API 36: full-screen notifications. On apps targeting Android 14 (API level 34) or higher, using the USE_FULL_SCREEN_INTENT permission is limited to apps offering calling and alarm functionality; Google Play revokes the default permission for apps that don't fit this profile. In other words, this rule has been in effect since API 34 — if it's showing up for the first time during your targetSdk 36 migration, it's not a new restriction, it's an old debt you'd skipped.

Finally, there's a change independent of targetSdk that shows up in the same migration window: background work launched from a foreground service now has to comply with its own runtime quotas. This rule applies to apps running on Android 16 or higher, regardless of the API level they target — I cover it separately in the next section, because foreground service rules form their own category of breakage.

Edge-to-Edge and Foreground Service Requirements

According to Android 16's behavior changes page, the long-standing "opt-out" escape hatch for edge-to-edge — R.attr#windowOptOutEdgeToEdgeEnforcement — no longer works for apps targeting SDK 36. The official statement is clear: this attribute is deprecated and disabled; an app targeting API 36 can no longer opt out of edge-to-edge drawing. If you've never dealt with this before, you're likely to run into content that overlaps or disappears behind the status bar and navigation bar.

Three points you need to check in practice:

On the foreground service side, the change is sneakier: background work triggered from a foreground service (e.g. a sync started from within a notification service) is now subject to its own runtime quotas on apps running Android 16 or higher. So the assumption "I'm inside a foreground service, the quota doesn't apply to me" no longer holds on Android 16 and above. Official documentation explicitly includes work created by libraries like WorkManager or DownloadManager in this scope, in addition to work scheduled directly with JobScheduler. So WorkManager isn't an escape route from the quota; what it provides is that the work is defined with a constraint model that can be deferred and retried.

1// The assumption of "unlimited" background work from inside a foreground service no longer holds.
2// WorkManager jobs are subject to the same runtime quota too (along with JobScheduler/DownloadManager).
3val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
4    .setConstraints(
5        Constraints.Builder()
6            .setRequiredNetworkType(NetworkType.CONNECTED)
7            .build()
8    )
9    .build()
10WorkManager.getInstance(context).enqueue(syncRequest)

Testing and Staged Rollout Plan

Pushing the targetSdk 36 migration to production all at once means showing your users every one of the behavior changes above at the same time. Following a step-by-step order instead reduces the risk:

• Take a dependency inventory: check whether the third-party SDKs you use have published an API-36-compatible release. If a library hasn't shipped a compatible version yet, your migration is blocked on that library — this is a bottleneck point.
• Raise compileSdk and targetSdk separately: first bump the compile target to 36 and see the build errors; then change targetSdkVersion and observe the behavior differences.
• Manually test predictive back, edge-to-edge, and large-screen behavior: these aren't caught by lint or the compiler — they're only surfaced by manually testing on a real device or emulator.
• Push to a closed testing track (internal/closed testing): use Play Console's test tracks to observe real behavior before going to production.
• Roll out to production in stages (staged rollout): expand distribution gradually with percentage-based rollout while monitoring crash/ANR rates.

An important practical note: shipping this targetSdk update for an existing, already-published app does not re-trigger the "12 test users / 14 days" closed testing requirement. That requirement only applies to new individual developer accounts publishing their first production release — so if you're updating an existing app, you don't need to deal with this extra waiting period.

Once the compatible version goes live in production, the policy warning in Play Console clears automatically and Google sends a confirmation notification — so you don't have to guess whether the migration succeeded; the notification tells you.

When taking a dependency inventory, instead of checking each library's changelog one by one, pulling the output of ./gradlew :app:dependencies and comparing version numbers against known-compatible releases saves time. Taking that inventory on day one of the sprint prevents a surprise blocker at the end of the migration.

During the time you spend on the closed testing track, repeatedly and manually test these three scenarios in particular: exiting a screen with custom back behavior (form, editor) via the system back gesture, verifying that insets are applied correctly on a screen that draws behind the status bar and navigation bar, and opening the app on a tablet or foldable in both portrait and landscape. These three scenarios make most of the behavior changes listed above visible in a single session.

The Next Wave: API 37 Timeline

Google Play's target API requirement runs as an annual cycle — this year's API 36 wave isn't a one-off; the same mechanism ran for API 34 and API 35 in previous years. Given the nature of this cycle, you can expect a similar target API requirement for Android 17 (API level 37) to come up down the road.

What's clear for now: Android's official developer site already has a behavior changes page live for apps targeting Android 17, and topics like removing the orientation-resizability opt-out on large screens/foldables are covered there. However, an official, firm date for when Google Play will make API 37 mandatory has not been published on the Play Console help page as of when this post was written — so I'm not giving a specific month/date here. Rather than making a firm assumption, the safest strategy is to budget for a target API update every year and check the Policy status page in Play Console regularly.

Keeping this budgeting approach clearly visible in build.gradle.kts also prevents the "which SDK are we targeting" debate within the team:

1android {
2    compileSdk = 36
3 
4    defaultConfig {
5        minSdk = 24
6        targetSdk = 36 // Play requirement: mandatory since August 31, 2026
7    }
8}

If you plan the yearly bump as routine maintenance embedded in your release calendar rather than an "emergency," you won't need to re-read this post for the next wave.

FAQ

If I miss the Google Play API 36 deadline, will my app be removed?

No, it won't be removed. Existing users keep the app; downloading and using it isn't interrupted. The only thing that's cut off is new users on devices running a newer Android version than your target API level being able to find you on Play. On those devices, your app stops being visible and usable to new users — it's invisibility, not removal.

How do I get a target API 36 extension, and what's the final deadline?

Per Google's official definition, the extension form is reached through the detail page for the relevant warning or issue on the Policy status page in Play Console; non-compliant apps receive this warning along with a Play Console notification. If approved, the compliance date is pushed to November 1, 2026. But this isn't a guaranteed right — independent sources tracking Play policy note that extensions aren't guaranteed for every app, so the safest path is to start the migration without waiting for the extension.

Which apps can stay on API 35?

Only Wear OS and Android Automotive OS apps get by with API 35 (Android 15) or higher. For Android TV and Android XR apps, the floor is API 34. For phones, tablets, foldables, and standard Android Auto companion apps, the floor is always API 36 — there's no exception in this category.

What breaks when I raise targetSdkVersion to 36?

The three most common changes: predictive back animations requiring OnBackPressedDispatcher instead of onBackPressed(), edge-to-edge drawing no longer being possible to opt out of, and orientation, resizability, and aspect ratio restrictions being ignored on screens with a smallest width of 600dp or greater (you can temporarily opt out of this last one on API 36, but that option goes away on API 37). In addition, independent of targetSdk, background work triggered from a foreground service is subject to its own runtime quota on apps running Android 16 or higher. None of these produce a compile error — they're all only caught by manual runtime testing.

What order should I follow before raising targetSdk?

First check the compatibility of your third-party SDK dependencies, then raise compileSdk and resolve the build errors, then change targetSdkVersion and observe the behavior differences on the closed testing track, and finally go to production with a staged rollout.

Conclusion

The Google Play target API 36 requirement took effect on August 31, and today the real question isn't "will my app get pulled" but "am I losing new users." Check the Policy status screen in Play Console, treat the extension form as an extra buffer rather than a rescue plan, and start the targetSdk 36 migration with a third-party dependency check, finishing with a staged rollout.

I go deeper into where the edge-to-edge requirement comes from and how it has evolved into a design language alongside Material 3 Expressive in my post Material 3 Expressive and the Android 16 design system. You can find the coroutine-based approach for defining quota-bound background work with WorkManager in WorkManager 2.10 and coroutine-based background work. If you want to catch performance regressions on the Jetpack Compose side, Jetpack Compose 1.7 performance and strong skipping will come in handy.

For teams who'll also be reviewing their Play Console subscription and billing flows in this same migration window, Google Play Billing v7 subscription integration is a good companion piece. If you want to see how targetSdk 36's privacy and edge-to-edge requirements arrived in the previous wave (API 35), Android 15 developer privacy sandbox and edge-to-edge can be considered the natural predecessor to this post. If you have an Android Auto companion app, remember that the target API 36 floor requirement applies there too — you can find the details in Android Auto dashboard production guide.

Sources

• Google Play target API level requirements (Play Console Help) — the official definition of the August 31, 2026 requirement, exceptions (Wear OS/Automotive API 35, TV/XR API 34), and the November 1, 2026 extension window.
• Android 16 behavior changes: apps targeting API 36+ (Android Developers) — the official technical reference for predictive back, the edge-to-edge requirement, and the foreground service runtime quota.
• Android 16 is here (Android Developers Blog) — the official announcement of predictive back's expansion to three-button navigation.
• Android 14 behavior changes: apps targeting API 34+ (Android Developers) — the official source for USE_FULL_SCREEN_INTENT permission being limited to calling and alarm apps.
• Android 17 behavior changes: apps targeting API 37+ (Android Developers) — the official preview of the large-screen/orientation changes expected in the next wave.
• Update your target API level by August 31, 2026 (Testers Community) — a visual walkthrough of the Play Console warning screen, the closed testing exception, and an explanation of the annual cycle.
• Android API 36 August deadline: what to do now (stora.sh) — a practical summary of third-party SDK dependency risk and targetSdk 36 migration steps.
• Foreground service changes (Android Developers) — detailed technical documentation for background work triggered from a foreground service being subject to the runtime quota.