You stare at the screen of your phone, the battery draining faster than water through a cheap paper cup, and that shiny new automation app you just paid four bucks for is aggressively demanding something called WRITE_SECURE_SETTINGS. You tap the toggle. Nothing happens. A stubborn little toast message pops up telling you that due to Android’s internal security restrictions, you simply cannot flip that switch without jumping through some serious technical hoops via a computer. Frustrating, right?
Most people quit right here.
They refund the app, toss their phone on the couch, and accept their fate. But you aren’t most people. You want control over your hardware. You want to hide that annoying carrier label in the status bar, aggressively doze background apps to save juice, or maybe remap the Bixby button to actually do something useful. To pull off any of these tricks without resorting to the messy, warranty-voiding process of rooting your device, you have to bypass the standard user interface entirely. You have to talk directly to the operating system.
You need the Android Debug Bridge.
Back in 2019, I nearly gave myself a heart attack trying to debloat a carrier-locked Samsung Galaxy S10. I was sick of the pre-installed garbage eating up my RAM. I plugged the phone into my beat-up Lenovo ThinkPad, opened a command terminal, and hastily copy-pasted a string of text I found on an obscure forum. I hit enter. Instantly, the phone’s screen went entirely black. No status bar. No home button. Just a glowing, terrifying void. I had accidentally revoked a critical system permission instead of granting one to my package disabler app. It took me three hours of sweating over a keyboard, manually pushing commands blindly into the terminal, to restore the system UI. That nightmare taught me a crucial lesson: the command line is entirely unforgiving. It does exactly what you tell it to do, even if what you tell it to do is incredibly stupid.
So, let’s make sure you do this right.
What the Heck is ADB Anyway?
Think of your phone as a heavily guarded nightclub. The standard settings menu is the front door. The bouncers—Google’s security protocols—only let certain guests in, and they strictly dictate what those guests can touch. An app from the Play Store might be allowed to use your camera, but it absolutely cannot alter the system-level sleep cycles or change global animation speeds.
ADB is the secret backdoor reserved for the club owners.
It stands for Android Debug Bridge. It’s a versatile command-line tool that lets developers (and stubborn tinkerers like us) communicate directly with an Android device. By connecting your phone to a computer—either via a physical USB cable or over a local Wi-Fi network—you open a secure tunnel. Through this tunnel, you can push files, pull logs, install hidden packages, and most importantly for our current headache, grant elevated permissions that the graphical interface outright refuses to handle.
When an app begs you for a permission via ADB, it usually wants access to a hidden API. Apps like Tasker, Macrodroid, SystemUI Tuner, and Battery Guru rely heavily on these hidden pathways to perform their magic.
Setting the Stage: The Mandatory Prerequisites
You can’t just plug your phone in and start typing hacker jargon. You have to prep both your computer and your mobile device. If you skip a step here, you will crash headfirst into a wall of errors later. Believe me.
Step 1: Awakening the Developer Options
Android hides its most powerful tools from casual users. To unlock them, you have to perform a bizarre little ritual.
- Open your phone’s Settings app.
- Scroll all the way down to About phone.
- Find the entry labeled Build number. (On Samsung devices, this is buried under Software information. On Xiaomi devices, you are looking for the MIUI version or HyperOS version instead).
- Tap that build number exactly seven times in rapid succession.
Around the fourth tap, a tiny message will appear saying “You are 3 steps away from being a developer.” Keep tapping. Eventually, it will ask for your PIN or fingerprint. Once verified, the system formally congratulates you on your new developer status.
Step 2: Flipping the USB Debugging Switch
Now back out to the main Settings menu. You will find a brand new section called Developer options. On Pixel phones, it sits inside the System menu. Dive in there.
Scroll down until you see USB debugging. Turn it on. The phone will throw a scary warning at you, claiming that this mode is intended for development purposes only and that malicious apps could steal your data if you aren’t careful. Acknowledge the warning. You are officially ready on the mobile side.
A massive warning for Xiaomi, Poco, and Redmi users: MIUI and HyperOS are notoriously hostile to ADB. Turning on standard USB debugging is not enough. You must also scroll down slightly further and enable USB debugging (Security settings). If you ignore this, every single permission command you try to run will fail instantly with a generic “Security Exception” error. Oh, and Xiaomi will force you to insert a SIM card and log into a Mi Account just to flip that secondary switch. It is intensely annoying, but entirely unavoidable.
Step 3: Arming Your Computer
Your computer needs to know how to speak Android. For this, you need the official platform-tools package direct from Google. Forget all those shady “One-Click ADB Installer” executables floating around the internet. Half of them are severely outdated, and the other half are packed with malware.
Head to the official Android developer website. Search for “SDK Platform-Tools.” Download the ZIP file corresponding to your operating system (Windows, Mac, or Linux).
Extract that ZIP file somewhere easily accessible. I highly recommend tossing the extracted folder straight into the root of your C: drive on Windows (e.g., C:\platform-tools) or your main home directory on a Mac. Keeping the folder path short and free of weird spaces makes your life infinitely easier when you start typing directory commands.
The Critical Handshake: Connecting Device and Machine
Grab a high-quality USB cable. Do not use that frayed gas-station cable you keep in your car. Data transfer requires stable pins, and cheap charging-only cables will drive you insane by constantly dropping the connection.
Plug the phone into your computer.
Now, open a command terminal on your machine.
- Windows: Press the Windows key, type
cmd, and hit Enter. - Mac: Press Command + Space, type
Terminal, and hit Enter. - Linux: You already know what to do.
You need to point your terminal to the exact folder where you extracted those tools. If you put it on your C drive like I suggested, type this into the Windows command prompt:
cd C:\platform-tools
Hit enter. The prompt should now reflect that you are inside that specific folder. (Mac users would type something like cd ~/platform-tools).
Time for the moment of truth. Type the following command and press enter:
adb devices
(Mac and Linux users might need to type ./adb devices if the tool isn’t added to their system PATH variable. The little dot-slash forces the terminal to look inside the current directory.)
Look closely at your phone screen right now. A prompt should suddenly appear asking: “Allow USB debugging?” It will display a terrifying string of random letters and numbers called an RSA key fingerprint. Check the box that says “Always allow from this computer” and tap Allow.
Look back at your computer terminal. It should print out a random string of alphanumeric characters followed by the word device. If it says unauthorized, you missed the prompt on your phone. Unplug the cable, plug it back in, and try again. If it says absolutely nothing, your computer doesn’t recognize the phone—usually a sign of a bad cable or missing Windows drivers.
Deconstructing the Magic Spell
You have an established connection. The bridge is open. Now you need to push the actual command. But blindly copying and pasting commands from Reddit without understanding what they do is a great way to break your phone.
Every single permission-granting operation follows the exact same structural logic. It looks like this:
adb shell pm grant [package_name] [permission_name]
Let’s dissect this monster so you actually know what you are telling the computer to do.
adb: You are waking up the Android Debug Bridge program on your computer.
shell: You are telling the bridge that you want to open a direct Unix shell on the mobile device itself. Essentially, “Hey phone, I am about to speak your native language.”
pm: This stands for Package Manager. The Package Manager is the internal Android service responsible for keeping track of every single app installed on the device. It handles installations, uninstallations, and—you guessed it—security access rights.
grant: The specific action you want the Package Manager to perform.
[package_name]: This is the internal identification code for the app you want to modify. It almost never looks like the name of the app on your home screen. Instead, it uses a reverse-domain naming convention. For example, Google Chrome is com.android.chrome. Tasker is net.dinglisch.android.taskerm.
[permission_name]: The exact technical name of the system access right you are handing over.
Hunting Down the Elusive Package Name
The biggest hurdle people face isn’t typing the command; it’s figuring out the exact package name of the app they are trying to fix. If you type “Tasker” instead of “net.dinglisch.android.taskerm”, the terminal will just spit back an error laughing at you.
How do you find it?
The easiest method doesn’t even require a computer. Open the Google Play Store on your phone, search for an app called App Inspector, and install it. Open it up, tap on the app you are interested in, and look right under the title. You will see a string of text starting with “com.” or “org.” or “net.” That is your golden ticket.
Alternatively, if you want to feel like a real terminal jockey, you can ask ADB to list every single app installed on your phone. Type this:
adb shell pm list packages
Your screen will instantly flood with hundreds of lines of text. It’s overwhelming. To narrow it down, you can filter the results. Let’s say you are looking for an app related to battery management. You can pipe the command through a search filter like this:
adb shell pm list packages | findstr battery (On Mac/Linux, replace findstr with grep).
This trick saves hours of manual scrolling.
The Heavy Hitters: Permissions You Actually Care About
Not all access rights are created equal. Most apps ask for basic things like camera or location access, which you can easily handle via the normal phone settings. The commands we run over a wire are usually reserved for deep system modifications. Here is a breakdown of the most frequently demanded ADB permissions, what they actually do, and why apps beg for them.
| The Exact Permission Command String | What It Actually Does to Your Phone | Common Apps That Demand It |
|---|---|---|
android.permission.WRITE_SECURE_SETTINGS |
Allows an app to read and write to the protected system settings database. This is the holy grail. It lets an app toggle location services, change navigation bar styles, force immersive mode, or mess with the lock screen without your manual input. | Tasker, Macrodroid, SystemUI Tuner, AutoTools, SecondScreen. |
android.permission.DUMP |
Grants the ability to extract internal system diagnostic logs. While it sounds terrifying, battery monitoring apps need this to read exactly which background process is keeping your processor awake at 3 AM. | BetterBatteryStats, GSAM Battery Monitor, Wakelock Detector. |
android.permission.BATTERY_STATS |
Provides granular, low-level access to the internal battery usage history. Combined with the DUMP command above, it gives apps a perfect picture of your power consumption. | Naptime, Battery Guru, AccuBattery (advanced modes). |
android.permission.PACKAGE_USAGE_STATS |
Allows an app to see exactly what other apps you are using, how often you open them, and how long you look at them. Digital wellbeing alternatives rely heavily on this. | ActionDash, Greenify, various parental control apps. |
android.permission.SYSTEM_ALERT_WINDOW |
Lets an app draw over other apps. While technically available in the standard settings menu, some aggressive OEM skins (like MIUI) hide it, forcing you to grant it manually over the wire for screen recorders or gesture overlays. | Fluid Navigation Gestures, FNG, various screen recorders. |
Executing the Command (And Holding Your Breath)
You have your terminal open. The device is connected and authorized. You know your package name. You know the permission string. It is time to pull the trigger.
Let’s walk through a highly realistic scenario. You downloaded an app called SystemUI Tuner (package name: com.zacharee1.systemuituner). You want it to hide the Bluetooth and Alarm icons from your status bar because you prefer a clean aesthetic. The app tells you it needs WRITE_SECURE_SETTINGS.
Here is exactly what you type into that black box:
adb shell pm grant com.zacharee1.systemuituner android.permission.WRITE_SECURE_SETTINGS
Read it twice. Check for typos. Did you put a space between the package name and the permission? Did you accidentally capitalize ‘android’? The terminal is entirely literal. A single misplaced character ruins the whole operation.
Hit Enter.
What happens next usually confuses beginners. If the command works perfectly, the terminal outputs… absolutely nothing. It just drops you down to a new, blank command line prompt. No “Success!” message. No virtual confetti. In the world of command-line interfaces, silence is golden. It means the system accepted your instruction without complaint.
Pick up your phone. Force close the app you were trying to fix, and open it again. The annoying pop-up begging for access should be completely gone. You won. You bypassed the bouncers.
When Things Go Horribly Wrong: A Troubleshooting Guide
Rarely does everything work flawlessly on the first try. Android is fragmented, Windows drivers are notoriously flaky, and human fingers make typos. When the terminal spits red text at you, don’t panic. Almost every error has a logical explanation.
Error: “adb: command not found” or “adb is not recognized as an internal or external command”
This is the most common roadblock. Your computer is basically saying, “I have no idea what ‘adb’ means.”
This happens because you did not open your terminal inside the exact folder where the platform-tools live. You are probably sitting in C:\Users\YourName instead of C:\platform-tools. You either need to use the cd command to navigate to the correct folder first, or you need to add the platform-tools folder to your Windows System PATH environment variable. (Adding it to your PATH is a permanent fix that lets you run the tool from any folder, but it requires digging into advanced system properties—a headache for another day. Just use the cd command for now).
Error: “Security exception: grantRuntimePermission”
The terminal refuses to apply the change, citing a security block. If you see this, I can almost guarantee you are holding a Xiaomi, Poco, Redmi, or Oppo phone.
Chinese OEMs heavily modify the core operating system to prevent malicious apps from hijacking devices. As mentioned earlier, standard debugging isn’t enough for them. Go back into your Developer Options. Find the toggle for Disable permission monitoring or USB debugging (Security settings). Turn it on. Yes, it might ask you to sign into an account. Yes, it might make you wait through three separate 10-second countdown timers before letting you click ‘Accept’. Suffer through it, then try the command again.
Error: “Bad argument” or “Unknown package”
You typed something wrong. Plain and simple. You either misspelled the package name (e.g., typing com.android.crome instead of chrome), or you misspelled the permission string. Remember, package names and permissions are strictly case-sensitive. WRITE_SECURE_SETTINGS must be in all caps. android.permission must be strictly lowercase.
Error: “Operation not allowed: java.lang.SecurityException”
This one hurts. This means the app developer never explicitly declared that they might need this permission inside the app’s internal manifest file. You cannot force an app to accept a permission it wasn’t programmed to ask for. If the app’s code doesn’t explicitly mention WRITE_SECURE_SETTINGS, the operating system will block you from granting it, no matter how hard you try. Your only solution here is to contact the app developer and ask them to update their manifest.
The Undo Button: Revoking What You Granted
Let’s say you grant an app deep system access, and suddenly your phone starts behaving strangely. The battery tanks. The screen flickers. You suspect the app is abusing the power you just handed over.
You can easily slam the door shut.
The syntax is completely identical to granting, except you swap out one single word. You change grant to revoke.
adb shell pm revoke [package_name] [permission_name]
Using our previous example, killing the access for SystemUI Tuner looks like this:
adb shell pm revoke com.zacharee1.systemuituner android.permission.WRITE_SECURE_SETTINGS
Hit enter. Silence confirms the kill. The app is instantly stripped of its privileges and returned to its restricted state.
Cutting the Cord: Wireless ADB (Android 11 and Newer)
Cables are annoying. They disconnect if you bump the desk too hard. Recognizing this, Google introduced a massive quality-of-life improvement starting in Android 11: native Wireless Debugging.
You no longer need a physical wire to push commands, provided both your phone and your computer are connected to the exact same Wi-Fi network. This process is slightly more tedious to set up initially, but it feels like absolute magic once it is running.
Here is how you ditch the wire:
- Ensure your phone and PC are on the same Wi-Fi network. (Disable your VPN temporarily if you use one, as it breaks local network discovery).
- Go to Developer Options on your phone.
- Scroll down to Wireless debugging and toggle it on.
- Tap on the words “Wireless debugging” to enter its specific sub-menu.
- Tap Pair device with pairing code.
A pop-up will appear on your phone screen showing a massive six-digit Wi-Fi pairing code, along with an IP address and a port number (it will look something like 192.168.1.55:41234).
Now, jump to your computer terminal and type:
adb pair 192.168.1.55:41234 (Replace these numbers with exactly what your phone shows. The port number changes every single time you do this.)
The terminal will prompt you to enter the six-digit pairing code. Type it in. If successful, the terminal will say “Successfully paired to…”
You are paired, but you aren’t connected yet. Look back at your phone screen. Under the “IP address & Port” section (not the pairing pop-up, the main wireless debugging screen), you will see a slightly different port number. It might look like 192.168.1.55:38555.
Type this final command into your terminal:
adb connect 192.168.1.55:38555
Bam. You are connected over thin air. You can now run your pm grant commands exactly as you would with a cable. Just remember that the wireless connection drops automatically if you turn off Wi-Fi or restart the phone, requiring you to run the adb connect command again next time.
Why Not Just Root the Phone?
If you have read this far, a logical question might pop into your head. If I want deep system control, why am I messing around with individual command lines? Why not just root the device, install Magisk, and give apps absolute blanket permission to do whatever they want?
Ten years ago, rooting was practically mandatory for power users. Today? It is a massive liability.
Banking apps, mobile payment systems like Google Wallet, and even certain high-end games (like Pokémon GO) actively scan your device for root access. If they detect a compromised system partition, they refuse to launch. Bypassing these safety checks turns into a weekly cat-and-mouse game of hiding your root status from the safety protocols.
Furthermore, an unlocked bootloader—a strict requirement for rooting—destroys your device’s hardware-backed security keys. If you lose a rooted phone, a thief can bypass your lock screen with trivial ease.
ADB offers a brilliant middle ground. It grants you 80% of the benefits of rooting with exactly 0% of the security risks. Because you aren’t altering the core system partition or unlocking the bootloader, your banking apps remain perfectly happy. Google Wallet still lets you buy coffee. Netflix still streams in full HD. You get the customization you crave without breaking the underlying trust chain of the operating system.
The Security Reality Check
Just because this method is safer than rooting doesn’t mean it is entirely devoid of risk. You are handing over keys to the kingdom. You must trust the app you are granting these permissions to.
Let’s talk about WRITE_SECURE_SETTINGS again. An app with this permission can silently disable your lock screen PIN. It can turn on your GPS without a visible prompt. It can theoretically intercept notifications.
If you give this power to a reputable, open-source automation app developed by a known community member, you are fine. If you grant it to a sketchy “Battery Booster Pro 2024” app you found on a third-party APK site, you are essentially begging to have your data scraped.
Always audit your apps. Ask yourself why a specific app needs a specific permission. If a simple volume-slider widget asks for the ability to dump battery stats, that makes zero logical sense. Deny it. Uninstall it. Move on.
Scripting the Tedium Away
If you are the kind of person who flashes custom ROMs frequently, or if you regularly factory reset your device to keep it feeling snappy, manually typing these commands every single time gets incredibly tedious.
You can automate the automation.
On Windows, you can write a simple Batch script to push all your required permissions at once. Open standard Notepad. Type out your commands, one per line.
adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS
adb shell pm grant com.zacharee1.systemuituner android.permission.WRITE_SECURE_SETTINGS
adb shell pm grant com.franco.doze android.permission.DUMP
Save the file as permissions.bat directly inside your platform-tools folder. The next time you wipe your phone, you simply plug it in, open the terminal, type permissions.bat, and press enter. The computer fires off all three commands in less than a second. It is an incredibly satisfying feeling.
Mac and Linux users can do the exact same thing by creating a simple shell script (saving the file as permissions.sh) and making it executable via the chmod +x command.
Mac vs. Windows: The Silent Friction Points
I feel obligated to point out that the experience differs slightly depending on the computer sitting on your desk. Windows users generally have a tougher time initially because Windows is notoriously awful at automatically fetching the correct USB drivers for obscure Android devices. Sometimes, your phone connects, charges, but refuses to show up when you type adb devices. You end up digging through the Windows Device Manager, manually updating drivers, and forcing the system to recognize the phone as an “Android Composite ADB Interface.” It is a rite of passage.
Mac users usually skip the driver headache entirely. Unix-based systems are fantastic at natively recognizing Android devices over USB. However, Mac users face a different annoyance: terminal security protocols. Recent versions of macOS heavily restrict terminal access. You might find that your Mac refuses to run the tool because it came from an “unidentified developer.” You have to open your Mac’s System Settings, navigate to Privacy & Security, and manually click “Allow Anyway” to let the binary execute.
Also, if you are a Mac user and you plan on doing this more than once in your life, do yourself a massive favor and install Homebrew. It is a package manager for macOS. Instead of manually downloading ZIP files from Google and messing with folders, you simply open your terminal and type:
brew install android-platform-tools
Homebrew downloads the latest version, installs it, and automatically configures your system paths. From that moment on, you can just open a fresh terminal anywhere and type your commands. No folder navigation required.
A Final Word on OEM Weirdness
Before you run off to start hacking your status bar, keep in mind that Android is not a monolith. Google builds the foundation, but companies like Samsung, OnePlus, and Motorola build entire houses on top of it. Sometimes, those houses have weird, hidden rooms.
For instance, Samsung devices have a completely separate set of internal permissions tied to their proprietary Knox security framework. You might successfully grant WRITE_SECURE_SETTINGS to an app on a Galaxy S24, only to find that it still can’t toggle the mobile data switch. Why? Because Samsung hardcoded that specific toggle to require a Knox-level signature, which you cannot bypass with a simple wire.
Similarly, aggressive battery management systems on Chinese phones might silently kill the background app you just spent twenty minutes configuring. You grant the permission, the app works perfectly for exactly three hours, and then the phone’s internal memory manager ruthlessly assassinates the process to save 0.01% battery life. You have to dive into the app settings and manually exempt your specific app from battery optimization.
It is a constant, shifting puzzle. You fix one problem, and the operating system throws a new limitation at you. But that friction is exactly what makes fixing it so incredibly rewarding.
You aren’t just a passive consumer tapping shiny icons anymore. You are under the hood. You are dictating terms to the machine. Keep that terminal open, double-check your syntax, and don’t let a “command not found” error stop you from bending the hardware to your absolute will.
