Analysis and Solutions for Android ADB Permission Denied Issues

Problem Phenomenon and Background Analysis

During Android development, developers frequently encounter ADB (Android Debug Bridge) permission denied issues. Specifically, after executing adb shell, any command entered returns a Permission denied error. For example:

D:\android-sdk-windows\platform-tools>adb shell find /data -name *.db
find: permission denied

D:\android-sdk-windows\platform-tools>adb shell test
test: permission denied

D:\android-sdk-windows\platform-tools>adb remount
remount failed: No such file or directory

Permission Mechanism Analysis

The Android system is based on the Linux kernel and employs a strict security sandbox mechanism. Each application runs in an independent user space with a different user ID (UID). When connecting to a device via ADB, the ADB daemon (adbd) runs with restricted user permissions by default and cannot access sensitive system directories such as /data.

This design protects user data and system integrity. System partitions are typically read-only, and while data partitions are writable, regular user permissions cannot access other applications' data directories.

Primary Solution: adb root Command

According to ADB official documentation, the adb root command is the most direct solution. This command restarts the ADB daemon with root permissions. The implementation principle is as follows:

// Restart the adbd daemon
adb root

// Verify root permissions
adb shell whoami
// Output: root

After executing adb root, the ADB daemon runs with superuser privileges, allowing access to all system directories and files. Note that this feature requires the device to be rooted or the "Root access" option in Developer Options to be enabled.

Alternative for Non-Rooted Devices

For non-rooted devices, the run-as command can be used to access specific application data directories. This command allows executing commands as the target application's user:

// Use run-as to access application data
adb exec-out run-as com.yourcompany.app ls -R /data/data/com.yourcompany.app/

The exec-out parameter ensures command output is not processed by the shell, maintaining the original format. Although this method has limited permissions, it meets basic debugging needs.

Device Status Detection and Configuration

Before attempting to resolve permission issues, confirm the device status:

// Check device connection status
adb devices

// Check Developer Options
// 1. Enable Developer Options
// 2. Turn on USB Debugging
// 3. Set Root access to "ADB only" or "Apps and ADB"

If the device is not rooted, try using an emulator for testing, as emulators typically have root permissions by default.

In-Depth Technical Details

The root cause of ADB permission issues lies in Android's security model. The system protects data security through the following mechanisms:

• SELinux Policies: Mandatory access control to restrict process permissions
• File System Permissions: Based on standard Linux rwx permissions
• Application Sandbox: Each application runs in an independent user space

Understanding these mechanisms helps developers better handle permission-related issues.

Best Practice Recommendations

In practical development, follow these best practices:

• Use rooted devices or emulators for deep debugging during development
• Avoid using root permissions in production environments to ensure application security
• Properly use the run-as command to access your own application data
• Regularly check ADB versions and device compatibility

Conclusion

ADB permission denied is a common issue in Android development, which can be quickly resolved using the adb root command. For non-rooted devices, the run-as command provides limited access permissions. Understanding Android's security mechanisms and permission models helps developers debug and develop more effectively.