Grant Special Android Permissions Using ADB (No Root)

Before you start

Granting powerful permissions like SYSTEM_ALERT_WINDOW (draw‑over‑other‑apps) or WRITE_SECURE_SETTINGS gives an app capabilities that are normally reserved for system components. Misuse can lead to privacy leaks, unwanted overlays, or even device instability. This tutorial explains exactly why you might need these permissions, how to grant them safely via ADB, and how to verify or revoke them later.

Make sure you have the following prerequisites:

• A Windows, macOS, or Linux computer with Android Platform‑Tools (ADB) installed.
• USB debugging enabled on the Android device (Settings > About phone > tap Build number seven times, then Settings > System > Developer options > USB debugging).
• The device is charged to at least 50 % or connected to power – a failed command while the phone powers off can leave the app in a broken state.
• Either a USB cable or a reliable Wi‑Fi ADB connection (the steps are identical once the device is authorized).

Understanding the permissions you are about to grant

Android classifies permissions into several groups. The two most common “high‑risk” permissions that people request via ADB are:

• SYSTEM_ALERT_WINDOW – Allows an app to draw over other apps (e.g., chat heads, screen dimmers). Android shows a special “draw over other apps” toggle in Settings for each app that holds this permission.
• WRITE_SECURE_SETTINGS – Lets an app modify secure system settings (e.g., enabling/disabling ADB, changing the default launcher, toggling developer options). Only system apps normally receive this permission.

Both permissions are runtime permissions, meaning the user normally has to approve them in the UI. ADB can bypass the UI for debugging or testing purposes, but the same security considerations apply.

Step‑by‑step: Granting a permission via ADB

adb shell pm grant <package_name> <permission_name>

adb shell dumpsys package <package_name> | grep granted

android.permission.SYSTEM_ALERT_WINDOW: granted=true

Revoking a permission

If you later decide the app no longer needs the elevated rights, revoke them with pm revoke:

adb shell pm revoke <package_name> <permission_name>

Example:

adb shell pm revoke com.example.overlay android.permission.SYSTEM_ALERT_WINDOW

After revoking, the UI toggle will turn off and the app will lose the ability to draw overlays.

Alternative: Using App Ops for finer‑grained control

Android’s hidden appops tool can enable or disable specific operations that are not exposed as normal permissions. It’s useful when pm grant is blocked (e.g., on newer Android versions).

adb shell appops get <package_name>

adb shell appops set <package_name> SYSTEM_ALERT_WINDOW allow

adb shell appops get <package_name> SYSTEM_ALERT_WINDOW

Note: appops is undocumented and may change without notice. It also requires the same debugging privileges as pm.

Common pitfalls and troubleshooting

• Device not listed after adb devices: Ensure USB debugging is enabled, the cable is data‑capable, and the phone’s screen is unlocked. On some OEM skins you must also enable “USB debugging (Security settings)” under Developer options.
• “Permission denied” error: The device may be running Android 11+ with a stricter policy. Try adding --user 0 to the command:

  adb shell pm grant --user 0 com.example.tuner android.permission.WRITE_SECURE_SETTINGS

  If it still fails, the permission cannot be granted without root on that build.
• Permission appears granted but the app still cannot use it: Some apps perform their own runtime checks (e.g., calling Settings.canDrawOverlays()) which may cache the result. Force‑stop and restart the app, or reboot the device.
• App crashes after granting: The app may expect additional system privileges (e.g., being installed in /system). In that case, ADB grant alone is insufficient; you would need to install the APK as a system app, which requires root or a custom recovery – outside the scope of this tutorial.

Safety checklist before granting high‑risk permissions

1. Confirm the app’s source – only grant to apps you trust or are developing yourself.
2. Back up current settings: adb backup -apk -shared -all -f backup.ab (optional, for full device backup).
3. Take a screenshot of the permission state before and after the change – useful for rollback documentation.
4. Keep a note of the exact pm grant command you run, so you can easily revoke later.

Edge cases and device‑specific notes

• Samsung devices (One UI): The overlay permission may also be hidden under Settings > Apps > Special access > Display over other apps. After granting via ADB, you might still need to toggle the switch manually due to a UI bug.
• Android Go editions: Some permissions are not available at all; attempting to grant them will return “Permission denied”.
• Work profile / Android Enterprise: The pm command operates on the primary user (user 0) by default. To target a work profile, use the --user flag with the profile’s user ID (obtainable via adb shell pm list users).

Putting it all together – a practical example

Imagine you are testing a new “floating notes” app that lets you write quick notes that appear on top of any screen. The Play Store version does not request the overlay permission automatically because the developer wants the user to enable it manually. You want to automate the test on multiple devices.

1. Install the app via adb install notes.apk.
2. Find its package name: adb shell pm list packages | grep notes → com.example.floatingnotes.
3. Grant the overlay permission:

   adb shell pm grant com.example.floatingnotes android.permission.SYSTEM_ALERT_WINDOW

4. Verify the grant with adb shell dumpsys package com.example.floatingnotes | grep SYSTEM_ALERT_WINDOW.
5. Launch the app (you can start it via ADB as well):

   adb shell monkey -p com.example.floatingnotes -c android.intent.category.LAUNCHER 1

6. Open a different app (e.g., Settings) and confirm the note widget stays visible.
7. When the automated test suite finishes, revoke the permission:

   adb shell pm revoke com.example.floatingnotes android.permission.SYSTEM_ALERT_WINDOW

This workflow can be scripted in a CI pipeline to test overlay behavior across many device models without manual interaction.

Summary

Using ADB’s pm grant (or appops set) you can safely give an app high‑risk permissions for debugging, testing, or controlled personal use. The process is straightforward:

1. Enable USB debugging and connect the device.
2. Identify the app’s package name.
3. Run adb shell pm grant <package> <permission>.
4. Verify with dumpsys package or the Settings UI.
5. Test the app’s new capability.
6. Revoke when you’re done.

Always keep security in mind: only grant what you truly need, document every change, and revert the permission once testing is complete. With these safeguards, ADB becomes a powerful ally for developers and power users alike.