# Permissions: Background Location Access Not Approved

**Guideline:** permissions/background-location · **Store:** Google Play · **Risk:** medium · **Difficulty:** medium · **Typical turnaround:** 2-4 days

Canonical URL: https://appstorereject.com/rejections/google/permissions%2Fbackground-location/permissions-background-location-access-not-approved

## Description

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.

## Common variations

- Issue found: Feature does not meet requirements for background location access
- Prominent disclosure not found for background location
- Permissions declaration form needs more information
- Your video does not demonstrate the declared feature
- Background location access does not appear essential to your app's core functionality

## Example rejection email

```
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
```

## Resolution steps

## How to Fix Background Location Permission Rejections

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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.
8. **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.

## Appeal guidance

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.

## Before / after examples

**Before:** 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:** 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.
**Why it works:** 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.

## Common questions

**Can you appeal a permissions/background-location rejection?**

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.

**How long does this typically take to fix?**

Typical turnaround is 2-4 days (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=permissions-background-location-access-not-approved*