Match precision to the feature
| Feature | Likely design question |
|---|---|
| Regional weather | Can approximate location or a manual city selection work? |
| Nearby store browsing | Is a broader radius acceptable? |
| Turn-by-turn navigation | What precise access and active-use behavior are required? |
| Location-based account security | Can the decision tolerate uncertainty safely? |
The Android location documentation explains precise and approximate access behavior. The grant model depends on platform version and the permissions requested.
Request the appropriate combination
On versions supporting the precise/approximate choice, follow the documented request pattern rather than requesting fine location in isolation and assuming it will always succeed. Check the resulting grants and design the location pipeline for the available accuracy.
The runtime-permission guide provides the request and denial model. A user selecting approximate access has granted a useful limited capability, not necessarily denied the feature entirely.
Handle uncertainty in the result
Use the location's accuracy information and freshness when making decisions. Do not display a precise-looking map pin as certainty when the measurement is broad or stale. For user-facing selections, allow correction or manual input where practical.
Avoid storing more location detail than the feature needs. Precision and retention are separate privacy decisions.
Test changes while the app exists
A user can change precision or revoke access in settings. Test returning to a running app, recreating its screen and resuming a saved task. Recompute the capability rather than trusting a startup-only check.
Background access is a separate question and may inherit the available precision limitations. Do not assume foreground fine access automatically authorizes ongoing background collection.
Review declarations with APKLint
The permission checker can identify location declarations and overly broad requests. It cannot determine whether your feature genuinely needs precision or whether the UI accurately represents uncertainty. Close that gap with feature-specific tests and a documented fallback for approximate access.
Design nearby results around uncertain location
Suppose a store finder receives an approximate location whose uncertainty covers several neighborhoods. Showing only the single closest store can imply a precision the input does not support. Present a broader set of results, explain the approximate area and allow the user to enter a town or choose a point manually. Keep the selected search location distinct from the device's measured location.
The location permission guidance explains the platform's access choices. Request the documented combination when the feature genuinely benefits from precision, then inspect the granted capability. Do not equate a requested fine-location permission with a promise that every returned measurement is precise, recent or suitable for a safety-sensitive decision.
Evaluate age and accuracy before using a fix
A precise measurement from a previous trip can be less useful than a fresh approximate one for a current search. Preserve the measurement's available timing and accuracy context, and apply feature-specific acceptance rules. For example, a regional weather display can often use a manually selected city when a current fix is unavailable; a navigation instruction needs a different reliability assessment.
Test the UI with two deliberately different uncertainty conditions and with a stale result. Confirm that the map and result ordering change appropriately, and that an unavailable location does not silently reuse an old point as though it were current. Avoid turning a failed update into a precise-looking zero coordinate or an unexplained jump to another region.
When the user changes precision in settings, reconstruct the screen from the current access state. Do not retain a previous fine-access Boolean in saved UI state and continue treating it as authoritative. Check a fresh launch as well as returning to an existing task, since the app's process and screen state may change during permission updates.
If the feature also uses background location, review that grant independently. The background guidance states that approximate foreground access also limits background accuracy. Broadening the collection schedule cannot restore precision that the user did not grant. Keep retention and transmission proportional to the actual feature, and avoid storing a detailed trail merely because a location API can supply one.
Sources and further reading
Reference review: 29 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.
Android inspection tools and practical release guides. About APKLint · Report a correction
