Requesting access to location in the background

Academy Logo

Free training.

Learn more about how you can minimize your use of location data to protect user privacy at Academy for App Success.
 
We realize that compliance with the Location policy may require substantial work for some developers, so we are offering an extended timeline to make any necessary changes.

Google Play restricts the use of high risk or sensitive permissions.

We will soon begin prohibiting unnecessary access to location in the background.

Your app should not request access to location in the background unless it’s required. If your app requests access to location in the background but it’s not critical to the app’s core functionality, you must remove it from your app and / or implement location access in the foreground, such as when your app’s activity is visible to users. You can find details on policy compliant implementation below.

Get approval for your app’s access to location in the background

Before we implement this policy change, you will be able to submit your use case for your existing app via the Play Console and receive feedback on its compliance with the new policy. This gives you an opportunity to receive actionable feedback before the policy is fully enforced and enough time to make the right changes.

We suggest that you review location best practices and evaluate whether you really need to access location in the background before making and submitting changes.

Timeline for review and approval changes

Beginning September 30, 2020,  we will start reviewing apps that request access to location in the background. If your app is impacted, you will be notified on the App content page (Policy > App content) in the Play Console to complete the permissions declaration form.

Beginning January 18, 2021, all new apps (first published after April 16, 2020) submitted to Google Play that access location in the background will need to be approved before they can go live.

Beginning March 29, 2021, all existing apps (first published before April 16, 2020) that access location in the background will need to be approved or they will be removed from Google Play.

App review considerations

When reviewing your app, we’ll consider:

  • Does the feature deliver clear value to the user?
  • Would users expect the app to access their location in the background?
  • Is the feature important to the core purpose of the app?
  • Can you deliver the same experience without accessing location in the background?

Note: This list is not exhaustive, but intended to give you an idea of how your apps use of location permissions may be reviewed and interpreted.

Core functionality is defined as the main purpose of the app. This may comprise a set of core features, which must all be prominently documented and promoted in the app's description. Without the core feature(s), the app is "broken" or rendered unusable.

Best practices and guidance for accessing location data

This section contains best practices and guidance for accessing location data, alternative options, and tips on how you can make location data access clearer to users.

Best practices

We encourage all developers to review the following best practices for accessing location data in their apps:

  • Review the background location access checklist to identify any potential access in your code. Remember you are also responsible for ensuring all third-party SDKs or libraries that you use comply with our policies, including use of location permissions.
  • Minimize your use of location by using the minimum scope necessary to provide a feature (i.e., coarse instead of fine, foreground instead of background).
  • Review privacy best practices and ensure you have the proper disclosure and privacy policies in place.
  • You should never request location permissions from users for the sole purpose of advertising or analytics.
Additional guidance for accessing location in the background

Your app should request the minimum scope necessary (such as coarse instead of fine, and foreground instead of background) to provide the current feature or service requiring background location access. Users should reasonably expect that the feature or service needs the level of location requested. For example, we may reject apps that request or access background location without adequate justification.

Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.

Apps are allowed to access location using foreground service (when the app only has foreground access, e.g. "while in use") permission if the use:

  • has been initiated as a continuation of an in-app user-initiated action, and
  • is terminated immediately after the intended use case of the user-initiated action is completed by the application.

Apps designed specifically for children must comply with the Designed for Families policy.

Alternatives for features requiring access to location in the background

Below is a list of potential features that can often be used with access to location in the foreground instead. Having these features does not mean that your app will be automatically rejected. However, if these features are the only reason your app requires access to location in the background, then the chances of rejection are higher.

  • Suggest nearby friends / players / connections to add only when the user is in the app [excludes suggesting nearby friends / players / connections while the app is closed]
  • Personalized in-app content based on user location (i.e. music playlist for home, local news, etc) without any notification / alert / feature to user when the app is closed 
  • Restrict content to enforce region-based digital rights management
  • Delivery/service (for example, food, package, or ride) tracking on the user side (not driver)
  • Turn-by-turn navigation [not applicable if any functionality is done while the user is outside the app, such as passive tracking of routes / steps, monitoring when a user starts or stops driving, etc.]
  • Aggregating user location data to show traffic patterns / high congestion points or map nearby internet speeds

