11 May 2026 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 justWRITE_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:
- List installed packages:
adb shell pm list packages -f
- Pull the APK from the device if needed:
adb pull /path/to/package.apk
- 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-permissionsto work on a single app.
Recommended workflow for most users
If you just want the shortest reliable path, use this sequence:
- Identify the package name.
- Confirm the permission string from the APK or manifest.
- Run
adb shell pm grant package permissionoradb shell pm revoke package permission. - If that fails on an older device, try the interactive
adb shellapproach.
This method is simple, repeatable, and works well for debugging permission-related issues during development and QA.
Related guides
- Granting app permissions using ADB without root
- How to list permissions of an Android application using ADB
- Querying device state via ADB shell command
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.