Unlocking Android’s Sandbox: How UID/GID Permissions Shape App Security

Linux Permission Mechanism

Users have uid, gid, and supplemental gids.

Processes inherit uid, gid, and gids from their owning user; child processes inherit from their parent.

File systems store uid, gid and the classic rwx permission bits.

Android

When you run adb shell, the shell process is started with the "shell" uid (2000). Executing adb shell <command> forks a child process that inherits the same uid/gid as the shell. The id command shows the current user information.

Process details can be inspected via cat /proc/<pid>/status, which displays uid, gid, and groups.

In Android’s file system, each file and directory is created with specific uid, gid, and permission bits, defined in fs_config.c. Directory definitions and file definitions are illustrated below:

Device node uid/gid definitions reside in the various ueventd.*.rc files.

Because Android inherits Linux’s permission model, a process must hold the appropriate uid or gid to access a file.

How to Obtain UID/GID

System Processes : Core services (e.g., servicemanager , vold , surfaceflinger ) are launched by init with uid/gid values taken from their respective .rc files. For example, surfaceflinger.rc defines the uid/gid for the surfaceflinger service.

App Processes : Each installed app receives a unique uid. User and group constants are defined in android_filesystem_config.h . System accounts such as AID_ROOT (0) , AID_SYSTEM (1000) , and AID_SHELL (2000) are reserved, while regular apps get ids above 10000 (e.g., u0_a504 for WeChat). The core permission mapping file is platform.xml , which links each permission to a group (gid). When an app requests a permission in its AndroidManifest , the corresponding gid is added to the app’s process groups, granting the necessary rwx rights.

For example, files under /sdcard belong to the sdcard_rw gid. An app that declares android.permission.WRITE_MEDIA_STORAGE receives this gid, allowing it to read/write those files.

Permission Types

Low‑level unified control: Traditional Linux file permissions (rwx) applied to services that are not Android‑specific (e.g., file access, TCP/IP). Permissions like android.permission.WRITE_MEDIA_STORAGE fall here.

Framework logic control: Most permissions are enforced by the Android framework (AMS, PMS, WMS). The framework scans the manifest, caches granted permissions, and checks them via checkPermission at runtime.

adb shell

Tracing the process chain init → adbd → /system/bin/sh → <command> shows that init runs as root, but adbd deliberately drops its uid to shell (2000). The source code of adbd confirms this uid change.

The framework’s shell package declares almost all permissions, making adb shell the “permission king”. For instance, adb shell pm grant <package> <permission> works because the shell uid holds the hidden android.permission.GRANT_RUNTIME_PERMISSIONS permission, which normal apps lack.

Therefore, developers should leverage adb shell for debugging and permission testing, but attempting to grant permissions from within an app using Runtime.getRuntime().exec("pm grant …") will fail because the app does not possess the required uid.

Runtime.getRuntime().exec("pm grant package_name permission_name");

The key takeaway is that Android’s sandbox, built on Linux uid/gid mechanics, governs every file and process access, and understanding these fundamentals unlocks powerful debugging and security capabilities.