How to audit your app permissions properly

App permissions are one of the most consequential privacy controls on your phone, and one of the most neglected. Most people grant permissions during app installation without reviewing them, never revisit those decisions, and have no clear picture of what data each app on their device can access right now. This guide explains how to audit your permissions systematically, what to look for, and what to do about what you find.

Why this matters more than most people realise

The permissions an app holds are not just data it collects for its own use. A substantial ecosystem of data brokers operates by aggregating data sold or licensed from app developers. Location data collected by weather apps and fitness trackers is sold to data brokers who resell it to insurers, law enforcement agencies, employers, and political campaigns. Contact lists from productivity apps end up in marketing databases. Microphone access from apps that "need it for voice features" has been documented being activated in the background in several high-profile cases.

When you grant an app a permission, you are not just trusting that specific company. You are potentially trusting every advertiser, analytics provider, and data partner integrated into that app — a chain that is rarely disclosed clearly and frequently changes via SDK updates you never see.

How to audit on stock Android

The most efficient audit path on stock Android (Android 12 and later):

• Go to Settings → Privacy → Permission Manager. This shows every permission category and which apps hold it — a far more useful view than going app-by-app.
• Work through each category: Location, Microphone, Camera, Contacts, Storage, Phone, Body Sensors, Calendar, Nearby Devices.
• For each app listed under a permission, ask: does this app need this permission to perform its core function? If not, revoke it.
• Check the Privacy Dashboard (Settings → Privacy → Privacy Dashboard) which shows a 24-hour timeline of which apps accessed which permissions and when. This is the most revealing view — you will frequently find apps accessing location or microphone at times when you weren't actively using them.

How to audit on GrapheneOS

GrapheneOS's permission audit is the same as stock Android plus additional categories unique to the platform:

• The standard Permission Manager is present and works identically.
• Network permission is an additional toggle available per-app. Navigate to Settings → Apps → [App Name] → Permissions → Network. This is a GrapheneOS-exclusive feature not present in any standard Android build.
• Sensors permission controls access to accelerometer, gyroscope, barometer, and other hardware sensors. This is also GrapheneOS-exclusive. Revoke this for any app that doesn't have a legitimate need for motion sensing.
• Storage scopes allow granting an app access to specific files rather than entire directories — significantly reducing exposure compared to granting broad storage access.

Permission categories that matter most

Not all permissions carry equal risk. Focus your audit on these:

• Location (Precise): GPS-level accuracy. Very few apps legitimately need this. Navigation apps, yes. A recipe app or flashlight, no. Prefer "Approximate" where offered, and "Only while using the app" over "Always allow".
• Location (Approximate): network-based location, accurate to roughly 100–500 metres. Still sensitive — can identify your home, workplace, and movement patterns over time. Revoke from any app where it isn't clearly needed.
• Microphone: the most abused permission category. Voice assistants, communication apps, and music recognition tools have legitimate needs. Flashlight apps, games, barcode scanners, and utility apps do not.
• Camera: broadly similar to microphone — grant only to apps whose core function involves capturing images or video.
• Contacts: granting contacts access gives an app your entire social graph, including the names, numbers, and email addresses of people who never consented to share their data with that app. Revoke liberally.
• Storage: broad storage access on older Android versions gave apps access to everything on your storage. On Android 13+ this is scoped to media types. Still, grant only where the app's function clearly requires reading or writing files.

Red flags to look for

Certain permission patterns are strong indicators of data harvesting beyond the app's stated purpose:

• Flashlight app with contacts or location: there is no functional reason a torch application needs your contact list or your GPS coordinates. This is a data broker integration.
• Game requesting microphone: unless the game features voice chat, microphone access in a game is almost always an ad network integration designed to listen for audio fingerprints from nearby television or radio.
• Utility apps requesting precise location always-on: weather apps, file managers, and QR code scanners have no legitimate need for continuous background location.
• Apps with large numbers of permissions relative to their function: a simple calculator that requests contacts, location, and microphone has almost certainly been monetised through data brokerage.

Background app activity

Permissions are only part of the picture. Background activity — what apps do when you're not using them — is equally important. On stock Android, check:

• Battery usage by app (Settings → Battery → Battery Usage): apps with significant battery consumption when you're not using them are running background processes.
• Data usage by app (Settings → Network → Data Usage): background data consumption indicates an app is sending or receiving data outside of your active sessions. Sort by background data to identify the heaviest senders.
• The Privacy Dashboard timeline: cross-reference permission access times with your actual usage. Location accessed at 3am when you weren't using the app is a clear signal.

GrapheneOS-specific: the network permission in practice

GrapheneOS's per-app network permission toggle is one of its most practically significant features. On standard Android, even if you revoke every other permission from an app, it can still make outbound network connections. It can send its device identifier, usage statistics, and any locally accessible data to its servers.

With network permission revoked on GrapheneOS, an app cannot make any network connection at all — it operates entirely offline. For apps like calculators, local note-takers, offline games, password managers with local vaults, or document editors, there is no legitimate reason to allow network access. Revoking it eliminates the data exfiltration risk entirely, regardless of what SDKs are embedded in the app.

What to do with over-privileged apps

After your audit, you'll typically find three categories of apps: apps with appropriate permissions, apps with excess permissions you can revoke without breaking functionality, and apps whose core function requires permissions you'd rather not grant.

For the third category, the options in order of preference:

• Revoke and accept limited functionality: some apps degrade gracefully when permissions are revoked. Worth testing.
• Replace with a FOSS alternative: F-Droid (the open-source Android app repository) carries privacy-respecting alternatives for most common app categories. Open-source apps can be audited for what they actually do with permissions.
• Remove the app entirely: if the function isn't critical and the permission cost is high, the simplest solution is uninstallation.

A thorough permissions audit typically takes 30–60 minutes and significantly reduces your passive data exposure without changing how your phone feels to use. On a Norypt Phone running GrapheneOS, the network and sensor permission toggles extend this audit capability beyond what any stock Android device offers, giving you meaningful control over what every installed app can actually reach.