Google Play Location Permissions in 2026: A Step-by-Step Tutorial to Adopt the Android Location Button

On April 15, 2026, Google Play announced an update to the Location Permissions policy. The Policy Deadlines table lists it under Permissions and APIs that Access Sensitive Information, with deadline 2027-01-27 — the same date as the Contacts row. The published sentence is short: Play is introducing the location button as the recommended minimum scope for precise location, in line with user-data and sensitive-permissions requirements. If your app targets Android 17 (API 37) or later and still asks for ACCESS_FINE_LOCATION just to search nearby, share a pin once, tag a photo, or fill an address, that is the flow Play now expects to go through the button. KappS is writing this as a policy walkthrough, not as a substitute for the live Help pages.

What you are solving today: audit every precise-location use in the binary and merged SDKs; classify each one as transactional (one-time, user-initiated) or persistent core (navigation, live tracking); migrate the transactional flows to the Android location button; set the published onlyForLocationButton flag when the button is the only precise-location path; and prepare the Play Console declaration that every ACCESS_FINE_LOCATION request now requires. Recheck current Play Console Help for the exact form labels — this tutorial only restates what those Help pages and the Android location-button guide publish.

What Play published (deadline, Help, Android 17)

Official pages describe the same deadline in different lengths. Rest on the table, then the dedicated Help article:

The Policy Deadlines row dated 2027-01-27: “To better protect user privacy, we're updating our Location Permissions policy. We're introducing the location button as the recommended minimum scope for precise location in line with our user data and sensitive permissions requirements. Announced 2026-04-15.”
The April 15, 2026 policy announcement uses the same wording and points you back to Policy Deadlines. Play said you would have at least 30 days from that date to start updating — the enforcement date on the table is still January 27, 2027.
Minimum Scope: Foreground Location Access and the Location Button is the how-to article. It repeats January 27, 2027 as the date policy compliance is mandatory for all apps, with 30-day self extensions available in Play Console. The declaration for apps that request ACCESS_FINE_LOCATION becomes available in November 2026. Enforcement for apps targeting Android 17+ is anticipated in late January 2027.
Permissions and APIs that Access Sensitive Information and its preview add the Android 17 rule: if precise location is needed only for one-time, user-initiated actions, you must implement the location button and the onlyForLocationButton permission flag. An older preview banner still says “effective October 28, 2026.” Policy Deadlines and the Minimum Scope article now say January 27, 2027 — use those dates, not the leftover October line.

The Android Developers Play policies timeline lists the same Location Permissions sentence under January 27, 2027.

Foreground access is while the app is open and visible. Background access is when it is not. This tutorial is the foreground / location-button path. Background location still follows the separate background-location review. The location button is not a background API.

Step 1 — Audit every precise-location use

Do not start in Console. Start with the binary and every merged library. Help’s test is whether the feature needs precise location at all, and if it does, whether that need is a one-time user action or a persistent core feature.

Walk the real artifacts, not the store listing copy:

Search the merged manifest and dependency manifests for ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION, and — if already present — USE_LOCATION_BUTTON.
Search code and SDK docs for fused-location clients, last-known-location calls, geocoders, map camera moves, and “near me” queries. Mark each call site with the user-facing feature that triggers it.
Ask whether the feature still works if you only have a city-sized coarse fix. Minimum Scope lists coarse-enough examples: local news and trends, regional events, regional weather, “items within 5 miles,” “friend is in your city,” store locators that show the nearest branches in a wide radius, city-level promotions, language or currency from a broad region.
If the user refuses fine location, does the feature continue with coarse, a typed address, or a map pin the user drops? Restricted-permissions policy already expects a reasonable path when the user declines.
Is the feature promoted on the Play listing? Persistent ACCESS_FINE_LOCATION must be essential to the main purpose or a major product feature as promoted in the Store listing.

If the honest answer is “we only need a precise point for one tap,” stop treating that as a standing runtime permission. That is a location-button job.

