Android App Permissions Explained: What to Allow and What to Deny
A flashlight app asks for your contact list. A wallpaper app wants your precise location. A PDF reader would like the microphone, please. If you have used Android for more than a week, you have seen a permission prompt that made no sense, tapped Allow anyway, and moved on. Most people do, because the prompt arrives at the exact moment you want to use the app, which is the worst possible moment to say no.
The quiet good news is that Android's permission system has grown genuinely strict over the past decade, and you can be aggressive about denying requests without breaking much. Here is how the system actually works, which permissions deserve scrutiny, and which requests you can refuse without a second thought.
Install-time versus runtime: why prompts exist at all
Before Android 6.0 arrived in 2015, apps presented every permission as a take-it-or-leave-it bundle at install. Since then, sensitive permissions have been requested at runtime, one at a time, when the app first needs them. Google's developer documentation on permissions divides them into two tiers. Install-time permissions cover low-risk plumbing such as internet access and vibration, and they are granted silently. Runtime permissions guard what Android formally labels dangerous permissions: data and sensors that can genuinely hurt you if misused.
That framing matters. Every prompt you see is, by definition, about something sensitive. There are no trivial runtime prompts.
The six permission groups that matter
Runtime permissions are organised into groups, and six of them do almost all the work:
- Location is the most requested and the most abused. Fine location can pin you to within a few metres.
- Camera and microphone are self-explanatory, and since Android 12 a green status-bar indicator lights up whenever either is in use.
- Contacts hands over other people's data, not just yours. Grant WhatsApp contacts access and you upload your address book to Meta's servers to power friend discovery; we weigh that trade-off in our WhatsApp review.
- Photos and videos got stricter in Android 13, which replaced blanket storage access with media-specific permissions, and Android 14 added a select-photos option so you can share individual images instead of the whole gallery.
- Phone covers call state and call logs. Very few apps outside dialers and carrier tools have any business here.
Only while using the app, and one-time grants
Android 10 introduced the option to allow location only while an app is in the foreground, and Android 11 extended the idea with one-time permissions for location, camera and microphone. These should be your defaults. A navigation app plainly needs location while you drive; almost nothing needs it in the background. Google Maps works fine on the while-in-use setting, as we note in our Google Maps review, and any app that nags you to upgrade to Allow all the time should explain precisely why. If the explanation is vague, the answer is no.
The Privacy Dashboard and permission auto-reset
Since Android 12, the Privacy Dashboard in Settings shows a 24-hour timeline of which apps touched location, camera and microphone. It is the single best tool for catching an app that behaves politely in front of you and differently when you are not looking. Android also revokes permissions on its own: auto-reset, introduced with Android 11 and later brought to older devices through Google Play services, strips permissions from apps you have not opened in a few months. If some old game suddenly asks for location again, that is the system working as intended.
What to allow and what to deny
Google's own Play Store permissions help page explains what each permission controls, but it stops short of giving advice. Ours is simple:
- Location: while-in-use for maps, weather and ride-hailing. Deny it to games, shopping apps and social networks; they mostly want it for advertising.
- Camera and microphone: one-time grants, unless it is a camera or calling app you use daily.
- Contacts: deny by default. Messaging apps are the one defensible case, and even then you should understand what gets uploaded.
- Photos: use the photo picker or select-photos option. Full gallery access is rarely justified anymore.
- Phone: deny unless the app actually places calls.
Denying is cheap. If an app genuinely needs a permission, it will ask again in context, and you can reverse any decision in thirty seconds under Settings and Apps.
Special access: the permissions behind the second door
Some capabilities are so powerful they live outside the normal prompt system, buried under Special app access in Settings. Notification access lets an app read every notification you receive, including two-factor codes. Display over other apps enables overlay attacks that draw a fake login screen on top of a real one. And accessibility services, designed for screen readers, can read anything on screen and tap anything on your behalf. That combination is why accessibility abuse is the dominant technique in Android banking malware: a trojan with accessibility access can watch you log in, harvest the credentials and approve transfers by itself. No legitimate flashlight, phone cleaner or document scanner needs accessibility. Treat any such request as a red flag bright enough to uninstall over.
A five-minute audit worth doing
Open the permission manager and read the location, microphone and contacts lists top to bottom. Downgrade anything set to Allow all the time that does not visibly need it, glance through the special access screens, and let the Privacy Dashboard tell you the rest. You will not break your phone. The prompts were designed for exactly this kind of second-guessing.