Target API level 37: Play hasn't published the deadline

Google Play's target API level requirement page was last updated on 28 October 2026, and it does not mention API level 37 once. There is no published Play deadline for target API level 37. The August 2027 date every roadmap cites comes from a single developer-relations blog post, not from policy.

That distinction matters today, because the API 36 extension window closes on 1 November 2026 — today. The date for the next cycle is a stated intention; the work it implies is already fixed. Plan against the behaviour changes, not against a month no policy page carries.

The facts, as of 1 November 2026:

• Play policy today: new apps and updates must target Android 16 (API level 36) or higher, in force since 31 August 2026, with extensions running to 1 November 2026.
• API 37 on Play policy pages: absent. Neither the developer requirements page nor the Play Console help article names it.
• The August 2027 date: stated in an Android Developers Blog post dated 13 February 2026.
• The behaviour changes: published and stable, on a page last updated 31 October 2026.

What Google Play actually says today, and what it leaves out

The requirements page sets one bar: “New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play”, with lower bars for form factors — API 35 for Wear OS and Android Automotive OS, API 34 for Android TV and Android XR. Separately, existing apps “must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level”. Those two rules are different, and teams conflate them.

The extension is the sentence that expires today: “If you need more time to update your app, you'll be able to request an extension to November 1, 2026.” If you took it, your submission bar is API 36 from tomorrow with no further grace documented. We wrote up that cycle in detail when the API 36 extension clock started, and the mechanics have not changed since.

What is missing is the interesting part. The Play Console help article on target API level requirements also stops at API 36 and the 1 November extension. Two separate Google surfaces, both maintained, both current, both silent on API level 37. For a policy that governs distribution, that silence means no day, no form-factor carve-outs and no extension mechanism has been committed to in writing yet.

Where the August 2027 target API level 37 date actually comes from

One source: an Android Developers Blog post published 13 February 2026 by Miguel Montemayor, a Developer Relations Engineer on Android. Under the heading “Targeting API level 37 by August 2027”, it states that “for Google Play, new apps and updates will be required to target API level 37, making this behavior mandatory for distribution in August 2027”. The same post adds a caveat worth quoting to anyone who ships outside Play: “The deadlines for targeting a specific API level are app-store specific.”

Take the counter-argument at full strength. Google's DevRel announcements have reliably become Play policy, the annual August cadence has held for years, and a head of mobile who tells their board “we're ignoring August 2027 because it isn't on the policy page” deserves the response they will get. We are not arguing the date is wrong.

We are arguing it is the wrong thing to fund against. A blog post gives you a month; policy gives you a day, the form-factor exceptions and whether an extension exists at all. The API 36 cycle is the proof: the headline date was 31 August 2026, but the deadline that governed real submissions was 1 November 2026, via a mechanism that only ever appeared on the policy page. Budget the engineering now and treat the calendar as provisional.

You can start today regardless, because the API surface stopped moving long ago. Android 17 reached Platform Stability with Beta 3 on 26 March 2026, at which point, per the Android 17 release notes, “the API surface is now locked”. One caution if you read version numbers in code: Android 17's QPR releases complicate the picture, and we covered why the minor version matters before you branch on SDK_INT. We are not giving you a stable release date for Android 17, because the official pages we read do not state one and the dates in third-party trackers are not sourced to Google.

The behaviour changes that only fire when you target API 37

Here is the planning material. The behaviour changes page for apps targeting Android 17, last updated 31 October 2026, lists more than a dozen changes conditioned on your targetSdkVersion, not on the device's OS version. These are the ones with real engineering cost attached.

Change	Condition on the page	What it costs you
Local network access	“Beginning with Android 17, enforcement is mandatory for apps that target Android 17 (API level 37) or higher”	A declared ACCESS_LOCAL_NETWORK permission and a runtime prompt for anything touching mDNS, printers, casting or on-premise APIs
Certificate transparency	“If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default”	TLS validation behaviour changes by default; see the next section
Encrypted Client Hello	“For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections”	Only active where your networking library and the remote server both support it; middlebox and inspection-proxy surprises
static final fields	“Apps running on Android 17 or higher that target Android 17 (API level 37) or higher cannot change static final fields”	IllegalAccessException from any test harness, feature-flag shim or SDK that rewrites constants by reflection
MessageQueue	Apps targeting API 37 “receive a new lock-free implementation of android.os.MessageQueue”	Better frame timing, but it “may break clients that reflect on MessageQueue private fields and methods” — check your performance and APM SDKs
SMS one-time passwords	“For most apps targeting Android 17 (API level 37) or higher, these SMS messages do not become available until three hours after receipt”	Any home-grown SMS OTP auto-fill that reads the inbox stops working; move to the standard retriever flows
RemoteViews memory	“the system enforces a strict memory limit on RemoteViews updates for apps targeting Android 17 (API level 37) or higher”	Widgets that push large bitmaps throw instead of warning; the error names the used and maximum bitmap memory
Contacts Provider 2	CP2 restricts PII columns from the data view, and enforces strict SQL validation on ContactsContract.Data without READ_CONTACTS, for apps targeting API 37 and higher	Account-name and account-type columns disappear; loose query strings start failing validation
Orientation and resizability	The SDK 36 opt-out “will no longer be available for apps that target Android 17 (API level 37) or higher”	The largest line item for most apps; see below

