Background location is the single most scrutinised permission on both iOS and Android. Apple manually reviews every app that requests 'Always' location access, and Google Play requires a separate background location declaration form plus a valid use-case explanation. Under GDPR Art.5(1)(c), collecting precise background location when coarse foreground location would suffice violates the data-minimisation principle (CWE-359). CCPA §1798.100 treats geolocation as sensitive personal information requiring explicit disclosure. Apps that silently collect location in background services or push notification handlers — without user-visible features justifying it — face rejection, removal, and regulatory exposure.
Medium because background location without justification triggers manual review on both platforms and violates GDPR data-minimisation, but exploitation requires a device already running the app.
If background location is not genuinely needed, downgrade from 'Always' to 'When in Use' in Info.plist and remove ACCESS_BACKGROUND_LOCATION from AndroidManifest.xml. If background location is required, write a specific usage description that names the feature:
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Your location is used in the background to send alerts when you arrive at or leave saved places.</string>
For Android, submit the background location declaration form in Play Console (App content → Sensitive app permissions). Remove the permission from the manifest if the feature does not exist — its presence alone triggers scrutiny.
ID: app-store-privacy-data.privacy-declarations.location-usage-justification
Severity: medium
What to look for: Count all relevant instances and enumerate each. Check for background location permission requests: ACCESS_BACKGROUND_LOCATION in AndroidManifest.xml; NSLocationAlwaysAndWhenInUseUsageDescription in Info.plist or app.json; requestAlwaysAuthorization() in Swift; requestBackgroundPermissionsAsync() in Expo. If background location is requested, verify: (a) the usage description string specifically explains the background use case (not just "We need your location"); (b) there is a clear, demonstrable feature in the app that requires background location (delivery tracking, geofencing, workout tracking — not just "to improve recommendations"); (c) on Android, background location requires a separate permission dialog and Google Play requires a declaration form for apps using it. For foreground location, check that the app uses the most permissive-but-minimal permission level: uses ACCESS_COARSE_LOCATION where precise location is not needed, uses "When in Use" not "Always" for iOS where background is not needed. Also look for silent location collection patterns: location access in background services or push notification handlers that don't surface to the user.
Pass criteria: Location permission level matches actual use case. At least 1 implementation must be verified. Background location is only requested when the app has a clear, demonstrable need. Usage description strings are specific and mention the feature requiring location.
Fail criteria: Background location requested without a clear feature need; usage description is generic ("We need your location for a better experience"); coarse location replaced with precise location unnecessarily; location accessed in background without declaration.
Skip (N/A) when: App uses no location features (no location APIs detected in source or manifest).
Detail on fail: "NSLocationAlwaysAndWhenInUseUsageDescription is set but no background location feature is visible in the app — this will trigger manual review" or "ACCESS_BACKGROUND_LOCATION declared in AndroidManifest.xml but no geofencing or delivery-tracking feature found — Google will likely reject this without a valid explanation"
Remediation: Background location is one of the most scrutinized permissions on both platforms. Apple rejects apps that request "Always" location without a clear user-facing reason.
ACCESS_BACKGROUND_LOCATION from the manifest if background location is not used — it triggers automatic scrutinyReview the configuration in src/ or app/ directory for implementation patterns.
Cross-reference: For related patterns and deeper analysis, see the corresponding checks in other AuditBuffet audits covering this domain.