Back to all insights
InsightsAugust 31, 2026

Android Privacy & Permissions in 2026: The Deadlines That Actually Bite

Google Play's target API 36 deadline is 31 August 2026, and three permission policies follow it into 2027. The exact dates, and what breaks.

AndroidPrivacySecurityApp Maintenance
Android Privacy & Permissions in 2026: The Deadlines That Actually Bite

Android Privacy & Permissions in 2026: The Deadlines That Actually Bite

Most articles about Android privacy tell you to "respect user trust" and "only request what you need". That advice is true and it is useless, because it does not tell you what breaks or when.

This one is a calendar. Every date below comes from Google's own developer and Play Console documentation, and every permission is named exactly as it appears in your manifest. If you own an Android app, you can read this and know what to do next.


The deadline that is today

31 August 2026. From today, Google Play will not accept a new app or an app update unless it targets Android 16 (API level 36) or higher.

Existing apps that are already published face a softer but still painful rule. They must target Android 15 (API level 35) or higher to stay available to new users on devices running a newer version of Android than the app targets. An app still sitting on API 34 does not vanish, but new users on modern phones stop seeing it in the Play Store. Your install rate quietly drops and nothing in the Console shouts about it.

There are exceptions worth knowing:

  • Wear OS and Android Automotive OS apps need API 35 or higher, not 36.
  • Android TV and Android XR apps need API 34 or higher.
  • Permanently private apps distributed only inside one organisation are exempt.

If you cannot make it, Google allows an extension to 1 November 2026. The extension form appears in your Play Console. An extension is a reprieve, not a fix, and it buys you nine weeks.


What actually changes when you target Android 16

Raising targetSdk is not a version-number edit. The platform changes how it treats your app the moment that number goes up. These are the changes that catch business apps.

Local network access now needs a permission

This is the one that breaks apps silently. Android 16 gates all local network access behind the NEARBY_WIFI_DEVICES runtime permission. That covers mDNS, SSDP, NsdManager service discovery, direct TCP and UDP connections to local IP addresses, and multicast or broadcast traffic.

Without the permission your sockets fail with:

sendto failed: EPERM (Operation not permitted)
sendto failed: ECONNABORTED (Operation not permitted)

If your app talks to a printer, a scanner, a Chromecast, a point-of-sale terminal, a site controller, or any hardware on the same Wi-Fi network, test this before you ship. DNS requests to port 53 are exempt.

You can force the restriction on early and test it today:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <your.package.name>
adb reboot

Body sensor permissions were replaced

BODY_SENSORS and BODY_SENSORS_BACKGROUND no longer work. They are replaced by granular health permissions such as READ_HEART_RATE and READ_HEALTH_DATA_IN_BACKGROUND, covering heart rate, SpO2, and skin temperature.

There is a trap here. A mobile app using the new health permissions must also declare an activity that displays the app's privacy policy. If you do not, the permission is revoked. Your feature stops working in the field, not at build time.

The photo picker pre-selects your own photos

When a user grants "selected photos" access to an app targeting API 36, the photo picker now pre-selects images your app already owns. Users can deselect them, which revokes your access to those files. Handle that state change rather than assuming a file stays readable.

Edge-to-edge is mandatory

windowOptOutEdgeToEdgeEnforcement is deprecated and disabled for apps targeting Android 16. Your layout draws behind the system bars whether you planned for it or not. If you have never applied window insets, expect content under the status bar and buttons under the navigation bar.

Fixed orientation is ignored on large screens

On any display with a smallest width of 600dp or more, Android 16 ignores screenOrientation, resizableActivity="false", minAspectRatio, maxAspectRatio, and setRequestedOrientation(). Portrait-only apps become resizable on tablets and foldables.

You can opt out for now with the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY property. That escape hatch stops working in API 37, so treat it as a stay of execution. Games are exempt.

Predictive back replaced the old callback

onBackPressed() and KEYCODE_BACK are no longer called. Migrate to OnBackPressedDispatcher. If your app has a custom back behaviour, such as a wizard that steps backwards through a form, test it or it will simply close.


Three permission policies coming after the deadline

The API 36 deadline is the visible one. Three Play policies are working their way through the same pipeline, and they change what you are allowed to ask for at all.