Two more land when you target API 37 and are cheap to miss in a test plan: background audio restrictions tighten, and setContentCaptureEnabled(false) no longer disables Content Capture. One change often listed alongside these is not target-gated at all — native libraries loaded via System.load() must be read-only on Android 17 or you get an UnsatisfiedLinkError, and that applies by platform version whatever you target. Knowing which bucket a change sits in is the difference between a bug you control by shipping later and one you do not.

The local network permission will feel familiar if you follow browser platform work; the same control arrived on the web, where Chrome's local network access opt-out outlived Chrome 156. On mobile there is no opt-out once you target 37.

Certificate transparency and your private CA: a risk to test, not a confirmed break

Targeting API 37 turns CT on by default, and CT requires a certificate to be present in public CT logs. An enterprise app pinned to an internal certificate authority issues certificates that, by design, are not in public logs. The obvious conclusion is that every internal API call breaks on the first build you ship against API 37.

The network security configuration reference, last updated 28 August 2026, says otherwise. Its note is unambiguous: “Certificate transparency verification isn't performed on connections that use custom trust anchors.” The evaluation order it publishes for each <domain-config> is explicit — if certificateTransparency is enabled, enable verification; if any <trust-anchors> is "user" or inline, such as "@raw/cert.pem", disable verification; otherwise inherit. So the common enterprise setup, a private root declared as an inline trust anchor in your network security config, has a documented exemption.

The risk is the configuration that does not go through that file. If your app establishes trust in code — a custom TrustManager, an OkHttp CertificatePinner, a client bundled by a third-party SDK — then there is no <trust-anchors> element for rule two to match, and the published evaluation order does not describe your case. We have not tested this. We are not telling you it breaks; we are telling you it is the one line item on this list where the documentation does not answer the question, so it belongs in your test matrix rather than your assumptions. Teams that learned to audit trust stores after the eMudhra root removal already have the inventory this needs.

Two practical notes. You can opt a destination out per domain with <certificateTransparency enabled="false"/> inside its <domain-config>, which is the documented escape hatch if testing shows you need it. And from API 37, if you have defined no configuration for localhost, an implicit one applies that allows cleartext and enforces neither CT nor pinning — useful to know before you spend a day debugging a local test rig that behaves differently from production.

This is the wrong thing to worry about if your app only talks to public TLS endpoints with certificates from public CAs. Then CT is working as intended and you will not notice it.

The large-screen change is the one that costs real money

Everything above is bounded work. The orientation and resizability change is open-ended, because it is design work disguised as a manifest change. The February blog post is direct: “Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp). When you target API level 37, your app must be capable of adapting to a variety of display sizes.”

On a large screen — where the display's smaller dimension is at least 600 dp — these are ignored: screenOrientation and setRequestedOrientation() for the portrait and landscape values, resizeableActivity, minAspectRatio and maxAspectRatio. A portrait-locked activity stops being portrait-locked. There are two exemptions, and they are narrow: the changes “do not apply for screens that are smaller than sw 600 dp or apps categorized as games based on the android:appCategory flag.”

Read that as a scoping exercise, not a compliance task. Every screen built on a locked aspect ratio needs a tablet and foldable layout, and every camera, signature-capture, scanner or map screen with hard-coded dimensions needs rework. That is worth estimating before you commit to a date, which is why our Android app development practice treats this as a layout audit first and a code change second.

What to do between now and the target API level 37 deadline

Five steps, in the order we would run them:

1. Clear API 36 first. Your extension expires today. Nothing about API 37 matters if your next update cannot be submitted.
2. Build against API 37 in a branch and run your existing suite. The API surface locked in March 2026, so a compile-and-run pass costs days and surfaces the reflection failures — static final fields, MessageQueue internals — immediately.
3. Inventory by category, not by file. Local network calls, SMS OTP paths, widgets using RemoteViews, contacts queries, custom TLS trust. Each maps to one row in the table above.
4. Test the CT and private-CA path on a device. Not a review, a build. This is the item where documentation runs out.
5. Scope the large-screen work separately and fund it separately. It is the only item whose cost is proportional to how many screens you have.

Steps one to four are a sprint for most teams. Step five is a project, and it is the one that slips. If you are weighing whether to do that large-screen adaptation in-house or hand it to a team that has shipped multi-role production Android apps, our Android app development team will scope the audit against your actual screen inventory and tell you which activities need genuine redesign and which only need a layout qualifier. Ask us before August 2027 is a quarter away, not after Play finally publishes the day.