Step 2 — Classify transactional vs persistent core

For apps targeting Android 17 (API 37) or higher, the location button is the required minimum scope for transactional (one-time) precise location. Help’s common examples:

Search nearby — stores, ATMs, restaurants, parking, or scooters around the user.
One-time sharing — send a current location to a friend, or autofill a current address once.
Location tagging — attach a place to a photo or a social post the user is publishing.
Address pickers — help the user autofill a delivery address.

The button grants precise location for a single session and expires when the app session closes. It is foreground only. It is not a substitute for background location, and it is not a standing grant you can keep using after the user leaves the screen.

Persistent precise foreground is still allowed when it is core and the button or coarse location cannot do the job. Help’s examples of that side:

Navigation — turn-by-turn driving, walking, or cycling.
Live tracking — a runner’s progress, ongoing share with people, continuous measurement or surveying while the app is active.

The FAQ on the same page is blunt: you may still use standard ACCESS_FINE_LOCATION only if the app has a core, persistent feature (for example, turn-by-turn navigation) that cannot be served by a one-time button or coarse location. You will have to justify that in the Play Console declaration.

Two published prohibitions apply to every precise-location request, button or not:

Location permissions may not be requested for the sole purpose of advertising or analytics.
Device location data may never be sold.

Do not invent a third bucket. “We like a more accurate ad cohort” is not a core persistent feature. “The user taps Share location once” is not navigation.

Step 3 — Migrate transactional flows to the Location Button

Play Help and the Android location-button guide describe the same control. Use the Jetpack LocationButton path the Android page publishes. That library is marked experimental and subject to change — file issues on the Android issue tracker, and re-read the live guide before you lock a dependency version.

Published integration facts (do not invent extra APIs or Console buttons):

If the app targets Android 17 (API 37) or later and only contains features that need session-based precise location, Play policy requires the location button.
Declare standard location permissions plus the dedicated USE_LOCATION_BUTTON permission the system remote-rendering service needs.
If precise location is only obtained through the button, add the published onlyForLocationButton flag on ACCESS_FINE_LOCATION. Play Help’s Minimum Scope example writes it as a boolean attribute:

<uses-permission
    android:name="android.permission.ACCESS_FINE_LOCATION"
    android:onlyForLocationButton="true" />

The Android developer guide writes the same flag as a usesPermissionFlags value, together with USE_LOCATION_BUTTON:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton" />
<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

Those two snippets are what the live pages publish today. Use the form that matches the Help article and the Android guide you are implementing against — this page does not pick a third attribute name. Android’s note: adding the flag restricts the app from taking the broader precise-location permission; users must use the button to share a precise point.

Also declare ACCESS_COARSE_LOCATION when coarse is enough for a feature, or when the Jetpack sample still lists it beside fine. Prefer coarse whenever fine is not required.

Jetpack handles older devices: on Android 16 or lower the library falls back to a locally rendered control that keeps your layout and triggers the standard location permission prompt. That is the published compatibility path — not a second permission strategy you invent for API 36.

Then review the UI against Android’s design limits: you may customize colors, outline, shape, and a predefined label set (“Use precise location,” “Share precise location,” and the other listed types). The location icon is mandatory and not customizable; font size is system-managed for accessibility.

If a vendor SDK still requests standing ACCESS_FINE_LOCATION for a “search nearby” or check-in tap, that is the transactional pattern Play is moving onto the button. Replace the SDK flow or replace the SDK.

Step 4 — Prepare the Play Console declaration

Minimum Scope Help: all apps that request precise location (ACCESS_FINE_LOCATION) must complete a declaration in Play Console to show why they need it and why the location button or coarse location is insufficient. The declaration is scheduled to appear in November 2026. This page does not invent a menu path beyond the name Play publishes — use the labels in your account and the Help article linked from that form.

Help says the form will ask:

