Manifest & Permissions

Request Background Location Separately and Explain the Core Feature

Background location is a separate, sensitive capability. Request it only when the app has a genuine feature that needs location while the user is not actively using the foreground interface, and explain that feature before directing the user through the applicable platform flow.

By Updated 2 min read

Prove foreground access is insufficient

Write down the event requiring location, expected frequency, user benefit and stop condition. A feature that only needs location while its map is open should not request background access for convenience.

The background-location guide describes version-dependent request behavior. On newer Android versions, foreground and background access should not be bundled into one undifferentiated permission request.

Build a staged flow

TEXT · REFERENCE EXAMPLE
User enables the location feature
→ request the necessary foreground scope
→ demonstrate the feature
→ explain the separate background requirement if essential
→ follow the platform's background access flow
→ recheck access and preserve a foreground-only fallback

Use the location guidance to handle precise and approximate access. A background grant does not necessarily mean the app receives precise location.

Keep the user in control

Show whether background collection is enabled and provide a way to stop the feature. Do not restart tracking solely because the app was reopened if the user previously disabled it.

Handle denial without repeated prompts. An explanation should describe the actual ongoing use, not a vague warning that the whole app will stop working.

Check policy and data handling

Google Play's sensitive-permission policy can impose additional eligibility and disclosure requirements. Document the core feature, in-app disclosure, collection behavior and retention. A manifest declaration cannot establish compliance.

Review SDKs too: a dependency's location collection belongs in the app's data-flow assessment.

Test interruptions and revocation

Test foreground-only access, approximate access, background denial, later revocation and device restart. Confirm the feature stops or degrades safely and does not silently switch to another identifier or data source.

APKLint can inspect relevant permissions, but it cannot prove the frequency or purpose of runtime collection. Retain device-level evidence and current policy references with the release.

Sources and further reading

  1. Android Developers: Request background location
  2. Android Developers: Request location permissions
  3. Google Play: Permissions and APIs that access sensitive information

Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.

APKLint

Android inspection tools and practical release guides. About APKLint · Report a correction