For most Android phone and tablet apps, the August 31 rule is simple: a new app or app update submitted to Google Play must target Android 16, API level 36, or higher. Existing apps that are not being updated follow a different threshold, which is where the deadline gets confusing.

Requirement check: August 13, 2026. Google's current documentation says the new target API requirements take effect on August 31, 2026. Developers who need more time will be able to request an extension until November 1, 2026 through Play Console.

The two rules hidden inside one deadline

App situationRequirement from August 31, 2026
New phone/tablet appTarget Android 16 / API 36+
Update to an existing phone/tablet appTarget Android 16 / API 36+
Existing phone/tablet app with no new submissionTarget Android 15 / API 35+ to remain available to new users on newer Android versions
Wear OS or Android Automotive OS new app/updateTarget Android 15 / API 35+
Android TV or Android XR new app/updateTarget Android 14 / API 34+

A live phone app targeting API 35 is therefore not automatically removed on August 31. It can remain available to new users on newer Android versions, but the next update submission for that app needs API 36.

What happens to a live app still targeting API 34?

Google says an existing phone or tablet app targeting Android 14 / API 34 or lower will stop being available to new users on devices running an Android version higher than the app's target API level.

That is a discoverability restriction, not a remote uninstall. Google's policy says people who previously installed the app can continue to discover, reinstall and use it on Android versions the app supports.

It helps to separate two failure modes:

  • Submission failure: a new app or update does not meet the API 36 requirement.
  • Discoverability loss: an older live app falls below the existing-app availability threshold.

Those are different problems and may require different priorities.

Why changing targetSdk is not just a number bump

The target API tells Android that an app is ready for behavior changes tied to newer platform versions. Raising it can therefore change runtime behavior even when the code still compiles.

Google's migration guide points developers to the behavior-change lists for Android 13, 14, 15 and 16 when moving older apps forward.

A useful way to think about the upgrade is as three separate checks:

1. Build compatibility

Can the project, Gradle setup and third-party dependencies compile against the required SDK?

2. Runtime compatibility

Do core flows still work after Android enables behavior changes associated with the newer target level?

Permissions, notifications, background execution, alarms, deep links and SDK integrations are common places to test carefully.

3. Play compatibility

Does the resulting app bundle satisfy Play Console validation and any current declarations or policy requirements?

A successful local build only proves the first layer.

A practical migration order

Step 1: identify the current target

Check targetSdk or targetSdkVersion before changing dependencies. If the app is several releases behind, review each Android version's target-specific behavior changes rather than treating API 36 as one giant jump.

Step 2: audit third-party SDKs early

Old advertising, analytics, authentication, payments and device SDKs can become the real blocker. Confirm that critical dependencies support the newer target level before the final week.

A dependency that needs a major-version upgrade can create more work than the target SDK change itself.

Step 3: test behavior changes, not only compilation

Run the app on a recent Android release and exercise the workflows users actually depend on. Test permission denial and re-granting, notifications, scheduled/background work, app links, file sharing and any platform-sensitive SDK integrations.

The better question is not "does the release build succeed?" It is "what does Android now enforce because this app declared a newer target?"

Step 4: submit to a testing track before production

Upload a release candidate to an internal or closed Play testing track before the deadline. That exposes Play Console validation and declaration problems without making the production release the first real submission test.

Step 5: treat the extension as contingency

Google says developers who need more time will be able to request an extension to November 1, 2026. That is useful for a genuine migration blocker, but it is temporary; the underlying upgrade still needs to be completed.

The five-minute decision check

Use these questions in order:

  1. Submitting a phone/tablet app or update on or after August 31? Target API 36+.
  2. App already live and not being updated? Check whether it targets at least API 35 to preserve normal availability to new users on newer Android versions.
  3. Wear OS or Android Automotive OS? New apps and updates need API 35+.
  4. Android TV or Android XR? New apps and updates need API 34+.
  5. Cannot finish and test safely before the deadline? Check the Play Console extension path to November 1 rather than shipping an untested target bump.

What to watch next

The most practical detail to watch is the extension workflow in Play Console. Google's documentation says the November 1 extension will be available, so teams expecting to need it should watch their Play Console notices rather than assuming an extension is automatic.

Dependency readiness is the other risk. Close to the deadline, the final targetSdk value is often the easy part; outdated SDKs and behavior changes activated by the new target are where migration time is actually spent.

Conclusion

The August 31 Google Play deadline has two thresholds, not one. Most new phone/tablet apps and updates need API 36, while an existing app needs API 35 to keep normal availability to new users on newer Android versions.

The concrete next step is to classify the app first, then migrate deliberately: verify the current target, check dependencies, review target-specific behavior changes, test on modern Android and upload a Play testing-track build before the deadline.

Sources

Checked August 13, 2026:

Written and reviewed by /lico

Just writing down my thoughts, interests, and the things I learn along the way.