How to Inspect and Control App Operation Permissions on Android Using ADB dumpsys appops

While Android users are familiar with standard runtime permission dialogs—such as prompting to grant Camera or Location access—the operating system enforces these policies through an underlying security subsystem known as Application Operations (AppOps). Unlike binary permissions (which can cause poorly architected applications to crash when access is abruptly denied), AppOps provides granular interception. It can allow, deny, or silently ignore operations (such as feeding blank frames to a camera request or returning empty arrays for clipboard queries) while logging the exact timestamp, duration, and frequency of every hardware sensor access. Using Android Debug Bridge (ADB), developers and privacy auditors can inspect and modify AppOps states directly through dumpsys appops.

Architecture of the Android AppOps Subsystem

The AppOpsService coordinates between the Linux user ID (UID), application packages, and system sensor hardware:

• Operation Codes (OpCodes): Standardized internal operational tokens representing protected hardware and data actions (e.g. COARSE_LOCATION, FINE_LOCATION, RECORD_AUDIO, CAMERA, READ_CLIPBOARD, and RUN_IN_BACKGROUND).
• Mode Flags: Every operation per package exists in one of four operational states:
  • allow: Full, unrestricted access to the hardware or data provider.
  • ignore: Silently suppresses access; the application API call succeeds without error, but returns null, empty, or dummy data.
  • deny: Throws an explicit SecurityException to the calling process.
  • default: Reverts to standard manifest and runtime permission checks.
• Access Telemetry: Tracks access timestamps, active duration in milliseconds, and rejection counts across foreground and background states.

Dumping the Full AppOps State via ADB

To inspect system-wide AppOps tracking data across all installed packages, execute the diagnostic dump command:

# Dump the complete AppOpsService database
adb shell dumpsys appops

Because the output is extensive, filter the dump for a specific application package:

# Inspect AppOps tracking for a specific package (e.g. WhatsApp or Chrome)
adb shell dumpsys appops com.whatsapp

The output reports each operation, its mode, and timestamps of recent invocations:

Uid 10245:
  Package com.whatsapp:
    COARSE_LOCATION: allow; time=+2d14h20m ago; duration=1240ms
    RECORD_AUDIO: allow; time=+1h15m ago; duration=45200ms
    READ_CLIPBOARD: allow; rejectTime=+5h20m ago

Auditing Specific Package Permissions with cmd appops

The Android shell includes a dedicated appops command runner for querying and setting modes without parsing full dumpsys logs:

# Query all custom and default operation modes for a specific app
adb shell cmd appops get com.example.myapp

# Query the status of a single operation (e.g. CAMERA)
adb shell cmd appops get com.example.myapp CAMERA

Modifying Application Operation Modes via ADB

Administrators can override runtime restrictions dynamically without user interaction on the screen:

# Silently ignore camera access for an application without throwing an exception
adb shell cmd appops set com.example.myapp CAMERA ignore

# Silently ignore microphone recording
adb shell cmd appops set com.example.myapp RECORD_AUDIO ignore

# Explicitly grant background execution
adb shell cmd appops set com.example.myapp RUN_IN_BACKGROUND allow

# Revert an operation back to system default behavior
adb shell cmd appops set com.example.myapp CAMERA default

When set to ignore, an application requesting camera frames receives blank black surfaces, protecting user privacy while preventing application crashes.

Auditing Clipboard and Location Snooping

Background clipboard access is a frequent vector for privacy leaks. To determine whether an application has attempted to read the clipboard in the background:

# Check clipboard access timestamps and rejection history
adb shell dumpsys appops | grep -A 5 "READ_CLIPBOARD"

If rejectTime contains recent timestamps, the system successfully thwarted unauthorized background paste attempts.

Resetting AppOps Policies to System Defaults

To purge custom overrides applied during testing and restore standard factory permission handling:

# Reset all AppOps overrides for a specific package
adb shell cmd appops reset com.example.myapp

# Reset AppOps overrides across all packages for the current user
adb shell cmd appops reset --user 0

Troubleshooting Common AppOps Inconsistencies

When diagnosing permission discrepancies on Android devices:

• Permission Granted in Settings but App Fails: Check dumpsys appops. If the runtime permission is granted in the GUI but the AppOps mode is set to ignore or deny, the operation remains blocked at the system server level.
• Background Service Death: If an application stops running when the user switches tasks, inspect RUN_IN_BACKGROUND. If marked as ignore, Android automatically kills background processes spawned by that package.