Google Play background location rejection: fix the disclosure, declaration and video

What the background location policy requires

On Android 10 (API level 29) and higher, an app that reads location while it isn't visible, and isn't running a foreground service, needs ACCESS_BACKGROUND_LOCATION. Google's Location Permissions policy says background location "may only be used to provide features beneficial to the user and relevant to the core functionality of the app".

In practice, Google checks three things:

• Core feature: the feature is part of the app's main purpose (Google: without it, the app is "broken" or rendered unusable) and clearly benefits the user.
• Minimum scope: coarse instead of fine, and foreground instead of background, whenever that still works. Location for "the sole purpose of advertising or analytics" is never allowed.
• Verifiable evidence: four items:
  • the declaration form under Play Console → App content → Sensitive app permissions → Location permissions
  • a short video
  • a prominent in-app disclosure before the runtime prompt
  • a valid privacy policy, entered in Play Console and linked inside the app, that covers location

Review covers every app bundle and APK on every active track, testing tracks included. Google warns that without approval, app updates may be blocked and the app may be removed from Google Play.

Google has also announced an update to the Location Permissions policy, effective January 27, 2027. For apps targeting Android 17 (API level 37) or higher that need precise location only for one-time, user-initiated actions, the Android location button (the onlyForLocationButton manifest flag) becomes the expected minimum scope. The change is about precise location, not background access, but re-check the Policy Center before you submit.

Common reasons apps get rejected

1. The feature isn't core, or works in the foreground

Google lists features that usually fail because foreground location is enough:

• suggesting nearby friends or players only while the user is in the app
• personalizing in-app content such as local news or playlists, with no alert or feature when the app is closed
• restricting content to enforce region-based digital rights management
• delivery or ride tracking for the customer, not the driver
• turn-by-turn navigation, unless something runs while the user is outside the app (passive route tracking, drive detection)
• aggregating location to show traffic patterns or nearby internet speeds

Advertising, analytics or attribution alone never qualifies.

2. Prominent disclosure missing, late or incomplete

You'll see "Prominent disclosure not found", "Prominent disclosure needed before location runtime permission" or "Missing information in disclosure". The cause is usually one of these:

• the dialog appears after the system prompt
• the disclosure exists only in onboarding text or the privacy policy
• the text lacks the required wording: the term "location", a background phrase ("background", "when the app is closed", "always in use" or "when the app is not in use") and a list of all features that use background location

3. "Unable to verify background feature in the app"

The reviewer couldn't see the feature work. The video may skip the disclosure or runtime prompt, never send the app to the background, use a link the reviewer can't open or show the iOS app. Related findings are "Issues with submitted video", "In-app feature doesn't match the declaration" and, for login-gated features, "Missing or invalid testing credentials".

4. More than one feature declared, or a vague description

Google's help page says you may declare only one location-based feature that needs background access. "Tracking, geofence alerts and nearby offers" triggers "Multiple features declared", and "we use location to improve the experience" triggers "Unclear feature description".

5. A library added the permission

A geofencing, beacon, marketing or BLE SDK, or a Flutter, React Native or Cordova plugin, can merge ACCESS_BACKGROUND_LOCATION into your final manifest. Play sees it in the bundle and expects a declaration.

6. An old bundle still sits on a testing track

Production is clean, but an old closed testing release still declares the permission, so that version code keeps the issue open.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a background location rejection step by step

1. Read the finding. In Play Console, open Policy status. Note the issue title and every affected version code and track.
2. Decide: keep or remove. Would your app be broken without the feature? Could a foreground service or foreground-only location deliver the same result? If foreground works, remove the permission. That is usually the quickest way to clear the finding.
3. To remove it: find the source in Android Studio's Merged Manifest tab, or run bundletool dump manifest --bundle=app/build/outputs/bundle/release/app-release.aab | grep BACKGROUND_LOCATION. Block it in app/src/main/AndroidManifest.xml with <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove" /> and declare xmlns:tools on the root element.
4. To keep it, request incrementally. Ask for ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION first, and ask for background access only when the user opens the background feature. If you target Android 11 (API 30) or higher and request both at once, the system ignores the request and grants neither.
5. Show the disclosure, then the prompt. On Android 11+, "Allow all the time" is only on the settings page. Put the label from PackageManager.getBackgroundPermissionOptionLabel() in your disclosure so users know what to tap. Offer a way to decline, and keep the rest of the app working if they do.
6. Record a new video from a release build (shot list below).
7. Rewrite the declaration under App content → Sensitive app permissions → Location permissions. Describe one feature, explain why foreground location can't deliver it, and add the video link and test credentials.
8. Align your disclosures. The privacy policy and the location answers in the Data safety form must match the declared feature.
9. Ship a new version code to every track serving a non-compliant build, including testing tracks, so no active release still carries the old permission setup. Then send the changes for review from Publishing overview.

Prominent disclosure and video: what reviewers need to see

Disclosure wording

Google recommends this format. You can add detail, but keep these elements:

[App name] collects location data to enable [feature], [feature] and [feature] even when the app is closed or not in use.

If location also feeds ads, add "and it is also used to support advertising". A filled-in example: "RouteLog collects location data to enable automatic trip recording and mileage reports even when the app is closed or not in use."

Show the dialog during normal use, on its own (not bundled with unrelated notices), immediately before the runtime prompt. Google's background location page says it doesn't need an explicit "accept" or "I understand", because the runtime prompt collects consent. Google's general prominent-disclosure guidance and the Android docs still call for a way to decline, so a "Continue" / "No thanks" pair is the safe design. Google's background location page also asks for the disclosure in your store description and on your website. That is in addition to the in-app dialog, never instead of it.

