Minimum Scope: Foreground Location Access and the Location Button

Note: This policy help article provides guidance for foreground device location and the location button. For information on background device location, please refer to the Understanding location in the background permissions help article.

Establishing clear guidelines for device location data access is critical to building user trust and maintaining a safe ecosystem. This article details the requirements for apps' use of the new Android location button, as well as the standard use of foreground device location (ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION). Access to the location in the foreground happens while an app is open and visible to the user. If the access happens when the app is not visible to the user, then the app's access to the location is in the background.

There can be some cases where we approve an app's use of foreground service, a separate API that lets an app access location information even when the app is minimized and not visible to the user. But these are subject to separate review and must meet key requirements outlined in the Permissions for Foreground Services policy.

What does this mean for our Location Permissions policy? Accessing location in the foreground is the most transparent approach for users, which promotes trust and makes it the preferred method for apps on Google Play. Utilizing the Android location button offers an extra layer of privacy and control, ensuring your app meets the minimum scope requirements.

Overview: Minimum Scope for Location Access

To safeguard user privacy, Google Play requires all apps to request the minimum permission scope necessary to provide their core functionality. Please regard the following dimensions when scoping device location:

Precision: Use coarse location (ACCESS_COARSE_LOCATION) if your feature does not strictly require fine-grained accuracy.
Persistence: For one-time or infrequent needs, apps must transition from "persistent by default" to transactional access via the location button.

Background vs. Foreground: This article covers foreground access. If your app requires location while the app is not in use, refer to the background location requirements.

Example use cases where coarse device location may be required:

Localized Content & Discovery

Local News & Trends: Surfacing "News in Chicago" or "Trending in San Francisco" doesn't require knowing a user's exact street address.
Regional Event Discovery: Finding festivals, concerts, or farmers' markets happening in a city or neighborhood.
Coarse Weather Services: Regional weather tends to remain accurate whether the user is at home or three blocks away at a cafe.

Social & Community

Local Marketplaces: For classified listing apps, showing items for sale "within 5 miles" provides enough utility for a buyer without revealing the seller's exact location until they choose to share it.
General "People Nearby": Showing that a friend is “in your city” for social apps, rather than providing a real-time pin on a map.

Utility & Optimization

Store Locators: Showing the nearest branches of a national retail chain or bank. While precise location helps for "walking directions," a coarse location is sufficient to show the three closest stores in a 10-mile radius.

Personalization & Privacy

Targeted Promotions: Offering a coupon for a grocery chain that has multiple locations in a city.
Language & Culture: Automatically setting the app language or currency based on the user's broad region or country.

The Android Location Button (Mandatory for Android 17+)

For apps targeting Android 17 (API level 37) and higher, the Android location button is the required minimum scope method for obtaining precise location for "transactional" (one-time) use cases.

Why is the location button required?

Privacy-First: It grants precise location for a single session only, expiring as soon as the app session is closed.
User Intent: It creates a clear, predictable experience where users know exactly when and why their location is being shared.
Reduced Friction: It eliminates the need for complex runtime permission dialogs for simple tasks like finding a nearby store or tagging a photo.

When is the location button Required?

For apps targeting Android 17+, the button is mandatory for transactional use cases where precise location is only needed momentarily. Common examples include:

Search Nearby: Finding stores, ATMs, or restaurants near the user.
One-time Sharing: Sending a current location to a friend in a messaging app.
Location Tagging: Attaching a location to user-generated content like photos or social posts.
Address Pickers: Helping users autofill a delivery address.

Example Implementation (Manifest)

If your app only requires precise location via the button, you must declare it in your AndroidManifest.xml using the onlyForLocationButton attribute:

XML

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

For technical details, please consult the API documentation.

Requirements for Precise Foreground Location Permission

Apps that require precise, persistent access to ACCESS_FINE_LOCATION (and are not required to use the location button) must meet the following criteria:

Core Functionality: Access must be essential to deliver the main purpose of the app or major product feature as promoted in your Store listing.
Specific Policy Prohibitions: Location permissions may not be requested for the sole purpose of advertising or analytics, and device location data may never be sold.

Play Console Declaration

All apps requesting precise location (ACCESS_FINE_LOCATION) must complete a declaration in the Play Console to demonstrate access needs and justify why the location button or coarse location is insufficient.

The declaration will require you to complete the following questions:

1. Which user-facing features in your app require ACCESS_FINE_LOCATION?

The below chart lists the use cases, their descriptions, as well as a non-exhaustive set of examples. (If your use case is non-user-facing or not listed below, select "Other").

Use Case	Description	Examples
Search nearby	Used for discovering points of interest around the user	Finding nearby restaurants, businesses, parking or available electric scooters.
One time location sharing	Sharing the user's current location with other people or services	Autofiling the user's current address or sharing their current coordinates
Live tracking	Used for continuously monitoring and displaying location in real time	Tracking a runner’s progress, sharing ongoing location with people, and continuous location tracking for functions like measurement, spatial surveying and data collection.
Location tagging by user	Used for attaching a location to user-generated content	Tagging a photo with where it was taken or adding a location to a social media post.
Automated location tagging	Used for automatically attaching location metadata	A camera app adding location to photos.
Personalization	Customize default interface or content feed without user initiated search	Showing restaurants around the user as the apps default view by a restaurant finder app.
Navigation	Used for providing turn-by-turn directions to guide a user along a route	Directions for driving, walking, or cycling
Area specific actions	Used for triggering an action when a user enters or leaves a specific area (geofencing)	Sending a reminder when they arrive at the grocery store or offering a deal when they walk by
Nearby devices	Connecting to nearby Bluetooth/Wi-Fi devices in apps targeting Android 11 (API level 30) or lower where Android requires location permission	Pairing with a Bluetooth speaker, or discovering a smart TV for casting
Browser Location Access	Relaying precise location data to third-party websites or web applications at the user’s request to enable site-specific functionality	A browser passing location to a retail website to autofill a shipping address
Network diagnostics	Monitor, map, or troubleshoot network infrastructure and signal performance	Generating Wi-Fi heatmaps, identifying cellular "dead zones," or analyzing signal strength and tower performance across a service area
Other

2. Explain why ACCESS_COARSE_LOCATION or LocationButton is not sufficient and you need ongoing ACCESS_FINE_LOCATION.

Next Steps & Best Practices

Audit your code: Identify if your app targets Android 17+ and uses precise location for one-time tasks.
Implement the flag: If the button is required, utilize the onlyForLocationButton flag in your manifest.
Review the UI: Ensure your button follows Android design guidelines for consistency.

Frequently Asked Questions (FAQs)

When will the location button requirements be enforced?

We anticipate enforcement for apps targeting Android 17+ to begin in late October 2026. This timeline will harden as we gather more developer feedback; please monitor the Play Console for updates.

Are existing apps exempt from these requirements, or can they be granted an extension until they release an update?

No. All apps—both new and existing—that target Android 17+ must comply with these requirements. Updates to existing apps that do not meet these standards may be rejected.

Can I still use the standard ACCESS_FINE_LOCATION permission?

Only if your 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 be required to justify this during the Play Console declaration process.

What are the primary use cases for the location button versus precise permission?

Use the location button for: One-time "search nearby" queries, tagging a location on a social post, or helping a user pick an address.

Use precise location permission for: Features requiring continuous, real-time tracking while the app is active, such as fitness tracking or active navigation.

Does the location button work for background location?

No. The location button is strictly for foreground, transactional use. Background needs must still follow the background location review process.

Was this helpful?

How can we improve it?