In this article

Google Play has two different target API checks: whether you can submit an update, and whether an existing release remains available to new users on newer Android versions. Passing one does not establish the other. Inspect the exact policy notice before changing your app's minimum supported Android version.

This guide covers ordinary phone and tablet apps. Wear OS, TV, Automotive and XR have separate rows in Google's policy. Requirements were checked on October 8, 2026; use the current Console notice for your application.

Identify which gate is blocking you#

For phone and tablet submissions, Google's current policy requires API 36 or higher for new apps and updates from August 31, 2026. Existing-app availability uses API 35 as its threshold. Google describes an extension request to November 1, 2026; a request is not evidence that your application received an extension. See the target API policy and form-factor exceptions.

Write down the operation you were attempting:

  • Uploading a new application or update: inspect the submission requirement.
  • Investigating why a new user cannot install an existing listing: inspect availability, device compatibility and distribution settings.
  • Maintaining an app previously installed by a user: do not automatically equate this with new-user availability.

An API 35 phone release can meet the existing-app threshold while an API 35 update fails the newer submission threshold. That is an explanation to test against the notice, not proof that every installation problem is a target API problem.

Keep the three Android version settings separate#

minSdk defines the minimum supported Android version. targetSdk expresses the Android behavior level your application targets. compileSdk controls the APIs available to compile against. Raising the target does not, by itself, require raising the minimum to the same number. Google's policy explanation explicitly distinguishes target and minimum support.

For a Flutter project, inspect the Android module and the resolved build settings. Do not rely on a value in an obsolete branch or on a framework default you have not checked.

Record the release evidence:

text
package name:
version code:
artifact checksum:
form factor:
resolved target API:
Console notice and deadline:
extension decision, if any:

The artifact checksum connects the inspected bundle to the file actually submitted. A corrected Gradle file is useful, but it cannot repair an older bundle already uploaded.

Change behavior deliberately#

Treat the target change as a compatibility migration. Read the Android behavior changes for the destination release, inventory the features your app uses, and assign a test to each relevant change. Notifications, background work, storage, permissions and authentication deserve concrete checks where the application relies on them.

Build the production flavor. Confirm the resulting application's identity and target, then test both a newer Android device and the oldest version you still claim to support. Those tests answer different questions.

Avoid changing the target, minimum, plugins and signing setup simultaneously unless necessary. A smaller migration makes a regression easier to attribute.

Resolve an availability complaint with evidence#

If a user reports an unavailable listing, capture the exact message, device OS, country, account eligibility and whether the app was installed previously. Compare these with the published artifact and the Console's policy status. Country restrictions or device exclusions need a different remedy from a target API rejection.

Before closing the incident, retain the accepted artifact's identity and the resolved policy notice. An upload that passes validation still needs the ordinary review and release steps; it does not prove the update is live.

If an automated tool proposes a broad Gradle rewrite, apply the same review checks used for AI-generated code: inspect the change, confirm the artifact and test the behavior it affects.