What Android Got Right

The improvements to Android privacy since Android 10 are substantial and worth acknowledging:

Scoped storage

Apps can no longer read arbitrary files from your storage. Every app is confined to its own sandbox by default, with explicit user permission required to access shared media. This closes an enormous category of data-harvesting vulnerabilities that were the norm as recently as Android 9.

Granular location permissions

Apps must now choose between precise and approximate location, and must request background location separately from foreground location. Users can grant "while using the app" access that automatically expires. This dramatically limits what apps can harvest passively.

Permission auto-reset

Apps you have not used in a while have their permissions automatically revoked. This addresses the long-tail problem of apps granted permissions during installation that continue using them years later.

Privacy dashboard

Android now provides a timeline view of which apps accessed sensitive permissions — camera, microphone, location — and when. This makes passive surveillance by installed apps significantly more auditable.

What Android Did Not Address

All of the above improvements share a common assumption: the privacy threat comes from an app running on your device, not from a person holding your device.

Scoped storage does not help when someone can see your screen. Granular location permissions do not matter when someone opens your messaging app. The privacy dashboard audits background access, not foreground visibility.

The threat model that Android's privacy improvements target is: software that extracts your data without your knowledge. The threat model they do not address is: someone physically looking at your phone, with or without your cooperation.

App access is not granular for physical presence

Once your phone is unlocked, every app in your launcher is accessible to whoever is holding it. Android has no native mechanism to hide specific apps from view or require a secondary authentication to open them. App locking is left entirely to third-party apps, with all the limitations that implies.

Notification content is visible without unlocking

By default, notification content appears on the lock screen. Even with lock screen notifications disabled, notifications are accessible the moment the phone is unlocked — which is exactly when physical access risk is highest. Android provides notification sensitivity controls, but they apply at a channel level and are difficult to manage in practice.

Recents reveals what you were doing

The recent apps screen is a timeline of your last activities. Any app you were using when the phone was handed over is visible there. Android provides no native way to automatically clear recents when a specific condition is met.

There is no coercion-resistance model

Android's security model assumes the authenticated user is cooperative. There is no platform-level concept of a "duress" state — a mode where the authenticated session appears normal but protection remains active. This is a fundamental gap for anyone in a situation where cooperation is demanded.

Why This Gap Is Growing

Two trends are making the physical-presence threat model more important, not less.

Device checks are becoming more common. In various contexts — border crossings, domestic situations, employment screening — individuals are increasingly asked to hand over their phones. The assumption that your device is entirely private from anyone who physically holds it is no longer reliable.

Everything is on the phone now. The consolidation of communications, finances, social life, and work onto a single device means the stakes of physical access are dramatically higher than they were five years ago. The phone is not just a phone — it is the key to almost every dimension of a person's life.

What the App Layer Can and Cannot Do

Third-party privacy apps address real gaps that the platform does not. They can hide apps from the launcher, suppress notifications, control what appears in recents, and provide coercion-resistant modes. These are meaningful capabilities.

They are also constrained by what the platform permits. An app cannot simply make itself invisible — it needs platform-level permissions to do so, granted through a specific setup process. An app cannot replace Android's built-in recovery mechanisms — it must use the ones the platform provides.

The best outcomes come from privacy apps that work with the platform's legitimate permission tiers rather than trying to work around them. Using the same mechanisms that enterprise IT departments use to manage device fleets — legitimate, documented, supported — produces protection that is architecturally sound rather than a cat-and-mouse game with Android's security model.

The Honest Assessment of Where We Are

Android in 2026 is significantly more private from software threats than Android in 2019. It is not meaningfully more private from physical presence threats. The platform's roadmap does not suggest this will change — these are use cases that exist in tension with Android's usability goals and enterprise-device requirements.

The gap will continue to be filled by third-party apps. The quality of that protection depends almost entirely on the architecture of the specific app: whether it uses legitimate platform mechanisms or workarounds, whether it leaves a footprint or runs without evidence, and whether its protection holds under scenarios that go beyond casual privacy.