Android permissions: what minimization means for your app
Permissions are Android’s consent layer: the user grants or refuses access to their location, contacts or microphone. But they settle only one question, access, and not the one the GDPR asks, use. The CNIL’s reading grid fits in one word, minimization: one permission per real feature. Here is how the model works, what the platform already enforces, and what can only be verified by watching the app run.
Three families of permissions
The Android documentation distinguishes three families. Install-time permissions, known as normal, cover access that reaches beyond the app’s sandbox but presents little risk to privacy. Runtime permissions, known as dangerous, protect sensitive data and actions, location, contacts, microphone, camera: the app must request them during use, through a system dialog, and the user can say no. Special permissions, finally, cover particular operations and are managed in the settings.
For a DPO, what matters sits in the second family: dangerous permissions are the ones that open access to personal data, and the ones an inspector looks at first.
What the platform already enforces
Android itself pushes towards minimization. Since Android 11, the permission dialog for location, microphone and camera offers a one-time grant: access holds for the session, not forever. And for apps targeting Android 11 or higher, the system automatically resets the sensitive permissions of an app left unused for a few months.
In other words, a permission is no longer an asset acquired once: it has to be earned again. An app that relies on access granted once and for all is building on sand.
A permission is not consent
Granting a permission is a technical gesture: it opens access. GDPR consent bears on a purpose, and the CNIL’s recommendation says it expressly: the authorization granted by the system is not consent. The location permission lets the app read the position; it does not let it send it to ad networks.
The same reasoning holds for the advertising identifier: technical access is one thing, tracking is another, and the second is what requires consent.
Minimizing: one permission per visible feature
The CNIL’s expectation is concrete: every permission requested must map to a real feature, visible to the user. A permission with no apparent use is a signal to an inspector, and an app that asks for everything at first launch, before any gesture, says something about its design.
Good practice meets the rule: request the permission at the moment of the gesture that needs it, not at startup, and do without it when an alternative exists.
The real test: observed use
An app’s manifest lists the permissions declared; it says neither which ones are requested from the user, nor when, nor which ones actually serve. Those three facts can only be observed at runtime, on a real phone, following a real journey: the moment of each request within the journey, and the actual use that justifies it, or does not.
It is one of the six readings of a mobile app GDPR compliance audit, and one of the checks an inspection runs: proportionality is judged on use, not on declaration. Preparing means measuring it before you are asked.
Sources
Every finding in this article traces back to one of these documents.
- AndroidPermissions on AndroidAndroid Developers documentation, Google
- AndroidRequest runtime permissionsAndroid Developers documentation, Google
- CNIL ’25Recommendation on mobile applications, amended versionCNIL, deliberation no. 2025-024 of 27 March 2025
Common questions
- What is the difference between a normal and a dangerous permission?
- A normal permission is granted at install time and covers access with little risk to privacy. A dangerous permission protects sensitive data or actions, location, contacts, microphone, camera: it is requested during use, through a system dialog, and the user can refuse or withdraw it.
- Does a granted permission count as GDPR consent?
- No. The permission opens technical access; GDPR consent bears on a purpose, and must remain freely given, specific, informed and unambiguous. The CNIL’s recommendation says it expressly: the authorization granted by the system is not consent.
- What happens to the permissions of an unused app?
- For apps targeting Android 11 or higher, the system automatically resets sensitive permissions after a few months without use. The app has to ask again, and the user can refuse.
- How do you verify that a permission is actually used?
- By observing the app while it runs: the moment each permission is requested within the journey, and the use made of it afterwards. A permission requested but never used questions minimization, and it is a finding an analysis report documents, with evidence.