Permissions: Background Location policy

Permissions: Background Location Access Not Approved

Medium RiskMedium DifficultyTypical Fix: 2-4 days0 Reports

Also known as:Issue found: Feature does not meet requirements for background location accessProminent disclosure not found for background locationPermissions declaration form needs more informationYour video does not demonstrate the declared featureBackground location access does not appear essential to your app's core functionality

Our Take

Google rejects apps that request ACCESS_BACKGROUND_LOCATION without completing the Background Location permission declaration, submitting a compliant demo video, or showing a prominent in-app disclosure before the Android runtime prompt.

This falls under Google Play's "Permissions and APIs that Access Sensitive Information" policy, which requires that background location "only be used to provide features beneficial to the user and relevant to the core functionality of the app."

It's most common when developers declare a feature that reviewers judge as "nice to have" rather than core, when the declaration form lists more than one feature, or when the disclosure is buried in a privacy policy instead of shown as a standalone in-app prompt.

Resolution Guide

Confirm you actually need ACCESS_BACKGROUND_LOCATION

Check whether foreground-only access (ACCESS_FINE_LOCATION/ACCESS_COARSE_LOCATION while the app is in use) can deliver the same feature. Google's reviewers reject apps whose background use case is "nice to have" rather than core. As of the April 2026 policy update, Google recommends a foreground-only "location button" pattern for anything that doesn't require continuous tracking — see https://support.google.com/googleplay/android-developer/answer/17033915.

Declare exactly one feature

In Play Console, go to Policy > App content > Sensitive app permissions > Location permissions > Start. Google's form only accepts a single declared feature per submission; listing multiple background-location use cases is a common rejection cause.

Add a standalone prominent disclosure

Build an in-app screen or dialog (not your privacy policy or ToS) that appears during normal use, before the Android runtime prompt. It must name "location," state it is collected in the background ("even when the app is closed"), list the specific feature(s) using it, and offer a real choice (e.g. "Agree" / "No thanks") — not mimic an OS dialog. Reference: https://support.google.com/googleplay/android-developer/answer/11150561.

Record a compliant demo video

On a physical Android device (not iOS, not an emulator screenshot), record roughly 30 seconds showing: opening the app, navigating to the feature, the prominent disclosure appearing, then the Android system permission prompt, then the feature working. Upload it as a YouTube (unlisted) or Google Drive link in the declaration form's Video Instructions field.

Fill in reviewer test access

In the same form, provide explicit login credentials and step-by-step instructions for how a reviewer reaches the background-location feature, so they don't have to guess.

Use `backgroundPermissionRationale` on Android 11+

If your target SDK triggers the two-step "Allow all the time" system flow, customize the rationale text shown before the second step so it matches your in-app disclosure wording.

Resubmit the Permissions Declaration Form

Policy > App content > Sensitive app permissions > Location permissions. Submissions are typically reviewed within a few days; do not publish an update with the same unresolved issue while a review is pending.

Verify manifest permissions match actual usage

Remove ACCESS_BACKGROUND_LOCATION from your manifest entirely if a bundled SDK or library declared it but your app doesn't use it — this has caused false-positive rejections when developers didn't realize a dependency added the permission.

Example Rejection Email

From:Google Play Developer Support

Subject:Policy violation - Permissions: Background Location Access

Google Play Console — Policy status Issue found: Feature does not meet requirements for background location access Your app was reviewed and found to violate our Permissions and APIs that Access Sensitive Information policy. Your app requests the ACCESS_BACKGROUND_LOCATION permission, but the feature you selected in your Permissions Declaration Form does not meet our requirements: "Your selected feature should deliver clear value to the user and be important to the core functionality, or main purpose of the app." We also could not verify a prominent disclosure shown in your app prior to the runtime permission request, or the disclosure did not match the behavior shown in your submitted video. Action required: - Confirm your app's primary use case actually requires continuous background location access - Add an in-app disclosure, shown before the system permission dialog, that names the feature and states location is collected in the background - Re-record your demonstration video showing the disclosure, then the Android runtime prompt, then the feature working - Resubmit your Permissions Declaration Form with only one feature declared Learn more: https://support.google.com/googleplay/android-developer/answer/9799150

Consider Appealing

Appeal only if you can show the rejection was a false positive — for example, the permission came from a third-party SDK you don't actually use, or your disclosure and video were already compliant and Google's automated check missed them. Attach the exact video link, screenshots of the in-app disclosure with timestamps, and the declaration form text you submitted. If the real issue is that your background-location use case is genuinely optional or convenience-only, don't appeal — switch to foreground-only access and resubmit, since Google's reviewers consistently uphold rejections on "nice to have" background use cases.

Generate Appeal

Before & After

Before — Rejected

A fitness app requests ACCESS_BACKGROUND_LOCATION to "improve route accuracy," discloses this only inside a linked privacy policy, and the declaration form lists three features (route tracking, geofenced reminders, and social check-ins).

After — Approved

The app is split to request background location solely for live workout route tracking (the single declared feature), adds an in-app dialog shown before the permission prompt ("RunTrack uses your location in the background to record your route, even when the app is closed"), and the geofenced reminders/check-ins fall back to foreground-only access.

What changed: Narrowing to one clearly core feature with a dedicated in-app disclosure satisfies both the single-feature rule on the declaration form and the prominent disclosure requirement, instead of relying on a privacy policy buried behind a settings link.