Audit and Trim Android App Permissions

You've installed a handful of apps, granted a few permissions, and now you wonder: which of those apps actually need the access they've been given? Over‑privileged permissions can expose your location, contacts, microphone, or even your SMS messages to apps that don't need them. This tutorial shows you a concrete, repeatable workflow to audit every permission on your device and trim the excess, using only the built‑in Permission Manager and, when you need more detail, the Android Debug Bridge (ADB).

Why a Permission Audit Matters

Since Android 6.0 (Marshmallow) most permissions are runtime – the system asks you each time an app tries to use a sensitive feature. However, a few permissions are still granted at install time, and many users simply click “Allow” without reviewing the request. Over time, the cumulative effect is a device that knows far more about you than you intended.

Auditing permissions helps you:

• Reduce the attack surface for malicious or compromised apps.
• Conserve battery and data (e.g., disabling background location).
• Improve app stability by removing permissions that cause unnecessary background activity.

Before You Start

Two optional prerequisites make the process smoother, but the core UI‑only steps work on any modern Android device.

1. Enable Developer Options and USB debugging if you plan to use ADB.
   • Open Settings → About phone and tap Build number seven times.
   • Return to Settings → System → Developer options and toggle USB debugging on.
2. Install ADB on your computer.

   On Windows, macOS, or Linux you can download the platform‑tools zip, extract it, and add the folder to your system PATH.

If you prefer to stay entirely on the phone, skip the ADB section and continue with the built‑in Permission Manager.

Step 1: Scan Permissions with Android’s Built‑In Permission Manager

All stock Android builds (Pixel, AOSP, and most OEM skins) include a central place to view permissions per app.

1. Open Settings.
2. Navigate to Privacy → Permission manager. On some devices the path is Apps → Permission manager or Settings → Apps → Advanced → Permission manager. The exact wording may vary, but the function is the same.
3. At the top you’ll see a list of permission groups (e.g., Location, Camera, Microphone, Contacts, SMS, Phone, etc.). Tap a group to see which apps have that permission.
4. For each app, the toggle indicates whether the permission is Allowed or Denied. Tap the toggle to change the state.

Use the filter dropdown (usually labelled “Allowed”, “Denied”, or “All”) to focus on the Allowed column – those are the permissions you’ve granted.

Prioritising High‑Risk Permissions

Not all permissions are equal. Focus first on the groups that can reveal personal data or incur costs:

• Location – reveals your whereabouts.
• Microphone & Camera – can record audio/video without you noticing.
• Contacts & SMS – expose personal communications.
• Phone – can place calls or read your device ID.
• Storage – grants access to all files on the device.

For each app listed under these groups, ask yourself: Does this app truly need this access to function? If the answer is “no”, revoke the permission.

Step 2: Deep‑Dive with ADB (Optional but Powerful)

The UI view is convenient, but it hides two useful details:

• The exact android.permission.* name (useful for scripting).
• Permissions that were granted at install time and are not shown in the runtime manager (e.g., READ_PHONE_STATE on older apps).

ADB lets you extract a full permission list, filter it, and even batch‑revoke permissions.

2.1 Connect Your Device

adb devices

If your device appears with the word device next to it, you’re ready. If it shows unauthorized, check the phone for a prompt to trust the computer and accept it.

2.2 List All Installed Packages

adb shell pm list packages -3

The -3 flag limits the output to third‑party apps (excluding system packages). Copy the list into a text editor for later reference.

2.3 Dump Permissions for a Single App

Replace com.example.app with the package name you obtained above.

adb shell dumpsys package com.example.app | grep granted=true

The command prints lines like:

android.permission.ACCESS_FINE_LOCATION granted=true

These are the permissions currently granted to that app.

2.4 Generate a Full Permission Report

Run the following one‑liner to create a CSV‑style file that you can open in a spreadsheet:

adb shell pm list packages -3 | cut -d':' -f2 | while read pkg; do 
  echo -n "$pkg,"; 
  adb shell dumpsys package $pkg | grep granted=true | cut -d' ' -f1 | tr '\n' ';' ; 
  echo; 
 done > permission_report.csv

The resulting permission_report.csv contains one line per app, with a semicolon‑separated list of granted permissions. Sort, filter, and highlight any permission that looks out of place.

2.5 Revoke a Permission via ADB

Use the exact permission string from the report. Example: revoking location from com.example.map.

adb shell pm revoke com.example.map android.permission.ACCESS_FINE_LOCATION

ADB will respond with Success if the operation succeeded. Some permissions cannot be revoked because they are classified as “system” or “privileged” – attempting to revoke those will return an error like Permission revocation failed: Not a runtime permission.

2.6 Batch Revocation (Advanced)

If you have identified a set of apps that should never have a particular permission (e.g., no app should have READ_SMS unless it’s a messaging app), you can script a batch revocation:

#!/bin/bash
TARGET_PERMISSION=android.permission.READ_SMS
adb shell pm list packages -3 | cut -d':' -f2 | while read pkg; do
  if adb shell dumpsys package $pkg | grep -q $TARGET_PERMISSION; then
    echo "Revoking $TARGET_PERMISSION from $pkg"
    adb shell pm revoke $pkg $TARGET_PERMISSION
  fi
done

Save the script, make it executable (chmod +x revoke_sms.sh), and run it. Always review the list first; batch actions can break apps that legitimately need the permission.

Step 3: Verify Changes

After revoking, double‑check that the permission is truly gone:

1. Open the Permission Manager again and confirm the toggle is now in the Denied position.
2. Run the ADB dump for the app once more to see that the permission no longer appears in the granted=true list.

If an app crashes or stops working, you’ll see a notification that a required permission is missing. In that case you can either re‑grant the permission or uninstall the app if it’s not essential.

Troubleshooting Common Issues

• ADB not recognized: Ensure the platform-tools folder is in your system PATH, or invoke it with the full path (e.g., ~/android-sdk/platform-tools/adb).
• Device shows “unauthorized”: Re‑connect the USB cable, unlock the phone, and accept the RSA fingerprint prompt.
• Permission Manager missing: Some OEM skins hide the Permission Manager under a different name (e.g., “App permissions” or “Permission usage”). Search Settings for “permission”.
• Cannot revoke a permission: The permission may be a “system” permission that only the OS can manage, or the app may be a device‑admin app. You’ll need to disable the device admin status first (Settings → Security → Device admin apps).
• App stops working after revocation: This is expected for apps that truly need the permission. Consider alternatives (e.g., a different messaging app) or reinstall the app with the permission granted at install time.

Who This Is Useful For

• Privacy‑conscious users who want to limit data exposure.
• Power users comfortable with command‑line tools and who want a reproducible audit.
• Developers who need to verify that their own apps request only the permissions they truly need.

Best‑Practice Checklist

1. Perform a quick UI audit once a month using the Permission Manager.
2. Run the ADB CSV report quarterly to spot any newly added permissions.
3. Keep a backup of your device (or at least app data) before batch revocations.
4. When an app misbehaves after a revocation, either re‑grant the permission or replace the app with a more privacy‑friendly alternative.
5. Consider enabling Permission auto‑reset (Settings → Apps → Special app access → Auto‑reset permissions) for apps you haven’t used in months.

By following this workflow you gain a clear, repeatable picture of what each app on your Android device can see and do. Regular audits keep your personal data under your control without the need for rooting or third‑party privacy suites.