Which user-facing features require ACCESS_FINE_LOCATION? Pick from the published list: search nearby; one-time location sharing; live tracking; location tagging by user; automated location tagging; personalization; navigation; area-specific actions (geofencing); nearby devices (the older Android 11-and-below Bluetooth/Wi-Fi discovery case); browser location access; network diagnostics; or Other. If the use is not user-facing or not listed, Help says to select Other.
Explain why ACCESS_COARSE_LOCATION or LocationButton is not sufficient and why you need ongoing ACCESS_FINE_LOCATION.

Selecting “search nearby,” “one-time location sharing,” or “location tagging by user” on a build that still holds standing fine location is Help’s example of a button-shaped use. Those rows are not a loophole for skipping the button on Android 17+.

If the only remaining precise-location path is the button, the declaration and the manifest should match: onlyForLocationButton set, USE_LOCATION_BUTTON present, and no leftover library that still takes the broader fine permission.

If you still need persistent fine location for navigation or live tracking, write the technical reason the button or coarse cannot do that job before anyone opens Console. Help’s action item for November: consult the team on whether ACCESS_FINE_LOCATION is required for core functionality, and be ready to explain why the minimum-scope path is not technically sufficient.

After January 27, 2027, in-scope apps that are not compliant are subject to enforcement. A 30-day self extension in Console is published — an extension is not a permanent exception. Existing apps are not exempt: updates that miss the Android 17+ location-button rule may be rejected.

What fails after 2027-01-27

Play publishes outcomes. Do not substitute folklore:

Transactional precise location without the button on Android 17+. Search nearby, one-time share, tagging, or address pick while still taking standing ACCESS_FINE_LOCATION is the pattern Minimum Scope calls the required button case.
Fine location when coarse would do. Eligibility for ACCESS_FINE_LOCATION is only for features that the button (Android 17+) or ACCESS_COARSE_LOCATION (all versions) cannot adequately support.
No declaration on an ACCESS_FINE_LOCATION build. After January 27, 2027, in-scope apps that are not compliant are subject to enforcement. The November 2026 form is how you show the remaining persistent uses.
Fine location only for ads or analytics, or selling location. Help lists both as prohibited, including for apps that otherwise qualify for persistent access.
Using the button as a background workaround. The button is strictly foreground and transactional. Background needs still go through the background-location review.
Treating an older “October 28, 2026” banner as the live deadline. Policy Deadlines and the Minimum Scope timeline now say 2027-01-27. Re-read those two pages before you schedule the release.

If Console shows a new location questionnaire after you read this, follow the live Help article linked from that form. This page does not invent extra buttons, extra API class names, or extra dates beyond 2026-04-15 (announced), November 2026 (declaration available), and 2027-01-27 (Policy Deadlines / mandatory compliance; Android 17+ enforcement anticipated later that month).

A 10-minute checklist

List every feature that reads device location. Mark each one coarse-enough, transactional precise (button), or persistent core (navigation / live tracking).
If a feature is coarse-enough, drop ACCESS_FINE_LOCATION for that path and keep ACCESS_COARSE_LOCATION only.
If every remaining precise use is transactional and you target Android 17+, implement Jetpack LocationButton, declare USE_LOCATION_BUTTON, and set the published onlyForLocationButton flag on ACCESS_FINE_LOCATION.
If a feature truly needs standing fine location, write why the button and coarse cannot do that job — before anyone opens Console.
When the November 2026 declaration appears in Play Console, complete it so the selected use cases match the shipping binary.
Confirm the store listing only promotes features that match the access you still request. Do not request location for advertising or analytics alone, and do not sell location data.
Re-read current Policy Deadlines and the Minimum Scope location-button article before you rely on the 30-day self extension.

The one-line version

If the app targets Android 17+ and only needs precise location for one user tap, Play’s Location Permissions update — announced April 15, 2026, deadline 2027-01-27 — requires the Android location button (with the published onlyForLocationButton flag) instead of standing ACCESS_FINE_LOCATION; keep persistent fine location only when you can declare a core use such as navigation or live tracking and explain why the button or coarse is not enough.