Precise location in Android apps: the location button comes first

Many Android apps ask for precise location by default. Google's policy names the location button as the recommended minimum for precise location, and the change takes effect on 27 January 2027.

What Google's policy saysCopy Anchor Link

The Play Console article "Permissions and APIs that Access Sensitive Information" is the current policy article, and the preview links to it. It announces a location change. It says: "To better protect user privacy, we're updating our Location Permissions policy." For precise location, it says: "We're introducing the location button as the recommended minimum scope for precise location," effective January 27, 2027. The same page says the Contacts Permissions policy takes effect on the same date.

The page also says: "Minimize your requests, choosing lesser sensitive options like coarse location and foreground access whenever possible." It asks apps to "request the minimum scope necessary (for example, coarse instead of fine)." It adds: "You should never request location permissions from users for the sole purpose of advertising or analytics." The article says its summaries are overviews, and that the full policy takes precedence in case of conflict. Check the full policy text before you build.

What the policy does not sayCopy Anchor Link

The announcement does not spell out a rule that one-time, user-initiated actions must use the location button, so this article does not state that as a requirement. The policy's location text does say that Foreground Services access of device location must be user-initiated and temporary, and that location must be limited to essential functions that directly benefit the user.

Our reading, labelled as ours, is that a button the user taps to fetch their location, once, is the natural fit for the recommended minimum. A feature that needs a steady stream of location while the app is open is a different case, and the policy text is the place to check your own case.

Check each place you askCopy Anchor Link

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 actionsCopy Anchor Link

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 fits the policy's recommended minimum scope for precise location.

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 worksCopy Anchor Link

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 asks for the minimum scope necessary 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 dateCopy Anchor Link

The 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 policy page says the Contacts Permissions policy takes effect on the same day, so one audit can cover both.

Explain each request in settingsCopy Anchor Link

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 shipCopy Anchor Link

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 standsCopy Anchor Link

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 notification permission change, 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.

SourcesCopy Anchor Link

• Google Play Console Help, Permissions and APIs that Access Sensitive Information (current policy article): https://support.google.com/googleplay/android-developer/answer/9888170
• Google Play Console Help, preview of the location and contacts changes (secondary): https://support.google.com/googleplay/android-developer/answer/16909972
• OTF pricing: otf-kit.dev/pricing