Request background location only when continuous tracking materially enables your core feature; otherwise prefer foreground-only location to reduce review risk, battery drain, and support burden. Following the checklist below helps you implement a review-ready flow and measure whether background access actually moves your metrics within a few weeks.
| Evidence | Practical interpretation | Business / user impact |
|---|---|---|
| Android split ACCESS_BACKGROUND_LOCATION in API 29 and Play requires a specific declaration plus screenshots | Treat this as a product decision that requires a short in-app rationale, reviewer steps, and minimal telemetry | Expect substantially lower opt-in than foreground prompts; measure the funnel and budget 3-7 business days for typical Play review delays |
iOS Location Permission Review Checklist goes deeper on the ideas above and adds concrete next steps.
When should I request background location permission?
Ask for background location only if continuous tracking outside the foreground is essential to your app's core experience. Examples: live logistics/drivers, safety geofencing that must fire when the app is closed, or real-time duty-of-care tracking.
What this means in practice: prefer foreground-only permissions if periodic or on-demand updates suffice - this reduces Play review risk, battery impact, and support volume. One thing worth noting - background access adds compliance and operational overhead, so factor that into roadmap and SLO discussions.
When you move from outline to execution, What Founders Can Learn from Google Maps Permissions helps close common gaps teams hit here.
How do I implement background location on Android?
A clear process diagram illustrating the recommended runtime sequence: foreground permission prompt → in-app rationale screen explaining value → request background permission → if denied, open Settings intent → enable persistent foreground service if continuous tracking required.
Implement background location as three focused tasks: manifest and API prep, a staged runtime UX, and Play Console submission assets.
Manifest and API-level preparations
Add required permissions
Include both foreground and background permissions in AndroidManifest.xml: ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, and ACCESS_BACKGROUND_LOCATION.
Target API and test matrix
Ensure targetSdkVersion >= 29 and test on Android 10, Android 11+, and a couple of popular OEM builds. Plan 1-2 days for a small test matrix; wider OEM coverage will increase QA time.
Foreground service for persistent tracking
If you collect continuously, declare android:foregroundServiceType="location", request FOREGROUND_SERVICE, and show a persistent notification that explains active tracking. This adds UX and compliance complexity and may need legal review.
Runtime flow and UX: request sequence, rationale screen, and Settings fallback
Foreground first
Ask for ACCESS_FINE_LOCATION first and wait for acceptance; this establishes value exchange and reduces surprise.
Show an explicit rationale
Display a 1-2 sentence rationale that explains why "Allow all the time" is needed, the user benefit, and how to revoke access later.
Request background permission
Then request ACCESS_BACKGROUND_LOCATION. On some devices the system shows "Allow all the time"; on others users are routed to Settings, so include an Intent to ACTION_APPLICATION_DETAILS_SETTINGS and a short visual guide.
Handle denials and telemetry
Use shouldShowRequestPermissionRationale to detect permanent denial; offer a settings-button flow and log funnel events (foreground prompt shown/accepted, rationale shown, background prompt shown/accepted, settings opened). Expect instrumentation and event validation to take a couple of days.
Google Play declaration and pre-submission checklist
- Provide a short, specific use-case and step-by-step reproduction for reviewers; be explicit about which screens trigger collection.
- Attach screenshots of your in-app rationale and the Settings guide to avoid reviewer confusion.
- Publish a privacy policy URL that mentions background location, retention period, and revocation steps; mirror that text in the rationale UI.
- Consider a reviewer-friendly build or instructions that minimize unrelated telemetry. Expect 3-7 business days typical turnaround and longer for borderline cases.
What are the trade-offs and operational impacts?
A compact checklist block with 8 immediate items: manifest entries, rationale UI, Settings intent, foreground service config, telemetry events to capture, Play Console assets, privacy policy updates, and staged rollout percentages.
Only ask when the user benefit clearly outweighs review friction, battery cost, and support burden. This is a trade-off, not a default.
- User trust - 'Allow all the time' typically has lower acceptance than foreground prompts; plan for materially lower opt-in and size experiments accordingly.
- Play Store risk - vague or non-core use-cases often trigger manual review; add 3-7 business days buffer and be ready for resubmission.
- Technical cost - continuous tracking increases battery variance across devices; add monitoring, SLOs for battery and crashes, and a support runbook for OEM quirks.
The practical takeaway: gate background-dependent features behind a staged rollout and an A/B test that compares retention and feature usage between opt-ins and non-opt-ins. Expect to collect meaningful signal in 2-6 weeks depending on traffic and opt-in rate.
Execution checklist (realistic effort and near-term tasks)
Core implementation typically takes a small team 1-3 days of focused work, plus Play review and QA time you should budget separately.
Manifest and code changes
Add permission entries, foreground service flags, and a persistent notification; estimate 4-12 hours of dev work and basic QA for a minimal implementation.
Rationale UI and settings flow
Build a short rationale screen and a Settings guide; estimate 1-2 days including copy and simple visuals. UX reviews or polished animations add time.
Telemetry and experiments
Add opt-in funnel events and plan an A/B test; expect 1-3 days to instrument and validate events, longer if analytics pipelines need changes.
Play Console assets and review prep
Capture rationale screenshots, write the declaration and privacy text, and reserve 3-7 days for review turnaround; be prepared to respond to reviewer questions within a day or two.
One thing worth noting: reviewers sometimes ask for tighter retention commitments or additional screenshots. If that happens, be ready to narrow retention windows or provide a reviewer build that disables continuous collection to reduce friction.
