Can I revoke the INTERNET permission on Android?

Not through the standard permission UI. INTERNET is classified as a normal permission and is auto-granted without a user prompt. To block an app's network access you need either Android's built-in per-app data restriction (Settings > Apps > [App] > Mobile data and Wi-Fi) or a local VPN firewall app that routes traffic per application. GrapheneOS adds a proper network permission toggle that sits alongside dangerous permissions and can be revoked like any other.

What does 'Allow only while using the app' actually mean for location?

The permission is active only while the app is visible in the foreground or in a brief grace period immediately after it leaves it. As soon as the app is fully backgrounded, location access is suspended. This is the recommended setting for most apps that legitimately need location, such as restaurant finders or parking apps. 'Allow all the time' should be reserved for a deliberate use case like a GPS tracking app you have consciously configured.

How do I check which apps have been using my microphone in the past 24 hours?

Go to Settings > Privacy > Privacy Dashboard on Android 12 or later. The timeline view shows every app that accessed the microphone, camera, or location, with timestamps. Tap any entry to go directly to that app's permission settings. If automatic permission reset is enabled (Android 11+), apps you have not opened in months will already have had their permissions revoked automatically.

Does Android 13's notification permission actually matter for privacy?

Yes, more than most people expect. Apps with notification access can potentially be read by accessibility services, screen recorders, or overlay apps that monitor the notification shade. OTP codes, message previews, and account alerts all pass through notifications. Treating POST_NOTIFICATIONS like a sensitive permission and denying it to apps that have no clear need for notifications reduces the surface area for that kind of secondary leakage.

Android App Permissions: What They Mean and How to Lock Them Down

Every time you install an app on Android, you are entering a negotiation. The app wants access to your hardware, data, and sensors. The Android permission system is the framework that governs what it can actually reach. Understanding that framework is not optional anymore - it is the first line of defense between your personal data and apps that may misuse it, whether through careless coding or deliberate collection.

This guide covers how Android permissions actually work under the hood, what each major permission category means in practice, and the concrete steps you can take to audit and lock them down today.

How the Android Permission Model Works

Android has used a runtime permission model since Android 6.0 (API level 23), released in 2015. Before that, all permissions were declared at install time and granted in a single batch - you either accepted everything or you did not install the app. The runtime model changed this by requiring apps to ask for sensitive permissions at the moment they need them, in context.

The system divides permissions into three broad protection levels:

Normal permissions are auto-granted by the OS without a user-facing dialog. They cover low-risk operations: accessing the internet (yes, INTERNET is a normal permission), changing network state, setting alarms, or using Bluetooth for basic pairing. You never see a prompt for these.
Dangerous permissions are the ones that matter for privacy. They cover data or hardware that could expose personal information: location, contacts, camera, microphone, call logs, SMS, storage, body sensors, and activity recognition. Apps must request these at runtime, and you must explicitly grant them.
Signature permissions are reserved for apps signed with the same certificate as the component defining the permission - typically system apps or apps from the same developer suite. You cannot grant or revoke these manually.

Since Android 11, there is also a one-time permission option for location, camera, and microphone. Granting access “only this time” means the permission expires as soon as the app moves to the background. Android 12 added approximate location as a separate tier, letting you share a rough area instead of GPS-level precision.

AOSP documentation on the full permission hierarchy is available at developer.android.com/guide/topics/permissions/overview.

The Permission Categories You Should Actually Care About

Not every dangerous permission carries the same weight. Here is a breakdown of the most consequential ones:

