A map asking for your location makes sense.
A flashlight asking for it raises a better question.
Permission systems are easiest to understand when the requested access maps directly onto the feature the person is trying to use.
Navigation needs location.
A camera needs camera access.
A voice recorder needs the microphone.
The interesting cases are the ones where the relationship is not obvious.
The scope matters as much as the permission name
“Location access” is not one thing.
Android currently distinguishes foreground from background location and approximate from precise location. Its developer documentation says apps should request only the type of location access critical to the user-facing feature, and that most use cases need location only while the user is actively engaging with the app. Background access is supposed to be reserved for cases where it is central to the function. See Android’s location-permission guide and background-location guidance.
That gives us a practical way to examine a permission request.
Do not ask merely:
Does this app use location?
Ask:
- Does the feature need location at all?
- Does it need precise location?
- Does it need location continuously?
- Does it need location when the app is closed?
- Could a postal code or one-time location request do the job instead?
Those are materially different levels of access.
An unusual request is a clue, not proof of abuse
Suppose a shopping app asks for location.
That might support nearby-store inventory, local pickup, tax calculation, or fraud prevention.
Suppose a social app asks for location.
That might power nearby content or geotagging.
The request may have a legitimate explanation that is not obvious from the app icon.
Android’s own guidance even tells developers to inspect SDK dependencies because embedded libraries can themselves depend on location permissions.
So the presence of a permission is not enough to conclude that a company is secretly selling location histories.
A stronger investigation needs the actual data flow: network traffic, SDK documentation, privacy disclosures, regulator findings, or code showing where the location goes.
Minimization gives the question a measurable form
Android’s privacy documentation tells developers to minimize permission requests and prefer narrower methods where possible. Its newer Android 17 guidance continues that direction by emphasizing one-time and limited location access for common tasks that do not require permanent background tracking. See Android’s permission-minimization guidance.
That does not create a universal legal test.
It does create a useful engineering test:
Is the requested access proportional to the feature?
A weather app asking for approximate location while open is one thing.
The same app demanding precise background location forever is a different architecture.
The Surveillance Economy often hides in that difference between technically useful and actually necessary.