Home Page » News » How To » How to Use Android’s Hidden App Ops to Fine‑Tune App Permissions (No Root)

Using Android’s Hidden App Ops to Fine‑Tune App Permissions

17 min read Learn how to access Android’s hidden App Ops tool via ADB, view and modify individual permission settings, and safely fine‑tune app behavior without rooting your device. October 09, 2026 20:30

Why you might need App Ops

Android’s public permission manager covers the most common privacy settings, but many granular controls remain hidden. App Ops is an internal framework that stores the exact state of every permission a package requests – even those that the UI hides or bundles together. By tapping into App Ops you can:

Re‑enable a permission that the system auto‑revoked after a reboot.
Block a permission that the UI does not expose (e.g., background location on older Android versions).
Test how an app behaves when a specific operation is denied without uninstalling it.

This tutorial shows how to reach App Ops using the standard adb tool, read the current state, and safely modify it – all without rooting the device.

Before you start

Make sure you have a computer with Android Platform‑Tools installed. The tutorial works on Windows, macOS, and Linux.

Enable Developer options on your phone: Settings > About phone > tap Build number seven times.
Activate USB debugging: Settings > System > Advanced > Developer options > USB debugging.
Use a USB‑C cable that supports data transfer (charging‑only cables will not work).
Charge your phone to at least 50 % – the steps involve restarting the device.
Back up any critical data. Changing App Ops rarely corrupts data, but a mis‑typed command can unintentionally block a core permission (e.g., READ_CONTACTS) and render an app unusable.

Understanding the App Ops model

App Ops stores permission states as integer codes:

Code	Meaning
0	Allowed (default)
1	Ignored – the operation is blocked silently.
2	Default – system decides based on the public permission UI.
3	Foreground only – operation works only while the app is in the foreground.

When you toggle a permission in Settings, Android writes the corresponding App Ops entry. However, the UI does not expose every operation. For example, OP_FINE_LOCATION (fine‑grained GPS) and OP_COARSE_LOCATION (network‑based location) are separate, but the Settings screen groups them under a single “Location” switch.

Accessing App Ops via ADB

The adb shell command lets you run a limited shell on the device. From there you can invoke the hidden appops binary. The binary is present on virtually every Android release from 5.0 (Lollipop) onward, so the method works across a wide range of devices.

Step 1 – Verify ADB connection

Connect your phone to the computer with the USB cable.
Open a terminal (Command Prompt, PowerShell, or macOS/Linux shell).
Run adb devices. You should see a line like 0123456789ABCDEF device.

If the device shows as unauthorized, look at your phone for a prompt asking to allow USB debugging and tap Allow. Tick the “Always allow from this computer” box to avoid future prompts.

Step 2 – Open a shell with the correct user

Starting with Android 6.0, the appops binary can be executed only by the shell user (UID 2000). The simplest way is to use adb shell directly, which drops you into that user context.

adb shell

You should see a prompt that looks like shell@android:/ $. If you see root@, you have a rooted device – the tutorial still works, but the extra privileges are unnecessary.

Listing current App Ops for an app

The most common first step is to see which operations an app currently has. You need the package name (e.g., com.whatsapp for WhatsApp). You can obtain it via adb shell pm list packages or by looking in the Play Store URL.

Step 3 – Get the package name (if you don’t know it)

adb shell pm list packages | grep -i whatsapp

The output will contain a line like package:com.whatsapp. The string after the colon is the package name you’ll use in the next commands.

Step 4 – Dump the App Ops table for that package

adb shell appops get com.whatsapp

The command prints rows such as:

android:camera:allow
android:record_audio:ignore
android:access_fine_location:allow

Each line shows the operation name and its current mode (allow, ignore, etc.). This is the raw view you’ll edit later.

Modifying a single operation

To change a permission, use the set sub‑command. The syntax is:

adb shell appops set PACKAGE OPERATION MODE

Where MODE can be allow, ignore, default, or foreground. Let’s walk through a practical scenario.

Scenario – Block background location for a fitness app without disabling foreground GPS

Identify the package name, e.g., com.example.fitness.

Check the current location ops:

adb shell appops get com.example.fitness | grep location

If you see android:access_fine_location:allow and android:access_background_location:allow, you can restrict the background operation:

Run the command:

adb shell appops set com.example.fitness android:access_background_location ignore

Verify the change:
```
adb shell appops get com.example.fitness | grep background_location
```
You should now see android:access_background_location:ignore.

After the change, the app can still request GPS while you are actively using it, but Android will refuse background location updates. Most modern apps respect this mode and stop tracking when you close the UI.

Batch editing multiple ops

When you need to adjust several permissions for the same app, typing each set command can be tedious. You can feed a list of commands to adb shell via a script file.

Step 5 – Create a batch file (optional)

On your computer, create a text file named ops.txt with one command per line, for example:

appops set com.example.fitness android:access_background_location ignore
appops set com.example.fitness android:camera ignore
appops set com.example.fitness android:record_audio ignore

Then push and execute it:

adb push ops.txt /data/local/tmp/
adb shell sh /data/local/tmp/ops.txt