Permission	What it exposes	Typical legitimate use	Red flag use
`ACCESS_FINE_LOCATION`	GPS-level position	Navigation, weather	Flashlight, games
`ACCESS_COARSE_LOCATION`	Cell-tower / Wi-Fi position	Local search	Any app with no local feature
`RECORD_AUDIO`	Live microphone	Voice calls, voice search	Shopping, social apps
`CAMERA`	Still images, video	Scanner, video call	Utility apps with no viewfinder
`READ_CONTACTS`	Full contact list, emails, phones	Dialer, messaging	Most single-purpose apps
`READ_CALL_LOG`	Incoming/outgoing call history	Dialer	Anything that is not a dialer
`READ_SMS` / `RECEIVE_SMS`	SMS content	2FA autofill, SMS apps	Apps with no messaging function
`BODY_SENSORS`	Heart rate, step count	Fitness trackers	Games, tools
`ACTIVITY_RECOGNITION`	Step detection, physical activity	Fitness, health	Most apps
`READ_MEDIA_IMAGES`	Photo library (Android 13+)	Gallery, photo editor	Most utility apps

The INTERNET permission is not in this table because it is silent and auto-granted. Yet it is the pipe through which collected data leaves your device. You cannot revoke it in standard Android - but you can block an app’s network access using Android’s built-in per-app data restrictions or a local VPN firewall (see Android Privacy Hardening Checklist for tooling options).

Using the Privacy Dashboard

Android 12 introduced the Privacy Dashboard, and it is underused by most people. Go to Settings > Privacy > Privacy Dashboard. You will see a timeline of the past 24 hours showing every app that accessed location, camera, or microphone, color-coded by permission type.

Tap any entry to drill into the specific app’s permission page directly. If you see an app that has no obvious reason to access a sensor - a PDF reader that pinged your microphone at 2 AM, for instance - that is a signal to revoke the permission and consider removing the app entirely.

On Android 12 and later, the system also displays an indicator dot in the top-right corner of the screen whenever an app is actively using the camera or microphone. This is not cosmetic. It is an OS-level indicator that cannot be suppressed by an app (apps targeting API 31+ cannot create overlays that cover it). If you see the indicator while using an app that has no business recording, investigate immediately.

How to Audit and Revoke Permissions

Reviewing a single app

Go to Settings > Apps > [App name] > Permissions.
You will see permissions split into “Allowed” and “Not allowed.”
Tap any permission to change it. For location, you get four options: Allow all the time, Allow only while using the app, Ask every time, and Don’t allow. For camera and microphone, you get three.

The “Allow only while using the app” option is usually the right choice for anything that needs live sensor access. “Allow all the time” should be reserved for apps where background access has a clear, trusted purpose - a GPS tracker app you have set up deliberately, for example.

Reviewing by permission type

Rather than going app-by-app, you can audit by permission:

Settings > Privacy > Permission Manager (path varies slightly by Android skin).
Select a permission category, for example “Camera.”
See every app grouped by access level. This view makes it easy to spot outliers.

This is the fastest way to audit your camera and microphone exposure across the whole device in under two minutes.

Automatic permission reset

Android 11 introduced automatic permission reset. If you have not opened an app for a few months, Android will automatically revoke its runtime permissions. You can verify this setting per app under Settings > Apps > [App name] > Permissions > Pause app activity if unused.

This is particularly useful for apps you installed once (a conference app, a rental car app) and kept around without using. Those apps may have permissions that are silently active and costing you data exposure. The auto-reset feature closes that gap without requiring manual cleanup.

Permissions on Custom ROMs and Hardened Android

If you are running GrapheneOS or LineageOS, the permission controls go further. See GrapheneOS vs. LineageOS 2026 Comparison for a full breakdown of each ROM’s security posture, but a few permission-specific points are worth noting here:

GrapheneOS extends the standard model with storage scopes (limiting what an app can see inside shared storage to files it created itself), a contact scopes feature (letting you share a subset of contacts per-app), and a network permission toggle that appears alongside the standard dangerous permissions. It also hardens the permission infrastructure at the OS level, removing the ability for apps to use side channels to infer permissions that were denied.

LineageOS includes a Privacy Guard feature in some builds that allows per-app blocks on dangerous permissions independently of the app’s declared target API, and can return dummy data (fake location, empty contact list) instead of a hard denial - useful for apps that crash on denial rather than degrading gracefully.

