Android 16 is now the submission gate: target API 36, and what the 1 November window actually is

If a submission came back this week on its target API level, the date behind it is 31 August 2026, and it is behind us. Checked 2 September 2026.

Since that date Google Play has applied two requirements, to two different sets of apps, with two very different verbs.

• A new app or an app update must target Android 16 (API level 36) or higher to be submitted — Wear OS and Android Automotive OS at API 35 or higher, Android TV and Android XR at API 34 or higher.
• An app already on Play, across mobile and Android Auto, must target Android 15 (API level 35) or higher to stay available to new users on newer devices. Wear OS, Android TV, Android XR and Android Automotive OS each carry their own availability row, and they are set out below.

Those are not two readings of one rule. Google states them under two separate headings, App update requirements and App availability requirements, and they fail differently: one blocks the upload, the other narrows who can install what is already published.

So a team that has not shipped an update since it moved to API 35 is compliant on availability and blocked on submission the moment it tries to ship. Nothing about the app changed. The build sat still and one of the two bars moved past it.

Both of Google's pages on this are still written as though 31 August were ahead of them. That is worth knowing before you read either one, and it is why every answer on this page ends at Play Console.

The submission gate: API 36

Play Console Help, Target API level requirements for Google Play apps, read 2 September 2026:

"Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS, and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher."

That one sentence, read as a table:

What clears the gate is the build itself: a submission whose targetSdkVersion meets the bar in the row for its form factor.

The developer site carries the same requirement at developer.android.com/google/play/requirements/target-sdk, and opens with it in the present tense and unconditionally: "When you upload an APK, it must meet Google Play's target API level requirements." That page carries a stamp of its own — "Last updated 2026-08-14 UTC."

Wear OS carries three different numbers on the Help Center page, because three different questions are being answered. For publishing, the page says: "When you publish a new Wear app, you must target Android 15 (API level 35) or higher." The availability requirements state the Wear OS bar at Android 14 (API level 34) or higher. And an FAQ answer on the same page is written for a Wear OS app targeting API 33 or lower. Read the section that matches your question, and take the answer for your app from Play Console.

The per-form-factor tables date the same API level to two different years. The Android TV app requirements table carries a single row putting Android 14 (API level 34) or higher at 31 August 2025. The Android XR app requirements table dates the identical API 34 bar to 31 August 2026. Both were on the page on 2 September 2026, under a headline sentence that groups Android TV and Android XR together.

The availability bar: API 35

The second obligation sits under App availability requirements, and the page's own words for it are:

"Currently, existing apps (across mobile and Android Auto) must target Android 15 (API level 35) or higher by August 31, 2026"

An app below that bar stays installable on a narrowing set of devices. The developer-site page states the mechanic: such apps "…will only be available on devices running Android OS that are the same or lower than your app's target API level." A device running a newer Android OS version than the app targets drops out of the set.

Everybody who already has the app keeps it. Google's sentence, verbatim:

"Users who have previously installed the app from Google Play will not be impacted and will still be able to discover, re-install, and use the app on any Android OS version that your app supports."

A new user on a newer device is shown a message, and Google publishes its wording. Google Play will inform the user that "this app is not available to install on their device because it was made for an older version of Android."

That is the difference between the two obligations in one paragraph. The submission gate produces a rejected upload, and the person who pressed the button sees it. The availability bar produces an install that never happens, on somebody else's device, with a store message you did not write — and where it registers is install volume.

For an existing Android TV app the page states two cases. "If your existing Android TV app targets Android 13 (API level 33), then your app is compliant with this policy." And it states that an existing app targeting Android 12 (API level 31) or lower stops being available. For an Android TV build, as for every other build, the Policy status page in Play Console is where your own package's state is written.

The stated exception

Verbatim, from the same page:

"Exceptions to these requirements include the following: Permanently private apps that are restricted to users in a specific organization and intended for internal distribution only."