Video shot list (aim for 30 seconds or less)

Record on an Android device with the build you submit. Android 11 or higher shows the settings-page step most users see. Google prefers a YouTube link and also accepts Google Drive links to an MP4 or another common video format. Make sure the link opens without signing in. If the feature has no visible UI, say so in the declaration and show its effect, for example a notification.

Alternatives that avoid background location

Google calls foreground location access its "preferred approach for apps on Google Play", and it often delivers the same value:

Foreground service with location type

Set android:foregroundServiceType="location" on the service and declare FOREGROUND_SERVICE plus FOREGROUND_SERVICE_LOCATION (the type-specific permission applies to apps targeting Android 14, API 34, or higher). Start the service with FOREGROUND_SERVICE_TYPE_LOCATION while your app is visible: without ACCESS_BACKGROUND_LOCATION, you can't start a location foreground service from the background. The policy allows this with "while in use" access only if the service was started "as a continuation of an in-app user-initiated action" and stops as soon as that task is done. Passive or always-on tracking the user didn't start doesn't meet that bar and needs the background declaration instead. Apps targeting Android 14+ also complete the foreground service declaration in App content, with its own video.

Geofencing

The Geofencing API needs ACCESS_FINE_LOCATION plus ACCESS_BACKGROUND_LOCATION when you target Android 10 (API 29) or higher, so switching to it doesn't avoid the declaration. If geofence alerts are your core feature, declare that feature alone. Google's help page lists geofencing for child safety as an example that may qualify, but each app is still judged on its own. The platform limit is 100 active geofences per app per device user.

Flutter, React Native, Expo and SDK edge cases

• Flutter and React Native: add the tools:node="remove" line to android/app/src/main/AndroidManifest.xml, then inspect the built .aab, not the source manifest.
• Expo: expo-location adds the permission only when isAndroidBackgroundLocationEnabled is true. To strip a permission another package adds, list it in android.blockedPermissions.
• Location SDKs: follow the vendor's Play review docs. You stay responsible for what the SDK does in your app, and the policy says location data may not be "exchanged for monetary compensation".
• Cross-platform video: record the Android build. Google explicitly says not to submit a video of your iOS app.

For other restricted APIs, see our sensitive permissions guide. For the Android 14 changes that come with a target SDK bump, see the target API level guide.

How to respond or appeal

Unlike App Store Connect, Google Play has no message thread with the reviewer. You either fix and resubmit, or appeal. When an update is rejected, the last version you successfully published stays on Google Play. That does not protect a live build that itself violates the policy, which Google can still act on.

• Fix and resubmit (most cases): update the declaration and video, then ship a compliant version code to all affected tracks. For "Unable to verify", Google's own advice is to modify the video and resubmit the declaration form.
• Appeal: appeal only if you think the reviewer misjudged a genuinely core feature. Use the appeal option in the email or on Policy status. Explain the user benefit, why foreground access fails, and link a clearer video.
• Don't resubmit unchanged: the same declaration and video will most likely get the same result. Change what the finding names first.

How to prevent background location rejections

• Gate it in CI/CD: after bundleRelease, run bundletool dump manifest and fail the build if ACCESS_BACKGROUND_LOCATION shows up in an app that isn't approved for it. This catches SDK upgrades that add it silently.
• Version your evidence: keep the declaration text, video and disclosure copy in the repo. Re-record the video and update the declaration when the feature changes, because Google says material changes can affect your approval and trigger additional reviews.
• Lint every locale: check that each translation still has "location", a background phrase and the full feature list. AI-assisted checks can flag translations that drop a required phrase.
• Retire stale testing releases before you submit.

appsubmitter.io combines AI-powered checks with human specialists for CI/CD, store submission and Google Play rejection guidance. Not sure your feature qualifies? Book a free consultation call before you record anything.

Template: how to reply to the Google Play review team

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello Google Play team,

We received "[issue title]" for [app name] ([package name]), version code [number], and have made these changes:

1. Declared feature (one only): [feature] – [what the user gets, e.g. automatic trip recording that runs while the phone is locked].
2. Why foreground access is not enough: [e.g. the user cannot keep the app open while driving].
3. Prominent disclosure, shown before the runtime prompt: "[exact text]".
4. Video: [unlisted link] – disclosure at [0:05], runtime prompt and "Allow all the time" at [0:12], feature working in the background at [0:20].
5. Test access: [credentials or "no login required"].
6. Non-compliant version codes [numbers] on [tracks] were replaced by version code [number].

If an element still can't be verified, please tell us which one.

Kind regards,
[Name], [developer account name]

Checklist before you resubmit

• The release .aab declares ACCESS_BACKGROUND_LOCATION only if you intend to declare it (checked with bundletool dump manifest).
• Foreground location is requested first; background location is requested separately, when the user opens the background feature.
• The disclosure appears before the runtime prompt during normal use, contains "location", a background phrase and all background features, and offers a way to decline.
• The same disclosure text also appears in the store description and on your website.
• The declaration describes exactly one core feature and explains why foreground location is not enough.
• The video (30 seconds or less) shows the disclosure, the runtime prompt and the feature working in the background, recorded on Android.
• The video link opens without signing in, and test credentials are provided if needed.
• Privacy policy and Data safety answers cover location and match the declared feature.
• Every non-compliant version code on all tracks, including testing, has been replaced.
• Any location foreground service is started by the user while the app is visible, stops when the task ends and is declared in App content (target Android 14+).

Frequently asked questions

Official source: Play Console Help – Understanding location in the background permissions. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.