Google Play's API 36 grace period is over, and the 2027 permission deadlines are already lined up

Since August 31, 2026, Google Play only accepts new apps and app updates that target Android 16 (API level 36) or higher. Wear OS, Android Automotive OS, Android TV and Android XR apps are exempt. Teams that needed more time could ask for an extension to November 1, 2026. That date has passed. If your targetSdkVersion is still below 36, you can't ship an update on Play right now, and that includes the hotfix you might need next week.

Existing apps that aren't being updated have a separate rule. They need to target at least Android 15 (API level 35) to stay available to new users on devices running a newer Android version than the app's target. Below that, the app only shows up for devices on the same Android version or older. So an app nobody has touched in a while doesn't get pulled, it just gets harder and harder to find.

On top of that, Google announced a batch of policy changes on October 29, 2026, with enforcement dates spread across 2027. None of them are urgent today. All of them are the kind of thing that turns into a panic if you notice it two weeks before the deadline.

The calendar for 2027

Here are the dates from Google's Policy Deadlines table and the Play policies page:

• January 27, 2027: contacts. The Contacts Permission policy restricts broad access to users' contacts. Apps that don't need broad access must use the Android Contact Picker.
• January 27, 2027: precise location. Apps targeting Android 17 (API 37+) must use the Android location button for one-time or infrequent precise location requests. If you keep ACCESS_FINE_LOCATION, you need a Play Console declaration explaining why the location button or coarse location isn't enough.
• January 27, 2027: subscription discounts. Subscriptions with ongoing eligibility-based discounts, such as student plans, must clearly disclose the eligibility criteria, how verification works, and what happens to price and benefits once the user is no longer eligible.
• April 14, 2027: AppFunctions. AppFunctions must not deceive or manipulate AI agents, bypass their security controls, or interfere with other apps.
• August 25, 2027: ACCESS_LOCAL_NETWORK. Local network access is restricted to apps that need it for core functionality when device pickers such as NsdManager aren't enough. Apps targeting Android 17 or higher need a Play Console declaration to use it.
• August 25, 2027: MANAGE_CONTACTS. Restricted to apps whose core functionality needs it when system pickers aren't enough, with a Play Console declaration. Everyone else must use narrowly scoped platform intents.

Why the target API bump keeps catching teams out

In our native Android projects, raising targetSdkVersion is rarely the hard part. Changing one number in Gradle takes a minute. The work is everything that number switches on: new platform behavior your app now opts into, libraries that haven't caught up, and test devices that don't cover the new version. We've watched a one-line change turn into a three-week sprint because a payment SDK or a BLE library hadn't shipped a compatible release yet.

The pattern we see most often is this: the app works, nobody is assigned to it, and the target API requirement shows up as a Play Console warning that lands in a shared inbox. Then a real bug appears, the fix is ready, and the upload gets rejected. Now you're doing a platform migration under pressure, with a production issue open. That's the situation a lot of teams are in this week.

My honest opinion: treat the yearly target API bump like a dependency you own, not a Google chore. Put it on the roadmap every spring, when the new requirement is announced, and do it while nothing is on fire.

The permission changes matter more than they look

The 2027 rules share one idea. Broad permissions are being replaced with system pickers and buttons, and if you want to keep the broad version you have to explain yourself in the Play Console.

We've seen this most clearly in healthcare and IoT apps. IoT apps tend to ask for local network access early, because device discovery is the first screen, and it's easy to request more than you need. If a picker built on NsdManager covers your discovery flow, the August 2027 rule is mostly paperwork you can avoid. If it doesn't, start writing down now why core functionality needs the permission, because that's what the declaration asks for.

Contacts are similar. Plenty of apps request full contact access for a single "invite a friend" screen. The Contact Picker handles that case, and moving to it before January removes a permission users distrust anyway. From the security side, this is also good news. In our pentesting engagements, over-broad permissions are a recurring finding: data the app never needed, sitting in a local cache, available to anyone who gets a foothold on the device. Less access means less to leak.

The location button rule only applies once you target Android 17, but if you ship a store finder or a "use my location" checkout field, plan the UI change now. A one-tap button is a different flow from a runtime permission dialog, and designers will want a say.

Don't skip the subscription and AppFunctions rules

The subscription disclosure rule is easy to miss because it lives in product and legal territory, not in code. If you offer a student or other eligibility-based plan, someone has to write down the verification process and the post-eligibility price on the paywall itself. On the web and backend work we do for enterprise clients, this kind of requirement usually means a change to both the app copy and the server that decides who is still eligible, so involve the backend team early.

AppFunctions is newer ground. The policy is short: don't trick AI agents, don't get around their security controls, don't interfere with other apps. If you're exposing app actions to agents, review them the way you would a public API. Check what each function can do without user confirmation, and assume something will call it with inputs you didn't expect.

What to do this week

1. Check your target API level today. If it's below 36, the upgrade is now blocking every release. Branch, bump, run your full test suite on an Android 16 device, and update any library that breaks.
2. Audit your manifest. List every use of READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION and ACCESS_LOCAL_NETWORK, and next to each one write whether a picker or button could replace it.
3. Put the 2027 dates in a shared calendar with an owner for each, not just a Slack reminder.
4. Assign someone to the Play Console inbox. Most of the pain we see starts with a warning nobody read.

If you want to see how we've handled platform migrations like this before, our portfolio has a few examples, and our development work covers both native Android and the backends behind it.

If a stuck targetSdkVersion or a permission audit you keep putting off sounds familiar, let's talk.