Many Android apps ask for precise location by default. Google's preview policy names the location button as the recommended minimum for precise location, and it takes effect on 27 January 2027.
What Google's preview says
The Play Console help page is a preview. It says: "This article previews changes from our April 2026 policy updates." For location, the page says: "We're introducing the location button as the recommended minimum scope for precise location." The effective date is January 27, 2027. The same date applies to contacts, which the page describes as "a new policy."
The page also says: "choosing lesser sensitive options like coarse location and foreground access whenever possible." It states that the full policy takes precedence in case of conflict. This article reads the preview, not the full policy, so treat the preview as the direction of travel and check the full policy before you build.
What the full policy adds
The full policy is more specific than the preview. It says that if your app needs precise location only for one-time, user-initiated actions, it must use the Android location button. It also says precise location, which is the fine-grained permission, is allowed only where your features cannot be supported by the location button or by the coarse permission.
Our reading is that a button the user taps to fetch their location, once, is the case the location button is built for. A feature that needs a steady stream of location while the app is open is a different case, and the full policy is the place to confirm it. The rules below are ours, and they are labelled as ours.
Check each place you ask
Start with a list of every screen that asks for precise location. For each one, write down the feature, the trigger and how often it runs. A one-time action, such as "use my location" on a search screen, is the first candidate for the location button. A feature that runs on every app open needs a stronger case, so note it for review.
Then ask whether the feature needs the street-level position at all. Many features only need the user's city or region. Coarse location covers that case, and the policy asks you to choose it whenever it works.
Use the location button for one-time actions
For a one-time action, use the location button in place of a standing permission request. The user taps the button, the location is requested for that action, and the request is tied to something the user chose. That matches the full policy's wording on one-time, user-initiated actions.
Keep the button's label and placement clear. A reader who taps a button labelled "Use my location" should expect the location to be used for that action only. If the app later uses the location for something else, the label is wrong, and the policy is the reason to fix it.
Ask for the smallest scope that works
Our rule is to ask for the smallest scope that still makes the feature work, and to ask only at the moment the feature needs it. An app that asks for everything on first launch gives the user no reason to say yes, and the policy points the other way anyway.
Explain the request in plain words, next to the button or the screen that needs it. Say what the location is used for and that it is used only for that feature. Users who understand the request are more likely to grant it, and the request is easier to defend if anyone asks.
Plan for the 2027 date
The preview's effective date is 27 January 2027, which leaves time to change the requests, the labels and the tests. Work backward from it. Find the screens, classify each request, move the one-time actions to the location button, and test the denied and coarse-only paths before the date.
Keep the contacts request on the same list. The preview says the contacts policy is new and takes effect on the same day, so one audit can cover both.
Explain each request in settings
Write the reason for each location request in the app's own settings screen too. A user who later wonders why the app knows where they are should find the answer in one tap, not in a support email. Keep that text in step with the request label on the screen, so the two never disagree. When a feature changes what it needs, update both at the same time.
Test before you ship
Test on real Android devices, and record what the user sees at each step:
- Deny the location permission. The feature should explain what is missing, and the app should not crash or loop on the prompt.
- Grant coarse location only. The feature should still work for the job it does, or it should say clearly what it cannot do.
- Tap the location button. The location should arrive once, for that action, and the screen should show it.
- Open the app again after a denial. The request should not appear at launch unless the user asked for the feature.
- Check the label and the button on a 390px phone. A long label should wrap without pushing the button off the screen.
Run the phone check last, after the labels are final. A button that works on a tablet can sit below the fold on a small phone.
Where OTF stands
If you want an app already built around precise location, we cannot point you to one. We checked the SaaS Dashboard, Booking, Fitness and Arcade kit pages for location, GPS, map and permission terms, and none of them mentions a location feature or a device permission. So this article does not say any OTF kit ships precise location handling.
The pricing page lists the Full-stack kits at $99 each and the Everything Bundle at $149, both as one-time payments, and it offers a live demo before you buy. Check each kit's repository and its permission settings before you rely on any of them. For the separate permission change Google is previewing for notifications, see the Android notification permission guide. If you are choosing a starting point for a product, the pricing page is the place to compare kits side by side: OTF pricing.
Sources
- Google Play Console Help, preview of permissions and APIs that access sensitive information: https://support.google.com/googleplay/android-developer/answer/16909972
- OTF pricing: otf-kit.dev/pricing
Top comments (0)