Google Play's annual target API deadline has arrived.

Starting August 31, 2026, a new mainstream Android application must target Android 16, API level 36, or higher before it can be submitted to Google Play.

The same requirement applies to updates for existing mobile apps.

A developer can therefore leave some older apps published under a previous target level, but cannot normally submit a new mobile release without moving to API 36.

Targeting Android 16 does not mean dropping older phones

The target API level is frequently confused with an application's minimum supported Android version.

They are different settings.

targetSdkVersion tells Android which generation of platform behavior and policy the application has been designed to handle.

minSdkVersion determines the oldest Android release on which the app can be installed.

An application can therefore target Android 16 while continuing to support much older devices if its developer keeps an appropriately low minimum SDK.

Google's submission policy now keeps apps within one major release

Google Play's general policy requires new apps and updates to target an API level no more than one year behind the latest major Android release.

The API 36 deadline is the 2026 application of that rule.

Google says the policy is intended to ensure that users benefit from newer platform security, privacy and performance protections rather than allowing applications to avoid new behavior indefinitely by declaring an obsolete target SDK.

An abandoned Android 14 app is not automatically deleted

The rule for apps that are already published is different.

Existing mainstream apps now need to target at least Android 15, API level 35, to remain broadly available to new users on newer Android releases.

An app targeting Android 14/API 34 or below is not necessarily removed from Google Play entirely.

Its distribution becomes restricted.

It can remain available to users whose devices run an Android version equal to or lower than the app's declared target.

New users running a newer Android version will no longer normally be able to obtain it through Google Play.

Some old apps can therefore disappear from an Android 16 user's store

Consider an abandoned app that still targets Android 13.

Google Play can continue offering it to new users on Android 13 or earlier.

A new user on Android 16 will no longer see it as normally available.

That restriction does not prove that the software is technically incapable of running on Android 16.

Google is restricting distribution because the app has not adopted the security and quality expectations attached to more recent versions of the platform.

The policy primarily affects new users, not automatic removal from existing phones

Google's documentation explicitly frames the rule around availability to new users.

The company is not announcing that obsolete applications will suddenly be uninstalled from devices where users already have them.

Instead, an outdated app gradually loses its ability to acquire new users as the installed Android base moves forward.

For an actively operated commercial service, that can become almost as effective as a hard removal over time.

Developers can request until November 1

Google provides a temporary extension for developers unable to meet the August deadline.

Eligible developers can request continued distribution until November 1, 2026.

Affected apps receive access to the extension request through Play Console notifications.

The extension does not cancel the policy.

It provides roughly two additional months for migration and testing.

Wear OS does not need API 36 yet

The deadline is shared across several Android form factors, but their required API levels are not identical.

New Wear OS applications and updates must target Android 15/API 35 or higher.

For already published Wear applications, Android 14/API 34 is the current threshold for remaining broadly available to users on newer releases.

Wear therefore remains one major API generation behind the requirement imposed on mainstream mobile applications.

Android Automotive also remains on Android 15

New and updated Android Automotive OS applications must target at least Android 15/API 35.

Existing Automotive apps have a lower availability threshold, with Android 12L/API 32 currently considered compliant.

Google also documents a specific exception for some apps targeting the Automotive form factor when they are bundled within the same package.

Android TV and Android XR stay on API 34

Television and extended-reality applications follow another schedule.

New Android TV and Android XR apps need to target Android 14/API 34 or higher.

Android TV had already been using API 34 as its new-submission requirement since 2025.

Existing TV apps can currently remain broadly available when targeting Android 13/API 33.

For Android XR, Google requires Android 14/API 34 for both new submissions and continued broad availability of existing apps.

Changing targetSdkVersion can materially change how an app behaves

Migrating is not simply a matter of editing one integer in a build configuration.

Android uses the target SDK precisely to determine when certain potentially disruptive platform behavior changes become mandatory.

Apps moving to API 36 therefore need testing against the Android 16 behavior changes that apply specifically to applications targeting that release.

Apps can no longer opt out of edge-to-edge on Android 16

One example involves edge-to-edge layouts.

Android 15 already enforced edge-to-edge behavior for apps targeting API 35, but an opt-out mechanism still existed for some cases.

For apps targeting API 36 while running on Android 16, that opt-out is disabled.

Developers need to handle system insets correctly so controls and content are not obscured by system bars.

Back navigation changes too

Android 16 enables predictive Back system animations by default for apps targeting API 36.

Applications that still rely on older Back interception mechanisms need to migrate to supported navigation APIs or use the temporary opt-out that remains available for predictive Back.

Google notes that legacy patterns involving onBackPressed or directly handling KEYCODE_BACK no longer behave in the same way under the new target.

Simply increasing the target number without testing navigation can therefore create real application bugs.

API 36 also activates additional security and privacy behavior

Android 16 includes several other target-dependent changes.

Google is strengthening parts of Intent handling and reducing the usefulness of some MediaStore information for device fingerprinting.

Photo permission behavior also changes when users grant an app access only to selected media.

Not every Android 16 feature depends on targetSdkVersion, but these target-specific changes explain why Google repeatedly forces applications to move forward.

Permanently private enterprise apps receive an exception

The policy is not universal across every Play-distributed application.

Google specifically exempts permanently private apps restricted to users inside a particular organization and intended exclusively for internal distribution.

Those deployments are not treated exactly like consumer apps competing for public Play Store distribution.

Google is steadily making old target APIs commercially unattractive

Targeting an older Android version once allowed developers to postpone many behavioral changes introduced by newer releases.

That compatibility mechanism still exists and remains useful during migration.

Google Play now gives it a limited commercial lifespan.

An actively updated app must remain roughly within one major Android release of the current platform.

An abandoned app receives more time, but gradually loses access to new users as Android moves ahead.

August 31 does not suddenly make every older application incompatible.

It does something more gradual: it makes falling behind increasingly expensive inside the store itself.