Introduction
For the first seven years of Android’s existence, installing an app meant accepting every permission it demanded — contacts, location, camera, microphone, SMS — in a single, all-or-nothing dialog that nobody read. A 2014 Carnegie Mellon study found that only 4% of Android users actually looked at the permission screen. The remaining 96% tapped “Accept” and granted apps access to their entire digital lives.
Android 6.0 Marshmallow (2015) changed that. Runtime permissions didn’t just tweak the permission model — they rewrote the social contract between apps and users. For the first time, you could install Facebook without granting it access to your SMS. You could use a flashlight app without giving it your location. You could say “no” to individual permissions and the app still had to work.
This is the story of how Android went from permission chaos to privacy control — and why it mattered.
The Old Model: Install-Time Permissions (2008–2015)
Android 1.0’s permission model was simple: apps declared every permission they might ever need in their AndroidManifest.xml, and users saw the full list before installing. Accept everything, or don’t install the app. There was no middle ground.
The model had one advantage — transparency. Users could, in theory, see what an app was requesting. But in practice:
- Permission lists were overwhelming: A typical app requested 10–15 permissions. Users didn’t read them.
- No context: Users didn’t know why an app needed a permission. “Why does the calculator need my contacts?” was never answered.
- No granularity: You couldn’t deny camera access while granting location. It was all or nothing.
- No revocation: Once granted, permissions were permanent. The only way to revoke was to uninstall the app.
The result was security theatre. Android’s permission model looked like it protected users. It didn’t.
The New Model: Runtime Permissions (2015–Present)
Marshmallow’s runtime permission model changed everything:
- Just-in-time requests: Apps request permissions individually, at the moment they’re needed. A camera app asks for camera permission when you take your first photo, not at install.
- User choice: Users can grant or deny each permission individually. Denying camera doesn’t deny location.
- Context: The system dialog explains why the permission is needed. The app can provide additional rationale.
- Revocable: Permissions can be revoked at any time in Settings → Apps → Permissions. No reinstall required.
- Graceful degradation: Apps must handle denial gracefully. The camera feature is unavailable, but the app doesn’t crash.
The implementation was backward-compatible. Apps targeting API 22 or lower (pre-Marshmallow) still used the old install-time model. Only apps targeting API 23+ triggered runtime dialogs. This gave developers time to adapt.
Dangerous vs. Normal Permissions
Marshmallow classified permissions into two categories:
Dangerous permissions (require runtime prompt):
- Calendar, Camera, Contacts, Location, Microphone, Phone, Sensors, SMS, Storage
Normal permissions (auto-granted):
- Internet, vibration, wake lock, NFC, Bluetooth — things that don’t directly expose user data
The dangerous permission list has expanded over time. Android 10 added background location as a separate, more restrictive permission. Android 11 added one-time permissions. Android 13 added notification permission as opt-in.
The Evolution
Runtime permissions didn’t stop with Marshmallow. Each Android release has added more granularity:
- Android 10 (2019): Background location requires separate permission. Apps can’t silently track location when not in use.
- Android 11 (2020): One-time permissions — grant camera, mic, or location for a single session. Auto-reset revokes permissions for unused apps after months.
- Android 12 (2021): Approximate location option. Privacy Dashboard shows permission access timeline. Camera and mic indicators + global kill switches.
- Android 13 (2022): Notification permission becomes opt-in. Photo Picker replaces full media library access with per-item selection.
- Android 14 (2023): Partial screen sharing — share one app, not the entire screen.
The trend is clear: permissions are becoming more granular, more transparent, and more temporary. The “grant once, forever” model is dead.
The Impact
Runtime permissions reshaped Android’s privacy model. The data:
- 65% of users chose “Only this time” for location and camera when offered (Google, 2021).
- Notification spam dropped significantly after Android 13 made notification permission opt-in.
- Background location access fell by 50%+ after Android 10’s separate background location permission.
The change wasn’t just technical — it was cultural. Apps could no longer assume they’d get every permission. Users could no longer claim they didn’t know what they were agreeing to. The power shifted, slowly and incompletely, from developers to users.
The Limitations
Runtime permissions aren’t perfect:
- Permission fatigue: Users still tap “Allow” more often than “Deny.” The dialogs are frequent and users are conditioned to dismiss them.
- Dark patterns: Apps delay permission requests until the user is invested, making denial more painful. “Allow camera to take your profile photo” after you’ve already filled out the form.
- Permission grouping: Some permission groups are too broad. “Storage” covers both media files and document access.
- Pre-installed apps: System apps often bypass runtime permission dialogs entirely.
Android’s permission model is better than it was in 2015. It’s not as good as it should be. The evolution continues.
References
- “Android Permissions: User Attention, Comprehension, and Behavior” (Carnegie Mellon, 2014)
- Android 6.0 Marshmallow runtime permissions documentation
- Android Developers Blog: runtime permissions, one-time permissions, notification permission
- Google Play distribution data and permission opt-in statistics