Permission Alternative Google wants Compliance date
READ_MEDIA_IMAGES, READ_MEDIA_VIDEO Android Photo Picker 28 May 2025, already enforced
READ_CONTACTS Intent.ACTION_PICK_CONTACTS January 2027, for apps targeting API 37+
ACCESS_FINE_LOCATION Location Button, or ACCESS_COARSE_LOCATION 27 January 2027, for apps targeting API 37+

Photos and video: this one already bites

The Photo and Video Permissions policy reached full compliance on 28 May 2025. Broad READ_MEDIA_IMAGES and READ_MEDIA_VIDEO access now requires an approved declaration proving the permission is essential to core functionality. Apps that fail are subject to removal.

One detail catches teams out repeatedly: building your own custom picker does not qualify you for the permission. Google's position is that if a picker is all you need, use the Android Photo Picker, which needs no permission at all.

Contacts: your 2027 problem, starting now

Introduced in April 2026, this restriction applies to apps targeting Android 17 (API level 37) or later, with compliance mandatory in January 2027. You may only request READ_CONTACTS if the Android Contact Picker is not sufficient. The Play Console declaration asks you to choose from eleven predefined use cases and explain why the picker does not work for you.

Location: the biggest change of the three

Google announced the Minimum Scope policy for location on 15 April 2026. Compliance becomes mandatory on 27 January 2027 for all apps targeting API 37 and higher, new and existing, with enforcement expected to begin from late October 2026.

For one-off precise location needs you are expected to use the Location Button, which grants precise location for a single session that expires when the session closes. You declare it with the onlyForLocationButton flag in your manifest. For anything that does not need street-level precision, such as regional pricing or a weather panel, ACCESS_COARSE_LOCATION is the expected choice.

If you genuinely need persistent ACCESS_FINE_LOCATION, you must complete a declaration and show that neither coarse location nor the button can serve your core functionality. "Nice to have" will not survive review.

Background location has its own bar

ACCESS_BACKGROUND_LOCATION was already the hardest permission to keep. The Play Console declaration requires a video of 30 seconds or less demonstrating the feature that needs background location and showing the steps a user takes to enable it in your app. On top of that you need prominent disclosure in the store listing, a privacy policy linked both on the listing and inside the app, and language in that policy that actually describes background collection.

If you run a delivery, inspection, or field-service app, this is not optional paperwork. It is the difference between shipping and not shipping.


What to do this month

Work through this in order. The first three items are the ones with a live deadline.

  1. Check your current target. Open build.gradle and read targetSdk. If it is below 36, you cannot publish an update from today.
  2. Request the extension if you need it. The form is in Play Console. It moves you to 1 November 2026 and no further.
  3. Test local network access. Run the adb compat command above against any build that talks to hardware on the LAN. This failure mode produces no crash report, only support tickets.
  4. Audit your manifest against the restricted list. Search for READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_CONTACTS, ACCESS_FINE_LOCATION, and ACCESS_BACKGROUND_LOCATION. For each one, write down the feature that needs it. If you cannot name the feature in a sentence, remove the permission.
  5. Replace what you can with pickers. The Photo Picker and the Contact Picker need no permission and no declaration. Every permission you delete is a declaration you never have to defend.
  6. Test the denial path. Deny each permission and use the app. A refused permission should degrade a feature, not crash a screen.
  7. Reconcile Data Safety with reality. Your Play Console Data Safety answers must match what the code actually collects, including analytics and crash reporting. A stale privacy policy is the most common cause of a rejection that looks mysterious.
  8. Check your large-screen layout. Install on a tablet or a foldable and rotate it. Portrait-only is no longer a decision you get to make.

Why this keeps happening

Every one of these deadlines was published months or years in advance. Apps still miss them, and the reason is structural rather than technical. Nobody owns the calendar.

A build finishes, the team moves on, and the app sits untouched until something breaks. By then the fix is not a small patch. It is a target SDK jump, a permissions audit, a Play Console declaration, and a video shoot, all at once, under time pressure.

The alternative costs very little. Someone checks the Android release notes each quarter, raises the target SDK on a normal release rather than an emergency one, and keeps the Data Safety form honest as the app changes. That is roughly a few hours a month, and it is exactly what our app maintenance plans exist to cover. Ours start at $399 a month, and this class of work is most of what the hours go on.

If you are not sure where your app stands, the fastest answer is a permissions audit against the table above. We are happy to run one. Talk to us and we will tell you what needs to change before January 2027, and what can wait.


Sources

Ready to scope your app?

Book a 30-minute call. You leave with a roadmap, a realistic budget range, and clear next steps.