Grant or Revoke Android App Permissions Using ADB (No Root)

Sometimes the Android Settings UI feels slow, especially when you need to tweak permissions for dozens of apps or for a newly installed app that immediately asks for access you don’t want to grant. ADB (Android Debug Bridge) lets you change permissions directly from your computer, without rooting the device. This tutorial walks you through the entire workflow: preparing your PC, connecting the phone, listing permissions, and safely granting or revoking them.

Why use ADB for permission management?

Android’s runtime permission model (introduced in Android 6.0 Marshmallow) stores each grant in a system database. The UI only exposes a subset of that data, and it can be cumbersome to repeat the same steps for many apps. ADB gives you:

• Speed – one command changes a permission for any app.
• Precision – you can target a specific permission that the UI hides (e.g., android.permission.READ_CALL_LOG).
• Automation – scripts can apply a baseline permission set after a fresh install.

All of this works on stock Android and on most OEM skins, as long as you have USB debugging enabled. No root, no custom recovery, and no third‑party apps required.

Before you start

• Computer running Windows, macOS, or Linux with adb (part of the Android SDK Platform‑Tools).
• USB cable that supports data transfer (charging‑only cables won’t work).
• Device with Developer options → USB debugging turned on.
• At least 30 % battery or a charger plugged in.

Step 1 – Install the Android Platform‑Tools

Step 2 – Enable USB Debugging on the phone

Step 3 – Verify the device connection

Step 4 – Identify the package name of the target app

ADB works with the app’s package identifier (e.g., com.whatsapp). You can find it in several ways:

Step 5 – List the current permissions of the app

Step 6 – Grant a permission

Use the pm grant command. This works for “dangerous” runtime permissions and for many “normal” permissions that the UI can’t toggle.

Step 7 – Revoke a permission

Reversing a grant is equally simple with pm revoke.

Step 8 – Using appops for special cases

Some permissions are controlled by the appops subsystem (e.g., android.permission.SYSTEM_ALERT_WINDOW or android.permission.WRITE_SETTINGS). The pm commands won’t affect them.

Step 9 – Verify the change inside the app

Most apps react instantly, but a few cache their permission state. To be safe:

• Force‑stop the app: adb shell am force-stop PACKAGE_NAME.
• Re‑open the app manually and check the feature that required the permission.

If the feature works (or stops working after a revoke), the command succeeded.

Step 10 – Automating bulk changes (optional)

When you have many apps to adjust, a short shell script can save time. Below is a minimal example for a Unix‑like shell:

#!/bin/bash
# grant‑location.sh – grant location to a list of packages
PACKAGES=(
  "com.example.map"
  "com.weather.app"
  "com.social.checkin"
)
for PKG in "${PACKAGES[@]}"; do
  echo "Granting location to $PKG"
  adb shell pm grant "$PKG" android.permission.ACCESS_FINE_LOCATION
done

Save as grant-location.sh, make it executable (chmod +x grant-location.sh), and run it while the device is connected.

Troubleshooting

Command returns “Security exception”

The device is likely running Android 10+ with Scoped Storage or a manufacturer‑added restriction that blocks pm for non‑system apps. In that case:

• Ensure the app you’re targeting is not a system app. System apps require adb root, which is unavailable on production devices.
• Try the appops approach for the specific permission.

Permission reverts after a reboot

On some OEM skins (e.g., certain versions of Xiaomi’s MIUI), the permission database is refreshed on boot. To make changes persistent:

• Re‑apply the commands after each reboot, or
• Create a small adb script and add it to your PC’s startup routine.

“Permission denied” when using appops

Make sure you typed the exact operation name. Use adb shell appops list to see all supported ops. If the operation is still denied, the device may have a vendor‑level policy that cannot be overridden without root.

Safety warnings

• Revoking a permission that an app depends on can cause crashes, data loss, or unexpected behavior. Test after each change.
• Granting a dangerous permission (e.g., READ_CONTACTS) to an untrusted app may expose personal data. Only grant what you truly need.
• Never run adb shell pm grant on a package you do not recognize – it could be a hidden component of malware.

When to prefer the UI over ADB

If you only need to adjust one or two permissions, the Settings UI is quicker and provides a visual confirmation. Use ADB when you:

• Need to apply the same change to many apps.
• Want to script a baseline permission set after a factory reset.
• Encounter a permission that the UI hides (e.g., SYSTEM_ALERT_WINDOW).

Wrap‑up

With the steps above you can confidently grant or revoke any runtime permission on a non‑rooted Android device using ADB. The workflow is repeatable, scriptable, and works across most manufacturers and Android versions. Keep a short cheat‑sheet of the most common permission strings you use, and you’ll spend less time navigating menus and more time using your phone the way you want.