Note that this is not an exhaustive list, and each app will be evaluated based on its declared core functionality. However, if your app only has functionalities such as those above that require use of location in the background, please consider replacing location access in the background with access to location in the foreground instead.

Making access to location in the background clearer to users

If you plan to use location in the background in your app, you should communicate this to users in the Google Play store listing via your app description, screenshots, and (if applicable) title or icon. 

Here are some suggestions on how to highlight use of location in the background to users:

  • Provide a short description to signal "location" (for example, "find anywhere" or “always know where”).
  • Include an in-app screenshot that shows a map / user location or geotagged images. 
  • If applicable, your app title or icon may also signal the location feature of your app.

Video demonstration

As part of the permissions declaration, you must provide a link to a short video that demonstrates the location-based feature in your app that requires access to location in the background (while the app is not in use). 

The video should demonstrate the background location feature and the required steps to encounter and enable this feature in-app. The video should show:

  • Runtime prompt,
  • the prominent in-app disclosure dialog displayed to users (described below),
  • and the feature being activated from the background.

The recommended duration is 30 seconds or less. A YouTube link is the preferred video format, but cloud storage links to an mp4 or other common video file formats are also supported.

Prominent disclosure

If your app accesses location in the background, you must provide an in-app disclosure of your data access, collection, use, and sharing. The in-app disclosure:

  • Must be within the app itself, not only in the app description or on a website;
  • Must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings;
  • Must describe the data being accessed or collected;
  • Must explain how the data will be used and/or shared;
  • Cannot only be placed in a privacy policy or terms of service; and
  • Cannot be included with other Disclosures unrelated to personal or sensitive data collection.
  • Does not need an “accept” or “I understand” granted by the user; enabling the user to close or swipe away are acceptable ways to migrate out of the disclosure.

It MUST also include this language explaining background location usage to the user:

  • “[This app] collects location data to enable ["feature"], ["feature"], ["feature"] even when the app is closed or not in use.

Additionally, if you extend permitted usage to ads, you must include the following:

  • “This data is also used to provide ads/support advertising/support ads.” (Choose the most accurate phrasing.)

The prominent disclosure may include other information to ensure compliance to policy requirements and clarity for users but must at least include the above, where relevant.

Frequently asked questions

My app has multiple features that use location in the background. What should I do?

You can only declare one app feature that uses location in the background for review. If your app contains multiple features that are both core to the app’s purpose and use location in the background, select the feature that provides the most significant benefit to the user. 

For example, a family companion app that uses location in the background to notify users of nearby offers and triggers an alert if a child leaves a geo-fenced region. The child safety geo-fencing feature should be used on your permission declaration as it delivers more user benefit (perceived safety) than the location-contextual ads (convenience / personalization).

Google Play will establish location in the background eligibility based upon review of the primary app feature you declare; however approval is contingent upon using location in the background is granted at the app level. It is your responsibility to ensure any other features that may use location in the background being policy compliant, including requirements pertaining to are disclosed to the user through the prominent user- facing in-app disclosure.

Where do I find the declaration?

The Location permissions declaration will be available in the Play Console on September 30, 2020. If your app APK or app bundle contains ACCESS_BACKGROUND_LOCATION and targets Android 10 or newer (SDK level 29 or higher) you will be directed to complete details on location usage on the App Content page.

If your app only accesses location in the background in APKs or app bundles targeting Android 9 or older (SDK level 28 or lower) and contains either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, you will need to indicate your intention to access location in the background on the App Content page in the Play Console. You will then be directed to complete details on location usage.

What if I have an old APK with Location permissions and can't make code changes?

If you have old APKs with Location permissions and you are no longer able to make code changes to these APKs you may apply for a policy exception.

In order to qualify for the exception, you must meet ALL of the following requirements:

  • You must declare the specific APK(s) for which you would like an exception.
  • The APKs requesting an exception must have been published before January 1, 2019.
  • You must have alternative APKs served to users on Android Oreo (API Level 26) or higher, and these must be compliant with the Location permission policy.
  • The APKs requesting an exception must represent a very small percentage (no more than low single-digit %) of your total install base.

Google Play will review the request and grant exceptions on a case by case basis. Alternatively, you may choose to unpublish the violating APKs to be compliant with the Location permissions policy.

Related content

Was this helpful?
How can we improve it?