Because the file runs in the shell user context, no additional permissions are required.

Verifying the effect in the UI

After you modify App Ops, the public Settings screen may still show the permission as “Allowed”. This is expected – the UI reflects the public permission state, not the hidden App Ops entry. To confirm the change:

Open the app and try the feature you just blocked (e.g., take a photo). The app should show an error or fallback UI.
Run adb logcat while reproducing the action. Look for messages like Permission denial: opening camera.

If the app crashes, you have likely blocked a mandatory operation. In that case, revert the change using the same set command with allow as the mode.

Reverting changes safely

Because App Ops changes are per‑package, you can always reset them to the system default. The simplest method is to use the reset sub‑command, which clears all custom entries for the package.

Step 6 – Reset all App Ops for a package

adb shell appops reset com.example.fitness

After resetting, the app will behave exactly as if you never touched its permissions. This is handy for troubleshooting or when you want to start fresh.

Common pitfalls and troubleshooting

Even though the commands are straightforward, a few things often trip users up.

Operation name typo: App Ops uses exact operation identifiers (e.g., android:camera, not just camera). A misspelled name results in Unknown operation and no change.
Package name mismatch: Some apps have multiple packages (e.g., a base package and a split‑APK). Use adb shell pm list packages -f to see the full list and target the correct one.
Permission revocation causing app crash: If an app expects a permission at launch (e.g., READ_PHONE_STATE) and you set it to ignore, the app may immediately crash. In such cases, revert to allow or use foreground if the app only needs it while visible.
Device‑specific restrictions: Some OEM skins (e.g., Samsung One UI) add extra layers that re‑apply default permissions after a reboot. If your changes disappear, run the set command again after a reboot, or create a small adb script that runs automatically using adb shell on startup (requires a custom launcher or Tasker).

Safety warnings

Changing App Ops does not require root, but it does affect app functionality. Blocking a core operation may render an app unusable, cause loss of data (e.g., blocking WRITE_CONTACTS while an import runs), or break system services that rely on that app. Always test changes on a non‑critical app first, and keep a note of the original mode so you can revert quickly.

Advanced use cases

Beyond simple permission toggling, App Ops can help developers and power users in more sophisticated ways.

1. Simulating a permission‑denied environment for testing

If you are an Android developer, you can use App Ops to emulate a user who has denied a permission without reinstalling the app. Set the desired operation to ignore, launch the app, and observe how it handles the denial. This is faster than rebuilding the APK with different targetSdkVersion settings.

2. Auditing hidden permissions

Run adb shell appops query-op to list all operations that have been explicitly set for any app. This can reveal cases where an app silently gained a privileged operation through a system update.

3. Combining with `pm grant/revoke`

Android 6.0+ also provides pm grant and pm revoke for runtime permissions. In practice, you may need to use both tools: pm revoke changes the public UI state, while appops set fine‑tunes the underlying operation. For example:

# Revoke the public camera permission
adb shell pm revoke com.example.camera android.permission.CAMERA
# Then ensure background camera usage stays blocked
adb shell appops set com.example.camera android:camera ignore

Putting it all together – a complete workflow

Below is a concise checklist you can follow whenever you want to audit or adjust an app’s permissions using App Ops.

Identify the target app: Get the package name with adb shell pm list packages | grep -i keyword.
Export current ops: adb shell appops get PACKAGE > ops_before.txt for later reference.
Decide which operation to change: Use adb shell appops get PACKAGE | grep op_name to view the current mode.
Apply the change: adb shell appops set PACKAGE OPERATION MODE.
Verify: Re‑run the get command and test the app’s behavior.
Document: Append the new state to ops_after.txt and note why you made the change.
Revert if needed: Use adb shell appops reset PACKAGE or set the operation back to allow.

This systematic approach reduces the chance of accidental lock‑outs and gives you a clear audit trail.

When to avoid App Ops

App Ops is a powerful tool, but it is not a substitute for proper privacy settings on newer Android versions. Starting with Android 10, many permissions are already scoped (e.g., ACCESS_BACKGROUND_LOCATION) and can be toggled directly in Settings. Use App Ops when:

You need to control a permission that the UI hides.
You are testing an app’s fallback behavior.
You have an older device (Android 6–9) where the UI is limited.

Otherwise, stick to the standard Settings UI – it is less error‑prone and integrates with Google’s permission auto‑reset features.

Summary

By leveraging the hidden appops binary via ADB, you gain fine‑grained control over every permission an Android app can request. The workflow is straightforward: connect, identify the package, read the current ops, modify the desired operation, and verify. With the safety precautions and troubleshooting tips provided, you can experiment confidently without rooting your device.

Feel free to bookmark this guide, adapt the batch script for your favorite apps, and share your findings with the Appitika community – precise permission control is a cornerstone of Android privacy, and mastering App Ops puts that power directly in your hands.

User Comments (0)

Add Comment

No comments added yet.

Add Comment

Your Name: *

Comment Title: *

Your E-mail: * We'll never share your email with anyone else.

Your Comment: *

Comments will not be approved to be posted if they are SPAM, abusive, off-topic, use profanity, contain a personal attack, or promote hate of any kind.