Basic syntax

How to Use ADB Grant and Revoke Commands

11 May 2026 Stephan Petzl Leave a comment Tech-Help

How to use adb grant and adb revoke correctly

If you want to change an app’s runtime permissions from the command line, the key thing to know is that these commands are used through pm inside an ADB shell session. The syntax is not just the permission name by itself; you need both the package name and the full permission identifier.

Use the following forms:

adb shell pm grant <package-name> <permission>
adb shell pm revoke <package-name> <permission>

For example, to grant an app access to read contacts:

adb shell pm grant com.name.app android.permission.READ_CONTACTS

And to revoke it:

adb shell pm revoke com.name.app android.permission.READ_CONTACTS

What you need to know before using it

  • Use the full permission name such as android.permission.WRITE_EXTERNAL_STORAGE, not just WRITE_EXTERNAL_STORAGE.
  • Use the app’s package name such as com.name.app.
  • Only runtime permissions can be changed this way, and only if the app declared them in its manifest.
  • Some permissions may not be grantable depending on Android version and app type.

Older Android versions vs newer Android versions

On newer Android versions, you can usually run the command directly as shown above. On older setups, you may need to open an interactive shell first:

adb shell
pm grant com.name.app android.permission.READ_CONTACTS

If the direct command does not work, try the shell-first version. This difference is especially relevant when you are working with older devices or legacy development environments.

How to find the right package and permission

If you are not sure which package name or permissions to use, follow this workflow:

  1. List installed packages:
adb shell pm list packages -f
  1. Pull the APK from the device if needed:
adb pull /path/to/package.apk
  1. Inspect the permissions declared by the app:
aapt d permissions path/to/app.apk

This is the safest way to confirm the exact permission string before granting or revoking it.

Grant or revoke all permissions for an app

If you want to automate the process, you can extract the permissions declared by the app and apply them in a loop. A practical approach is to parse the app’s runtime permissions and then call pm grant or pm revoke for each one.

For example, a shell pipeline can gather permissions from the APK and pass them to ADB. This is useful when you are testing an app repeatedly and want to avoid manually granting permissions one by one.

Resetting permissions for all apps

If you do not know which permission to change, or you want to return the device to a clean state, you can reset runtime permissions globally:

adb shell pm reset-permissions

Be careful with this command: it affects all apps on the device, not just one specific package.

Common mistakes to avoid

  • Using only the short permission name instead of the full android.permission.* value.
  • Forgetting to include the package name.
  • Trying to grant a permission the app did not declare.
  • Expecting reset-permissions to work on a single app.

If you just want the shortest reliable path, use this sequence:

  1. Identify the package name.
  2. Confirm the permission string from the APK or manifest.
  3. Run adb shell pm grant package permission or adb shell pm revoke package permission.
  4. If that fails on an older device, try the interactive adb shell approach.

This method is simple, repeatable, and works well for debugging permission-related issues during development and QA.

Where Repeato fits in

If you regularly test permission-heavy app flows, Repeato can help reduce the manual work. Because it is a no-code test automation tool for iOS, Android, and web apps, you can quickly record and run tests that verify permission dialogs and related user journeys. Its support for command-line scripts and ADB commands is also useful when you need to sequence device actions reliably during test setup.

Since Repeato stores workspace data in text and JSON format, it also fits well into version-controlled test workflows where permission changes and device setup steps need to stay reproducible.

Like this article? there’s more where that came from!