Skip to content
NoticeWelcome to Osteup! Practical tools and optimization tweaks shared freely.
Osteup LogoOsteup

How to Fix java.lang.SecurityException: grantRuntimePermission on Android

oosteup
··3 min read·0 views
Android
Sửa Lỗi java.lang.SecurityException grantRuntimePermission Trên Android Khi Dùng ADB SetEdit Shizuku Brevent

The error java.lang.SecurityException: grantRuntimePermission (often accompanied by Neither user 2000 nor current process has android.permission.GRANT_RUNTIME_PERMISSIONS) is a common roadblock when executing ADB shell commands to grant elevated permissions to apps like SetEdit, Brevent, Shizuku, LADB, or MacroDroid. This happens because OEM skins (ColorOS, Realme UI, MIUI, HyperOS, OriginOS) impose supplementary security restrictions that prevent shell UID 2000 from modifying protected settings.

Error Summary: When executing adb shell pm grant <package> android.permission.WRITE_SECURE_SETTINGS, the Android system denies authorization and throws a SecurityException. You do not need root access to resolve this problem; adjusting the correct developer toggles on your device is sufficient.

SecurityException Triggers Across Android OEM Skins

Different Android manufacturers implement unique safeguards over the ADB debugging bridge. The table below details the exact trigger and resolution for each major brand:

Device / OS Skin Root Cause Required Adjustment
Oppo, Realme, OnePlus (ColorOS / Realme UI / OxygenOS) "Permission Monitoring" actively blocks ADB shell commands from altering permissions. Turn off Permission monitoring (or toggle on Disable permission monitoring) in Developer Options.
Xiaomi, Redmi, POCO (MIUI / HyperOS) Secondary security debugging privilege is disabled by default. Enable USB debugging (Security settings) (requires a SIM card and Mi Account login).
Vivo, iQOO (Funtouch OS / OriginOS) System blocks remote settings modification via shell. Enable USB debugging and toggle on Allow security permissions via ADB.
Samsung & Stock Android (One UI, Pixel, Motorola) Revoked RSA keys or disconnected Wireless Debugging session. Revoke USB debugging authorizations, reconnect the cable, and tap "Always allow from this computer".

Method 1: Disable Permission Monitoring (Oppo, Realme, OnePlus)

For smartphones running ColorOS, Realme UI, or OxygenOS, permission monitoring causes over 90% of all grantRuntimePermission failures.

  1. Open Settings on your phone.
  2. Navigate to Additional settings (or System settings).
  3. Tap on Developer options. (If not visible, navigate to About device > tap Version / Build number 7 times).
  4. Scroll down the list to locate Permission monitoring.
  5. Toggle it OFF. On newer system builds, this setting is labeled Disable permission monitoring — in that case, switch it ON.
Disable Permission Monitoring toggle inside Android Developer Options
Location of the Permission Monitoring toggle in Developer Options

Once toggled, disconnect and reconnect your USB cable (or re-initialize ADB) and rerun the permission grant command.

Method 2: Enable USB Debugging Security Settings (Xiaomi, Redmi, POCO)

On MIUI and HyperOS devices, Xiaomi enforces an account-bound safety layer that rejects ADB runtime modifications unless security authorizations are explicitly approved:

  1. Ensure an active SIM card with mobile data is installed (Xiaomi requires network verification with your Mi Account).
  2. Open Settings > Additional settings > Developer options.
  3. Enable standard USB debugging.
  4. Scroll further down and toggle on USB debugging (Security settings).
  5. Review the 3 successive security warning prompts (5-second countdown each) and tap Next and Accept.
Xiaomi Troubleshooting: If you encounter the error "Device temporarily restricted" when turning on Security Settings, disconnect from Wi-Fi, turn on mobile data on your SIM, and toggle the setting again.

Method 3: Address Wireless Debugging & LADB Dropouts

When running permissions directly on-device using local terminal utilities such as LADB, Shizuku, or Brevent via Wireless Debugging (Android 11+), connection state issues trigger security exceptions:

  • Keep both toggles enabled: In Developer Options, ensure both USB debugging and Wireless debugging remain turned on simultaneously.
  • Prevent port swapping: Android randomizes the wireless debugging port upon reconnection. Keep your screen in Split-Screen mode while pairing LADB to ensure the port and pairing PIN remain synchronized.
  • Clear paired credentials: If repeated failures occur, enter Wireless debugging > delete all previously paired devices, and pair your local terminal again.

Verification: Testing Common ADB Grant Commands

After adjusting your security configurations, open Command Prompt / Terminal on your PC or your LADB console to verify functionality:

1. Grant secure system writing permissions to SetEdit:

bash
adb shell pm grant by4a.setedit22 android.permission.WRITE_SECURE_SETTINGS

2. Grant system dump and background management to Brevent:

bash
adb shell pm grant me.piebridge.brevent android.permission.DUMP

3. Grant system UI modification permissions to System UI Tuner:

bash
adb shell pm grant com.zacharee1.systemuituner android.permission.WRITE_SECURE_SETTINGSadb shell pm grant com.zacharee1.systemuituner android.permission.DUMP
Expected Success Output: When ADB executes a permission grant command successfully, it outputs zero text and immediately returns a blank command prompt. If a SecurityException reappears, reboot your phone and reconnect ADB.

Frequently Asked Questions (FAQ)

Does disabling permission monitoring expose my phone to security vulnerabilities?

No. This setting strictly governs commands executed through the ADB bridge. It enables legitimate system optimization and customization utilities to function. Once you finish granting permissions, you may re-enable monitoring if desired.

Why does the ADB permission error return after restarting the phone?

Certain Realme and Oppo builds automatically revert "Permission Monitoring" back to default upon reboot. However, permissions granted beforehand (such as WRITE_SECURE_SETTINGS) persist permanently across device reboots.

Does this SecurityException ever happen on rooted devices?

No. Rooted devices leveraging Magisk or KernelSU utilize Superuser (su) directly to assign runtime permissions, bypassing shell UID 2000 restrictions altogether.

Was this article helpful?

Related Articles

Comments(2)

Ngu Quang
Ngu Quang3/9/2026

ngon

Ngu Quang
Ngu Quang3/9/2026

rất ngon