For apps installed from F-Droid or sideloaded APKs, the same permission model applies, but you should also review the declared permissions in the manifest before installing. Tools like apktool can decode an APK’s AndroidManifest.xml without installing it. The F-Droid vs. Play Store guide covers why FOSS apps tend to request fewer permissions and what you should look for when comparing them.

Five Practical Rules for Permission Hygiene

1. Apply least privilege by default. When an app asks for a permission for the first time, ask yourself: does this feature require this sensor right now? If the answer is unclear, deny it and see what breaks. You can always grant it later.

2. Prefer “only while using” over “always.” Background location, in particular, is a significant data exposure vector. Very few consumer apps need it. Navigation apps are the main exception - and even then, only during an active route.

3. Audit after every major app update. Updates can introduce new permission requests silently. Android will prompt you if a new dangerous permission is added, but only if the app follows correct practice. Spot-check the permission list after updates for any apps you consider sensitive.

4. Treat notification permission seriously. Since Android 13, apps must request POST_NOTIFICATIONS as a dangerous permission. This is not just about annoyance - notification access can expose previews of messages, OTP codes, and other sensitive content to screen recorders or accessibility services that read the notification shade.

5. Remove apps you no longer use. Auto-reset helps, but an uninstalled app cannot abuse permissions it no longer holds. The smaller your installed app surface, the smaller your permission attack surface. If you need to keep a rarely-used app, make sure auto-reset is enabled for it.

For readers who want to combine permission hardening with network-level controls and VPN routing, the best Android VPN apps for 2026 covers tools that can enforce per-app traffic rules on top of the permission system.

What Permissions Cannot Protect You From

The permission model has real limits. INTERNET is ungated, meaning any app can send data over the network by default. Sensor fusion attacks - inferring your location from accelerometer and barometric sensor data without ever requesting ACCESS_FINE_LOCATION - have been demonstrated across multiple peer-reviewed studies. Apps with ACCESSIBILITY_SERVICE access can effectively observe everything on screen, including content from other apps.

The permission system is a necessary control, not a complete one. It is most effective when combined with a habit of installing only apps you trust, preferring open-source software where the code can be reviewed, and keeping the OS patched. For a full checklist of complementary controls, the Android Privacy Hardening Checklist walks through each layer in sequence.

The baseline takeaway: open your Privacy Dashboard today, run through your Permission Manager for camera, microphone, and location, and revoke anything that cannot justify the access. That single 10-minute audit removes more real-world exposure than most specialized privacy tools can.

FAQ

Can I revoke the INTERNET permission on Android?: Not through the standard permission UI. INTERNET is classified as a normal permission and is auto-granted without a user prompt. To block an app's network access you need either Android's built-in per-app data restriction (Settings > Apps > [App] > Mobile data and Wi-Fi) or a local VPN firewall app that routes traffic per application. GrapheneOS adds a proper network permission toggle that sits alongside dangerous permissions and can be revoked like any other.
What does 'Allow only while using the app' actually mean for location?: The permission is active only while the app is visible in the foreground or in a brief grace period immediately after it leaves it. As soon as the app is fully backgrounded, location access is suspended. This is the recommended setting for most apps that legitimately need location, such as restaurant finders or parking apps. 'Allow all the time' should be reserved for a deliberate use case like a GPS tracking app you have consciously configured.
How do I check which apps have been using my microphone in the past 24 hours?: Go to Settings > Privacy > Privacy Dashboard on Android 12 or later. The timeline view shows every app that accessed the microphone, camera, or location, with timestamps. Tap any entry to go directly to that app's permission settings. If automatic permission reset is enabled (Android 11+), apps you have not opened in months will already have had their permissions revoked automatically.
Does Android 13's notification permission actually matter for privacy?: Yes, more than most people expect. Apps with notification access can potentially be read by accessibility services, screen recorders, or overlay apps that monitor the notification shade. OTP codes, message previews, and account alerts all pass through notifications. Treating POST_NOTIFICATIONS like a sensitive permission and denying it to apps that have no clear need for notifications reduces the surface area for that kind of secondary leakage.