The privacy timeline

Privacy on Android was not designed once. It was negotiated, release by release, against the specific things apps had started doing. That history explains why the permission model is so uneven: it is an accumulation, not a plan.

TL;DR#

• 2008–2015: permissions are granted at install. One screen, all or nothing.
• 2015 (6.0): runtime permissions. Dangerous permissions are requested in context and can be denied.
• 2019 (10): scoped storage, separate background location, and restrictions on non-resettable identifiers.
• 2020 (11): one-time permissions and permission auto-reset — consent gains a duration.
• 2021 (12): Privacy Dashboard, mic/camera indicators and toggles, approximate location, clipboard toast.
• 2022–2024: granular media permissions and the Photo Picker (13), selected photos (14), Private Space (15).
• The trend: from what the app may access to how much, how often, and for how long.

Mental model#

Think of a building where the front desk used to hand out a master key at check-in.

For years, checking in meant receiving keys to every room you had plausibly claimed a need for. The desk did not check back, and the key worked forever.

Then the building installed per-door locks (runtime permissions): you ask at the door, the door can refuse, and the refusal is total. Then it added time-limited keys (one-time permissions): the key stops working when you leave the floor. Then it added partial keys (approximate location, selected photos): the key opens the room but not the filing cabinet. Then it added a log of every door that opened (Privacy Dashboard, data access auditing).

The resident can now see the logs, and the locks are on more doors than before.

Where the analogy breaks#

A building has one locksmith. Android has a permission system, an app ops layer beneath it, and a set of per-subsystem policies in between — media, location, notifications, background. A single capability can be gated by more than one of them, and they do not always agree. That layering is the subject of App Ops.

The big picture#

The replay panel is the useful part. Pick API 19 and then API 34 and watch the same five requests produce completely different answers.

Deep dive#

Install-time permissions (API 1–22)#

The original model is the simplest possible: an app declares permissions in its manifest, and installing the app grants all of them. The user sees one screen and can accept or refuse the whole package.

Two properties follow:

• The user cannot use the app and withhold one permission. It is all or nothing.
• Apps learn nothing from the grant, because there is no per-permission decision to observe.

The result was predictable. Apps requested everything they might ever need, because the marginal cost of another permission was one more line in a list nobody read.¹

Two things were happening underneath. First, the protection level of a permission (normal, dangerous, signature) determined whether the user saw it at all. Second, App Ops already existed as an internal, per-operation control that the user could not see. The modern privacy model is, in a sense, App Ops becoming visible.²

Runtime permissions (API 23, Android 6.0)#

Android 6.0 split permissions into install-time (normal) and runtime (dangerous). The runtime dialog is owned by the system, so an app cannot fake or restyle it, and the user can deny.

The three-state answer matters more than most people realise:

• Granted — the permission works.
• Denied — the app may ask again.
• Denied with "don't ask again" — subsequent requests are ignored silently, and the app must detect this and send the user to Settings.

Android 8.0 and 9: tightening the data#

The privacy story of these releases is less about dialogs and more about what data an app could reach at all.

• Android 8.0: ANDROID_ID becomes scoped to the app-signing key, breaking its use as a device-wide identifier.
• Android 9: background access to sensors and location is throttled; non-SDK interface restrictions begin to close private APIs that apps used to read.³
• Android 10: IMEI and serial numbers require a privileged permission, ANDROID_ID is further scoped, and MAC address randomisation becomes standard.⁴

The identifier story is its own page, because it is the clearest example of Android removing a capability rather than asking about it.

Android 10 and 11: scoped storage and consent with a duration#

Scoped storage (10, enforced for all apps in 11) removed direct filesystem access to shared storage. An app can reach its own directory, the MediaStore collections it has permission for, and files the user hands it through the Storage Access Framework. Everything else is gone.⁴

Background location became a separate grant in 10, and in 11 it became a separate request the user could refuse independently.

One-time permissions (11) added a duration to consent: camera, microphone and location can be granted for a single session, expiring when the app leaves the foreground. Permission auto-reset (11) revokes permissions from apps that have not been used for a few months.⁵

Android 12: making the invisible visible#

Android 12's contribution was not new restrictions. It was visibility.

