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.

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.
- Check your current target. Open
build.gradleand readtargetSdk. If it is below 36, you cannot publish an update from today. - Request the extension if you need it. The form is in Play Console. It moves you to 1 November 2026 and no further.
- Test local network access. Run the
adbcompat command above against any build that talks to hardware on the LAN. This failure mode produces no crash report, only support tickets. - Audit your manifest against the restricted list. Search for
READ_MEDIA_IMAGES,READ_MEDIA_VIDEO,READ_CONTACTS,ACCESS_FINE_LOCATION, andACCESS_BACKGROUND_LOCATION. For each one, write down the feature that needs it. If you cannot name the feature in a sentence, remove the permission. - 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.
- Test the denial path. Deny each permission and use the app. A refused permission should degrade a feature, not crash a screen.
- 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.
- 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
- Meet Google Play's target API level requirement, Android Developers
- Behavior changes: apps targeting Android 16 or higher, Android Developers
- Understanding restricted permissions with minimum scope alternatives, Play Console Help
- Minimum Scope: foreground location access and the Location Button, Play Console Help
- Understanding location in the background permissions, Play Console Help
- Required actions to comply with the Photo & Video Permissions policy, Play Console Help
Keep reading
Google Play Policy Updates: How to Avoid Rejections
A practical guide to Google Play policy updates and how to avoid rejection with data safety, permissions, and compliance checks.
Read articleAndroid 15 for Business Apps: What to Update Before Launch
A practical Android 15 update guide for business apps: compatibility checks, permission changes, performance tuning, and Play Store readiness.
Read articleCrash-Free Users vs Crash-Free Sessions: What Firebase Crashlytics Actually Measures
Crash-free users and crash-free sessions are not the same metric. Here is exactly how Firebase Crashlytics calculates each one, which benchmark to hold your app to, how Sentry compares, and the release playbook we use to stay above 99%.
Read article