Google Play is changing how Android apps should request precise location. For apps targeting Android 17 (API level 37) or later, Google’s new minimum-scope policy says one-time precise-location use cases should use the Android Location Button instead of requesting broad ongoing ACCESS_FINE_LOCATION access.
The policy is part of Google’s wider push toward minimum-scope access for sensitive data. Developers who still need persistent precise location will have to justify why a one-time Location Button or approximate location is not sufficient.
What is the Android Location Button?
The Location Button is designed for user-initiated, transactional location requests. Instead of granting an app broad precise-location access, the user explicitly taps a button when the app needs a precise position for a specific task.
Google says this model is appropriate for cases such as:
- finding nearby stores, ATMs or restaurants,
- sharing a current location once,
- tagging a photo or post with the current place,
- filling an address or local result on demand,
- and browser or web flows that need precise location only for the current interaction.
The goal is to reduce persistent access when the app only needs location for a short-lived action.
When is ACCESS_FINE_LOCATION still allowed?
Google is not removing ACCESS_FINE_LOCATION. Apps can continue using it when precise location is essential to a core, persistent feature that cannot reasonably be delivered with the Location Button or approximate location.
Google’s examples include use cases such as active turn-by-turn navigation and continuous fitness tracking. In those situations, a one-time location grant would not provide the functionality the user expects.
Developers requesting ongoing precise location should be prepared to explain why ACCESS_COARSE_LOCATION and the Location Button are technically insufficient.
The new Play Console timeline
- April 15, 2026: Google announced the new minimum-scope location policy.
- November 2026: Google says declarations for apps using precise location will become available in Play Console.
- January 27, 2027: Compliance becomes mandatory for apps in scope. Google says a 30-day self-extension will be available.
The policy applies to both new and existing apps that target Android 17 or later. Google also says updates to existing apps can be rejected if they do not meet the requirements after enforcement begins.
What developers should audit now
Before the declaration period opens, review the release manifest and every feature that touches location. The permission can come from your own code or from an SDK included in the app.
A useful audit should answer:
- Does the app actually need precise location?
- Is the need continuous or only user-initiated?
- Would approximate location be good enough?
- Can the Location Button cover the workflow?
- Does any third-party SDK add
ACCESS_FINE_LOCATIONunnecessarily? - Is the privacy disclosure consistent with the real behavior?
The onlyForLocationButton manifest flag
Google’s current guidance says developers implementing the Location Button for Android 17+ should use the onlyForLocationButton permission flag in the manifest. The flag is part of the platform’s minimum-scope model and helps indicate that the precise-location capability is intended for the button-driven flow.
Because Android 17 targeting and Play policy are both evolving areas, developers should verify the final SDK syntax against the latest Android documentation before shipping a production build.
How this fits with Google’s contacts policy
The same minimum-scope philosophy is also being applied to contacts. Apps targeting Android 17+ that request broad READ_CONTACTS access are now expected to use the Android Contact Picker when that smaller scope is sufficient.
See our Google Play READ_CONTACTS policy guide for the contacts timeline, and our Android 17 features guide for the broader platform changes.
What users gain from the change
For users, the benefit is clearer intent. An app that only needs location to find a nearby store should not necessarily retain broad precise-location access after that task is finished. A one-time, user-triggered mechanism creates a tighter connection between the action and the data being shared.
For developers, however, the policy requires more careful permission design. Apps that have historically requested precise location by default may need to split their workflows into transactional and persistent use cases before the 2027 enforcement deadline.
Start the conversation
Corrections, useful experiences and focused questions are welcome. Keep discussion respectful and on topic.