Android 17 is making location permissions more ‘in-the-moment’ (and harder to over-collect by accident)

Original post (source): Android Developers Blog - “Redefining Location Privacy: New Tools and Improvements for Android 17” (Mar 26, 2026)

• https://android-developers.googleblog.com/2026/03/location-privacy.html

Summary

Android 17’s direction is pretty clear: make “precise location” an explicit, in-the-moment decision, and give users better visibility when apps access location.

The highlights:

1) A new “location button” for one-time precise location

Instead of the classic permission prompt, Android is introducing a dedicated UI element (delivered via Jetpack) intended for responsible, session-based precise location access.

Notable details:

• The button is customizable (colors, outline, size/shape, label choices), but the core location icon stays consistent.
• Jetpack integration aims to make it feel like a normal view, and it should fall back to existing prompts on Android 16 and below.
• Available for testing starting Android 17 Beta 3.

2) Better transparency, closer to camera/mic standards

Android 17 adds clearer location access transparency:

• A persistent indicator when a non-system app accesses location.
• A tap-through view showing recent app use, with quick permission management.

3) “Coarse location” gets smarter in low-density areas

Approximate location will use a population-density-aware approach (instead of a fixed 2km grid), improving privacy guarantees where a small grid can still be identifying.

4) A redesigned runtime permission dialog

The location permission UI is being reworked so the “Precise” vs “Approximate” choice is more visually distinct, nudging users toward the minimum they actually need.

Why this matters

Location is one of the fastest ways to earn a one-star review:

• over-asking feels creepy,
• under-delivering breaks core utility (maps, delivery, travel), and
• confusing permission UX creates churn right when a user is trying to complete a task.

Android’s new patterns are a reminder to treat location access as product design, not just a technical permission.

Tiny win

Audit your location flows in one sitting:

1. List every screen that asks for location and the exact user benefit at that moment.
2. Remove any “ask on launch” location request that is not essential.
3. Add a single “why we ask” line wherever you request precise location.

If you use location for ads/measurement, double-check that your instrumentation still works when more users choose approximate or one-time access.

Read the original: https://android-developers.googleblog.com/2026/03/location-privacy.html