If your Android app asks for precise location to find a nearby store, Google Play wants a button instead

What's changing

Google announced in April that Android is getting a location button: a single tap that gives an app precise location for one moment, instead of the usual permission dialog asking how much and for how long. Google Play's updated Location Permissions policy, effective January 27, 2027, makes it the expected way to handle those moments.

The rule, from Play's policy preview: if your app needs precise location only for one-time, user-initiated actions, you must implement the location button, using the onlyForLocationButton flag in your manifest. Full precise location access is only available for features that neither the button (for apps targeting Android 17, API level 37, or higher) nor coarse location can support, and apps that need persistent precise location have to explain why in a Play Console declaration.

Two other lines in the policy are worth rereading: you must request the minimum scope a feature needs, and you can't request location only for advertising or analytics. A third is easy to miss: apps that request device location, including through the button, are still subject to Play's declaration process and review. The button makes the request smaller. It doesn't make it invisible to review.

Since October 27, Play Console has been running pre-review checks that flag potential location and contacts policy issues before an app goes to review. If you've shipped an update recently and seen a warning, this is probably why.

Which features this covers

Most apps don't need to know where someone is. They need to know where someone is right now, once. Google's own examples are finding a store and tagging a photo. In ordinary apps the list is longer:

• "Find the nearest branch" or "stores near me."
• Filling in a delivery or pickup address from where you're standing.
• Checking whether a service covers your area.
• Tagging a photo, a report or an inspection with a location.
• Sharing where you are once in a chat or a support request.

Each of these starts with the person tapping something, and each needs the location once. That's exactly the case the button is for.

What isn't covered: turn-by-turn navigation, delivery tracking for a driver, fitness tracking and anything else that needs location continuously. Those still use the regular permissions, with a declaration and review.

What to do before January

List every place your app asks for location. Include libraries and SDKs; a maps or analytics SDK can request permissions you didn't write.

Sort each one. One-time and user-initiated: move it to the button. Doesn't really need precise: use coarse. Needs it continuously: keep it, and prepare the declaration.

Drop anything that's there for ads or analytics alone. The policy is clear that it isn't allowed.

Redesign the moment, not just the permission. The button is a visible control, so the screen around it matters. Put it where the person is already deciding, next to the search box or the address field, and make the fallback obvious: someone who doesn't tap it should still be able to type a postcode.

Check Play Console now. The pre-review checks have been flagging location issues since October 27, and they'll tell you which builds need attention before review does.

Questions for the team

Before anyone writes code, a short conversation between product, engineering and whoever owns the privacy policy will save rework. Four questions are enough:

• Which features really need precise location? A store finder that sorts by distance can often work with coarse location, and many people would prefer it.
• Which SDKs ask for location, and why? If the answer is "the ad SDK wanted it," that request has to go.
• What happens when someone says no? Every location feature should still work, more slowly, with a typed address or postcode.
• Who files the declaration? If you keep full precise access anywhere, someone has to write the justification in Play Console and keep it accurate when the feature changes.

The answers usually make the work smaller than it first looks. Most teams find one or two features that genuinely need continuous location, a handful that become a button and a few requests nobody can explain, which can simply be removed.

Why this is good for the app too

A one-tap button is a better experience than a dialog asking for permanent precise access to find a coffee shop. Many people decline that dialog, and some never come back to the feature. A button that does one thing, once, when they ask, is easier to say yes to.

There's a support benefit as well. Permission problems are a common source of one-star reviews and confused tickets: "the map doesn't work," when what actually happened is that someone declined a dialog months ago. A button the person taps each time leaves less hidden state to get stuck in.

It also simplifies your data story. If your app only ever gets precise location in the moment someone taps for it, there's less to explain in a privacy policy, less to store and less to secure.

Apps that already ask for less than they could will find this change small. Apps that ask for everything up front, on first launch, will find it bigger. That's a pattern we've written about before, from the contacts side, in the app that asks for every contact, and the reasoning is the same: ask for what the feature needs, when the feature needs it.

The timing

The policy takes effect January 27, 2027. The button requirement applies to apps targeting Android 17, and target-level deadlines on Play tend to arrive on their own schedule, so the practical deadline is whichever comes first: your move to Android 17 or the policy date. Holiday release freezes make December a poor month to start.

If you'd rather work through your app's location and permission flows once, properly, our mobile applications team can help. Talk to us.

Related work: Spin Market.