BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Google's Play preview calls the Android location button the recommended minimum for precise location
Google's Play Console preview names the Android location button the recommended minimum for precise location, effective 27 January 2027. The preview says the full policy governs in a conflict, and a dev.to author reports that text is stricter.
The Engineer · Build desk
Preview: location button is the recommended minimum for precise; full policy wins a conflict. Per a dev.to author, full policy makes the button a must for one-time, user-initiated uses, allows precise only where button or coarse cannot serve. Many Android apps ask for precise by default.
- decision Play Console preview Calls the location button the recommended minimum scope for precise location, claim 2
- constraint Full policy (dev.to author) Apps needing precise location only for one-time, user-initiated actions must use the location button, claim 16
- constraint Full policy (dev.to author) Allows precise location only where the button or the coarse permission cannot support the feature, claim 17
- precedent Full Play policy Takes precedence over the preview in case of conflict, the preview states, claim 6
- exposure Android apps Many ask for precise location by default, claim 18
| Who | How | Kind | Claim |
|---|---|---|---|
| Play Console preview | Calls the location button the recommended minimum scope for precise location | decision | 2 |
| Full policy (dev.to author) | Apps needing precise location only for one-time, user-initiated actions must use the location button | constraint | 16 |
| Full policy (dev.to author) | Allows precise location only where the button or the coarse permission cannot support the feature | constraint | 17 |
| Full Play policy | Takes precedence over the preview in case of conflict, the preview states | precedent | 6 |
| Android apps | Many ask for precise location by default | exposure | 18 |
What happened
- The Play Console help page is labelled a preview of changes from Google's April 2026 policy updates.
- The page also tells developers to choose lesser sensitive options such as coarse location and foreground access whenever possible.
- The contacts policy, which the page calls new, takes effect on the same date.
- According to the dev.to author, the full policy allows fine-grained location only where the location button or the coarse permission cannot support the feature.
Why it matters
- contradiction The preview says "recommended", but the dev.to author reports the full policy says "must" for one-time, user-initiated requests, and the preview says the full policy wins a conflict. Plan to the stricter text.
- decision Apps that ask for precise location by default have to pick, screen by screen: move to the button, drop to coarse, or keep fine and write down why.
- cost The work lands in three places, the permission requests, the button labels and the tests, and the author says the 27 January 2027 date leaves time for all three.
The audit the dev.to author describes is mechanical. Start with every screen that asks for precise location, and record what each feature is, what sets it off and how frequently it fires [8]. Something done once, like "use my location" on a search screen, is the first candidate for the button. A feature that runs on every app open needs a stronger case [9].
Then ask whether the feature needs street-level position at all. Many need only a city or a region. Coarse location covers that, and the policy asks developers to choose it whenever it works [10].
On the button path, the user taps, the app asks for location for that single action, and the request follows from a choice the user made [14]. The label has to stay true to that. If the app later reuses the location for another feature, the author says the label is wrong and the policy is the reason to fix it [15].
The author reads a tap-to-fetch-once control as the button's intended use. Continuous location while the app is open is another matter, and the author leaves it to be confirmed against the full policy [7]. In our view the streaming case is where an app will have to make its argument.
The stricter wording is second-hand. The article says it reads the preview, not the full policy, and tells developers to check the full policy before building [11]. It does not describe enforcement or say what happens to an app that misses the date.
The author's test plan runs on real devices. With permission denied, the feature should explain what is missing, with no crash and no prompt loop. With coarse only, it should still do its job or say what it cannot do. On a button tap, the location should arrive once, for that action [12]. A fourth case is reopening the app after a denial [13]. The author's advice is to work backward from 27 January 2027 [3].
What to watch
- The full Play policy text: whether its one-time, user-initiated wording matches what the dev.to author reports.
- Any Google guidance on features that need continuous location while the app is open, the case the author sends back to the full policy.
- Whether the contacts policy, also effective 27 January 2027, gets its own requirements before the date.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap−10
- Incentives30
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The Play Console help page is a preview; it says: "This article previews changes from our April 2026 policy updates."
ReportedSupportedSource: Google Play Console help page, as quoted by the dev.to articleView cited source - [2]
For location, the preview page says: "We're introducing the location button as the recommended minimum scope for precise location."
ReportedSupportedSource: Google Play Console help page, as quoted by the dev.to articleView cited source - [3]
The effective date for the location change is January 27, 2027, and the article advises working backward from it.
- [4]
The same date applies to contacts, which the preview page describes as "a new policy."
ReportedSupportedSource: Google Play Console help page, as quoted by the dev.to articleView cited source - [5]
The preview page also says to choose "lesser sensitive options like coarse location and foreground access whenever possible."
ReportedSupportedSource: Google Play Console help page, as quoted by the dev.to articleView cited source - [6]
The preview states that the full policy takes precedence in case of conflict.
- [7]
The author reads a button the user taps to fetch their location once as the case the location button is built for, and treats a feature needing a steady stream of location while the app is open as a different case to confirm in the full policy.
- [8]
The author's audit starts with a list of every screen that asks for precise location, noting the feature, the trigger and how often it runs.
- [9]
The author says a one-time action such as "use my location" on a search screen is the first candidate for the location button, and a feature that runs on every app open needs a stronger case.
- [10]
The author says many features need only the user's city or region, that coarse location covers that case, and that the policy asks developers to choose it whenever it works.
- [11]
The article says it reads the preview, not the full policy, and tells developers to check the full policy before building.
- [12]
The author's test list: with permission denied, the feature should explain what is missing and the app should not crash or loop on the prompt; with coarse only, the feature should work or say clearly what it cannot do; on a location button tap, the location should arrive once, for that action.
- [13]
The author's test list includes a fourth case: opening the app again after a denial.
- [14]
On the location button path, the user taps the button, the location is requested for that action, and the request is tied to something the user chose.
- [15]
The author says that if the app later uses the location for something else, the button's label is wrong, and the policy is the reason to fix it.
- [16]
According to the dev.to author, the full policy says an app that needs precise location only for one-time, user-initiated actions must use the Android location button.
- [17]
According to the dev.to author, the full policy allows precise (fine-grained) location only where the app's features cannot be supported by the location button or by the coarse permission.
- [18]
Many Android apps ask for precise location by default.
- [19]
The author says the 27 January 2027 date leaves time to change the requests, the labels and the tests.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toPrecise location in Android apps: the location button comes first
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.