• Privacy Dashboard: a screen showing which apps used camera, microphone and location, and when.
• Indicators: a dot in the status bar while the camera or microphone is in use.
• Toggles: system-wide switches that disable the camera or microphone entirely.
• Approximate location: the user can grant coarse location only.
• Clipboard toast: reading the clipboard shows a toast.⁶

The design logic is that many users do not want to configure permissions; they want to notice misuse. Indicators and a dashboard serve that better than another dialog.

The platform side of this is data access auditing: apps can register an AppOpsManager callback and be told when their own accesses are recorded. That is the same data the Dashboard reads.⁷

Android 13 and 14: granular data, partial access#

• Granular media permissions: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO replace the blanket storage read.
• Photo Picker: the user hands over specific items without granting library access at all.
• Notification permission: POST_NOTIFICATIONS becomes a runtime permission.
• Selected photos (14): READ_MEDIA_VISUAL_USER_SELECTED makes partial media access a persistent state rather than a one-off handoff.⁸⁹

Android 15 and beyond: profiles and local networks#

Private Space (15) adds a separately locked profile whose apps and data are hidden from the main user. For app developers the impact is indirect but real: the number of profiles is no longer something to assume, and package visibility across profiles is filtered.¹⁰

Android 17 adds ACCESS_LOCAL_NETWORK as a runtime permission for local network access, and delays SMS OTP delivery for apps that are not the intended recipient. Both follow the same pattern: a capability that used to be ambient becomes a grant.¹¹

The shape of the curve#

Plot the releases by how much they changed for a typical app and the curve is not smooth. It is a long flat period followed by a staircase.

• 2008–2014: almost nothing changes. Install-time permissions are stable for six years.
• 2015–2017: one big change (runtime permissions) followed by consolidation.
• 2018–2021: four years of continuous tightening — identifiers, storage, location, visibility.
• 2022–2026: smaller, more targeted changes, often behind a flag or a Mainline module.

The staircase pattern is what you would expect from a platform that cannot break existing apps: a big change, then a period of adaptation, then the next big change. The Mainline module structure at the end of the period is the mechanism that makes the later steps smaller and faster.

The permission corpus, by API level#

The shape of the permission model is visible in the data. There are 43 dangerous permissions in the current corpus, and their distribution over time tells the story better than a list of features: seventeen arrived with Android 1.0, then a slow trickle, then clusters at API 29 and API 31 when storage, location and Bluetooth were each split into finer pieces.

The clusters are the interesting part. API 31's four new permissions are all Bluetooth and UWB — one capability that used to be covered by BLUETOOTH and ACCESS_FINE_LOCATION, split into three so that a user can grant "scan for nearby devices" without granting "connect to them". API 33's six are the media split and the notification permission. In both cases the platform did not add a new capability; it subdivided an existing one so consent could be narrower.

How it evolved#

Under the hood#

• ‹›PermissionManagerService.java↗grant, revoke and the protection-level checks
• ‹›AppOpsService.java↗the operation-level state beneath permissions
• ‹›AppOpsManager.java↗the client API, including the auditing callbacks
• ‹›↗where the privacy indicators are drawn
• ‹›UserManagerService.java↗profiles, including Private Space

Curiosity corner#

• App Ops shipped in Android 4.3 with a hidden settings UI. It was removed from the visible Settings app and lived on as an internal service until the Privacy Dashboard gave it a public face.
• The mic and camera toggles are not permissions. They are a system-level sensor block; an app with a granted permission still gets silence or a black frame.
• READ_EXTERNAL_STORAGE still exists, but on API 33+ it is effectively ignored for media in favour of the granular permissions.

Try it#

$ 
adb shell dumpsys package com.example.app | grep -A20 "runtime permissions"

android.permission.CAMERA: granted=true
android.permission.POST_NOTIFICATIONS: granted=false

$ 
adb shell appops get com.example.app

CAMERA: allow; time=+1h2m3s ago

$ 
adb shell am start -a android.settings.PRIVACY_SETTINGS

Starting: Intent { act=android.settings.PRIVACY_SETTINGS }

Build it#

Write a screen that requests camera, location and notifications, and log the result of each request including whether shouldShowRequestPermissionRationale is true. Then deny one permanently and observe the difference. The three-state model becomes concrete in about two minutes.

Check yourself#

Sources#