Android app permissions determine what an app can access on your phone, from your location and contacts to your camera, microphone, photos, and notifications. This practical audit checklist explains how to review those permissions, estimate their privacy risk, restrict unnecessary access, and recover when an app stops working after a change.
Overview
App permissions are requests for access to information or hardware on your Android phone. A navigation app may need location, a messaging app may need contacts or photos, and a video-calling app may need the camera and microphone. The important question is not whether a permission sounds sensitive; it is whether the app needs that access for a feature you actually use.
Android groups permissions into categories, but the exact names and menu locations can vary by Android version, phone manufacturer, and app. On many phones, you can begin at Settings > Security and privacy > Privacy > Permission manager, or search Settings for Permission manager. You can also review an individual app through Settings > Apps > [app name] > Permissions.
Use this audit as a repeatable decision process:
- List the permission an app has requested or already received.
- Match the permission to a feature you use.
- Choose the narrowest access option that still supports that feature.
- Check whether the access is temporary, foreground-only, background, or always available.
- Test the app and record the result in an audit worksheet.
Permission control is only one part of Android privacy. Also review unused apps, notification access, default apps, account security, software updates, and the information an app collects according to its privacy disclosures. For update and security-support planning, see our Android update and security support guide.
How to estimate permission risk
There is no universal score that can prove an app is safe or unsafe. A simple risk estimate can, however, help you prioritize reviews. Score each permission from zero to three using the following method:
- 0 — Not granted: The app cannot currently use the permission.
- 1 — Low exposure: Access is limited, such as selected photos, approximate location, or one-time use where available.
- 2 — Moderate exposure: The app can use the permission while you use it, or has access to a broader set of data than the feature strictly requires.
- 3 — High exposure: The app can access sensitive information or hardware in the background, or the permission is unrelated to any feature you use.
Add the scores for the permissions you have granted, then add one point for each permission that appears unrelated to the app's purpose. Treat the result as a review priority, not a security verdict. A high score means you should investigate and reduce access where practical; it does not establish that the app is malicious.
| Permission or access type | Review questions | Safer starting choice |
|---|---|---|
| Location | Does the app need navigation, nearby-device discovery, delivery tracking, or location tagging? Does it need access when closed? | Approximate location, while in use, or one-time access when available |
| Camera | Is scanning, photographing, video calling, or recording a core feature? | Deny until needed, then allow while using the feature |
| Microphone | Does the app support calls, voice recording, dictation, or voice commands? | Deny until needed or allow only while in use |
| Contacts | Do you need address-book matching or contact selection, or can you enter a number manually? | Deny, or provide access only if the feature is useful |
| Photos and videos | Does the app need to upload or edit media? Can you select individual items instead? | Selected photos or videos rather than the entire library |
| Notifications | Do alerts provide useful account, delivery, security, or communication updates? | Allow only if the alerts are valuable; manage categories afterward |
| Nearby devices | Does the app connect to headphones, accessories, or local devices? | Deny if you do not use device discovery or connections |
| Calendar, files, or other data | Is the access required for a feature you actively use? | Deny first and restore only when a needed feature explains the request |
Location, camera, microphone, contacts, and photos deserve extra attention because they can reveal personal routines, relationships, conversations, or media. Notifications can also expose message previews on a lock screen even though notification access is not the same as access to the underlying app data. Review both the permission and the notification content settings.
Inputs and assumptions for an audit worksheet
For each app, create a short record. A notes app or spreadsheet is enough. The goal is to make decisions repeatable after installing a new app, changing phones, or updating Android.
App name and purpose: What does the app do, and which features do you use?
Permission: List each granted, denied, or restricted permission.
Reason needed: Identify the exact feature that depends on it.
Access level: Record one-time, while-in-use, selected-content, background, or full access where those choices are offered.
Risk score: Assign 0–3, then add one point for an unrelated permission.
Decision: Keep, narrow, deny, or investigate.
Test result: Note whether the app still performs the feature you need.
Review date: Set a reminder for a future privacy check.
Start with apps that handle sensitive activities: finance, health, messaging, social networking, shopping, travel, and work. Then review apps that have been installed for a long time but are rarely opened. Android may offer a privacy dashboard that summarizes recent access by categories such as location, camera, and microphone. Use it to spot access you did not expect, then open the relevant app's permission page for a decision.
Do not assume that denying every permission is always the best choice. A map app without location access may be unable to provide turn-by-turn guidance, and a calling app without microphone access cannot transmit your voice. Privacy settings work best when they are tied to actual use rather than treated as a one-time blanket rule.
Worked examples
Example 1: A navigation app
Suppose you use an app for occasional trips. Location is relevant, but background access may not be necessary if you do not need active trip tracking while the app is closed. Start with approximate location or while-in-use access if that supports the required navigation features. If route guidance fails, restore the least expansive option that fixes it and document the change. Review location access again if you enable travel tracking or another background feature.
Example 2: A photo-editing app
A photo editor may need access to images you choose, but it may not need your entire photo library. Use selected-photo access when available. Camera permission can remain denied until you use the editor's camera function. If importing a picture works but saving or sharing fails, check the app's media or file access and grant only what the Android prompt and feature require.
Example 3: A shopping app
Shopping may work without contacts, microphone, or camera. Notifications could be useful for order updates but unnecessary for promotions. Deny unrelated permissions, then manage notification categories so important updates remain visible without accepting every marketing alert. If the app requests location, ask whether you use a location-dependent store or delivery feature; otherwise, leave it restricted.
When an app breaks after a restriction
First, identify the failed feature rather than restoring every permission. Reopen the app and repeat the action that failed. Check the app's permission page and grant the narrowest relevant option. If the problem continues, confirm that the app is updated, restart it, and check its own settings. Some apps require a permission only at the moment a feature is used. If Android has removed or reset access for an unused app, grant it again only when you return to that feature.
If an app still demands broad access for a function that should not require it, consider an alternative app or contact the developer. Do not bypass a device warning merely to make setup faster.
When to recalculate and repeat the audit
Revisit your Android privacy settings after installing an app, enabling a new feature, signing into a work account, changing phones, or completing a major Android update. Menu names and permission categories can change, so do not rely on an old path if it no longer matches your device. Search Settings for the permission name or Permission manager when necessary.
A practical recurring review can be brief:
- Open the Privacy dashboard and look for recent camera, microphone, and location access you do not recognize.
- Review high-risk apps in Permission manager, starting with those that have background or broad access.
- Remove permissions from apps you no longer use and uninstall apps you no longer trust or need.
- Check notification access and lock-screen previews separately.
- Retest essential apps after each restriction and update your worksheet.
For connected devices, apply the same principle beyond the phone: review the permissions and account access used by smart-home apps, and keep guest access separate where possible. Our smart-home network security checklist covers that wider setup. A permission audit is most useful when repeated as your apps, habits, and Android version change.