Note the page's own construction — "include the following". The list is the page's; what is on it for your app is Play Console's.

The 1 November 2026 window

This is the part where the page contradicts itself, and where the honest answer is a smaller one than either half of the contradiction.

What the headline block says, verbatim:

"You will be able to request an extension to November 1, 2026 if you need more time to update your app. You'll be able to access your app's extension forms in Play Console later this year."

What the FAQ on the same page says, verbatim:

"Only apps that are not compliant with the policy will receive a policy warnings and notification in Play Console. The extension form is available through the details page of the warning or issue on the Policy status page in Play Console."

Both were on the page on 2 September 2026. One describes the form as coming later this year; the other describes it as available now, and names where. The page also names more than one delivery channel for the same form: in Play Console, via Notifications, and on the details page of the warning or issue on the Policy status page.

The sentence that holds under either reading, and the one you can act on: the extension request reaches a non-compliant developer as a notification and a link on the Policy status page in Play Console. Three things travel with it, all of them the page's own: it is a request, it runs to 1 November 2026, and the condition attached to it is "if you need more time to update your app". It is time to raise the target, and the target is the table above.

Everything past that is a question about your app rather than about the policy, and Play Console is the only surface that answers questions about your app. Check Play Console.

Where the pages sit relative to their own date

Worth saying plainly, because it changes how much weight either page can carry on 2 September 2026.

• The Help Center article still opens "Starting August 31, 2026:" — a framing written for a date two days behind it — and states the availability bar as "Currently, existing apps … must target Android 15 (API level 35) or higher by August 31, 2026".
• The developer-site page stamps itself "Last updated 2026-08-14 UTC": seventeen days before the date it describes as starting.
• And the relief mechanism is still described in the future on a requirement that is already enforcing.

Read them for the policy's wording, which is what they are authoritative about. Read Play Console for your app's state, which is what it is authoritative about. Where the two disagree about whether something exists yet, only one of them is looking at your package name.

What a build at API 36 already inherits

Raising targetSdkVersion is a store obligation and a platform event at the same time. The platform half is worth knowing because the platform's own defaults are keyed to the API level a build targets, and a build that clears today's submission gate is at API 36 or higher — or at the level in its form factor's row above.

Two of the platform's own rules key off the target SDK, and an API 36 build sits above both thresholds.

Cleartext and CA trust. developer.android.com/privacy-and-security/security-config, page stamp Last updated 2026-08-28 UTC, sets the Network Security Config base-config defaults by the app's target SDK: at API 28 and higher, cleartextTrafficPermitted="false" and trust anchors system only. The same page, in prose: "apps targeting Android 6.0 (API level 23) and lower also trust the user-added CA store by default", and "Starting with Android 9 (API level 28), cleartext support is disabled by default."

android:exported. developer.android.com/about/versions/12/behavior-changes-12, page stamp Last updated 2026-08-14 UTC:

"If your app targets Android 12 or higher and contains activities, services, or broadcast receivers that use intent filters, you must explicitly declare the android:exported attribute for these app components."

and, on the same page:

"Warning: If an activity, service, or broadcast receiver uses intent filters and doesn't have an explicitly-declared value for android:exported, your app can't be installed on a device that runs Android 12 or higher."

Those are properties of the build, and they change on the day targetSdkVersion changes. Any statement about an Android app that does not name the API level it is tied to is a statement with its date stamp missing.

The two dates on this subject

Both were read from Google's pages on 2 September 2026. Before acting on either, check Play Console — the console is where the state of your package is written, and it is the surface Google's own extension route runs through.

Security Brigade has been CERT-In empanelled since 2008 and has assessed 693+ mobile application scopes. +91 22 4164 2220.

Every date, quotation, requirement table and page stamp above was read from Google's own pages — the Play Console Help article on target API level requirements, developer.android.com/google/play/requirements/target-sdk, the Network Security Config page and the Android 12 behaviour-changes page — on 2 September 2026.