1. Background location is a declaration-gated permission. Google Play treats location in the background as sensitive data: apps "that access location in the background must be approved via the permission declaration process in the developer console. Without that approval, app updates may be blocked and your app may be removed from Google Play." (https://support.google.com/googleplay/android-developer/answer/9799150) You cannot simply add ACCESS_BACKGROUND_LOCATION to the manifest and ship.
2. What actually counts as "background". "Access to the location in the foreground happens while an app is open and visible to the user. If the access happens after a user closes the app or uses the home button to return to their main screen, then the app's access to the location is in the background." In other words, any location read while your activity is not visible to the user is background access - including reads performed through a foreground service.
3. Only core functionality qualifies. "Background location may only be used when it provides a significant benefit to users and is relevant to the core functionality of the app." Core functionality means the main purpose of the app, and "the core feature(s) must all be prominently documented and promoted in the app's description." If the feature is not essential - without it the app is not broken or unusable - the declaration is likely to fail.
4. Google explicitly names foreground-doable features. The policy lists things that should normally be done in the foreground: suggesting nearby friends/players/connections only while the user is in the app; personalizing in-app content (local news, playlists) with no closed-app feature; region-based DRM; delivery/service tracking for users (not drivers); turn-by-turn navigation (unless it also tracks when the user is outside the app); and aggregating location to show traffic or nearby speeds. "If your app only has functionalities such as those above that require the use of location in the background, consider using access to location in the foreground instead."
5. Ads and analytics never justify background location. Two hard statements in the same article: "You should never request location permissions from users for the sole purpose of advertising or analytics" and "Access to the location in the background solely for the purpose of ads will be denied." If you do extend permitted usage to ads, that use must also comply with the Use of Location Data for Ads policies, and the disclosure must say so.
6. The declaration form must describe exactly one feature. Path in Play Console: App content > Sensitive app permissions > Location permissions. You must "Tell us about one location-based feature only in your app that requires access to location in the background and explain why it can't be implemented without this access." The rule is strict: "We can only evaluate one feature at a time. The inclusion of multiple features will result in an app's rejection." Approval is granted for the entire app, not for that single feature, so pick the most defensible, user-benefiting one.
7. Which manifest triggers the form. If your bundle/APK "targets Android 10 or newer (SDK level 29 or higher) and contains ACCESS_BACKGROUND_LOCATION permission in the manifest, you'll be directed to complete details on location usage." If it "targets 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 and then you'll be directed to complete details on location usage."
8. The video demonstration. Provide a short video that "clearly demonstrates the location-based feature being used in your app... Include the term... the prominent disclosure dialog that gets shown to users." Requirements: show the feature running while the app is not in use, plus the steps to enable it, the prominent in-app disclosure dialog and the runtime prompt. "Aim for a video duration of 30 seconds or less. The preferred format is a YouTube link, but Google Drive storage links to an MP4 or other common video file formats are also supported." It "must reflect your app's behavior on an Android device. For example, don't submit a video of your iOS app."
9. Prominent in-app disclosure wording (get this exact). The disclosure must be inside the app and in normal usage, not behind a menu; must describe what data is accessed and how it is used/shared; cannot live only in the privacy policy or terms; and must not be bundled with unrelated disclosures. Language must include the word "location" and use one of these phrases: "background" / "when the app is closed" / "always in use" / "when the app is not in use", and must list all features that use background location. Google's recommended template: "[This app] collects location data to enable [\"feature\"], [\"feature\"], and [\"feature\"] even when the app is closed or not in use." (Add ", and it is also used to support advertising" only if that is true.)
10. Four documents, and the privacy policy must be in two places. The approval pack is: (a) Permissions Declaration Form, (b) video demonstration, (c) prominent in-app disclosure, (d) "Privacy policy both in your app and on its store listing page." You must also communicate background location in the store listing itself (description, and ideally a screenshot that shows a map/user location or geotagged content; title/icon wording is optional).
11. Foreground service is the accepted alternative - with conditions. If you use a foreground service (FGS) instead, it is separately reviewed: use "must be initiated as a continuation of an in-app, user-initiated action" and "must be terminated immediately after the application completes the intended use case of the user-initiated action." Crucially, "if an app's use of device location via foreground service is equivalent to ACCESS_BACKGROUND_LOCATION (or otherwise 'location in the background'), the app will be subject to location in the background permissions requirements." See the Permissions for Foreground Services policy (https://support.google.com/googleplay/android-developer/answer/13392821).
12. Runtime behaviour on Android 11+ and the 2026 Minimum Scope change. On Android 10 the system dialog offers "Allow all the time"; "On Android 11 (API level 30) and higher, however, the system dialog doesn't include the Allow all the time option. Instead, users must enable background location on a settings page." Build an educational UI using shouldShowRequestPermissionRationale() and getBackgroundPermissionOptionLabel(), always offer a decline path, and keep the app usable without the permission. If the user grants only approximate foreground location, "your app has only approximate location access in the background as well." (https://developer.android.com/develop/sensors-and-location/location/permissions/background) Separately, the April 2026 policy updates - "Minimum Scope: Foreground Location Access and the Location Button" (https://support.google.com/googleplay/android-developer/answer/17033915) and the sensitive-permissions preview (https://support.google.com/googleplay/android-developer/answer/16909972, effective January 27, 2027) - make the Android location button the required minimum-scope method for transactional precise location for apps targeting Android 17 (API level 37) and higher, and require a declaration from developers using ACCESS_FINE_LOCATION. If background location is not needed, the fix on a rejection is to remove the permission from the manifest and the related source code across all APKs and all tracks.