权限与安全全景：Android 的四层安全模型

一次访问能否成功，可能同时取决于进程 UID、Framework 权限、AppOps 模式、Binder 调用方 身份和 SELinux policy。排障时必须确认拒绝来自哪一层，不能靠放宽其他层掩盖问题。

安全结论来自多层判定

常见误解	正确理解
Android 安全就是运行时权限弹窗	权限只是其中一层，沙箱、SELinux、签名各自独立生效
权限拒绝就是“没点允许”	可能是保护级别、AppOps、SELinux 或调用方身份问题
安全是应用层的事	安全从内核（UID/SELinux）到 Framework（权限/AppOps）贯穿多层

核心结论

1. 应用沙箱：UID + 独立进程 + SELinux 标签，保证“进程间互不干扰”。
2. 权限模型：normal/dangerous/signature/privileged 等保护级别决定授予时机。
3. SELinux：基于安全上下文的强制访问控制，权限模型之外的第二道闸。
4. 签名：识别应用身份，支撑系统应用与签名级权限。
5. 排查安全问题时按“沙箱 → 权限 → SELinux → 签名”逐层检查。

四层模型地图

逐步解释：

1. 沙箱：应用以独立 UID 运行，天然隔离。
2. 权限：声明并授权后才能访问受限资源。
3. AppOps：在权限之上做细粒度开关。
4. SELinux：按标签做强制检查，即使权限通过也可能被拒。
5. 签名：系统应用与特权能力靠身份背书。

常用在哪些地方

按排查频率排列：

1. 权限弹窗与授权：危险权限请求、被拒与重试。
2. 隐私开关：AppOps 对相机、位置、剪贴板的细粒度控制。
3. SELinux 拒绝：avc: denied 日志，系统与应用被拒的常见原因。
4. 系统应用特权：privapp 白名单、平台签名。
5. Binder 安全：服务端校验调用方 UID/PID。

验证与排障

环境：开发设备或模拟器；查看 SELinux 拒绝需要 root。

adb shell dumpsys package <包名> | grep -A20 "runtime permissions"
adb shell dumpsys appops
adb shell su 0 dmesg | grep avc
adb shell getenforce

先看权限授予，再看 AppOps 开关，最后查 SELinux 拒绝。四个状态各查一遍，才能确定 “卡在哪个闸口”。

源码入口

文件	关键位置	作用
ProcessList.java	UID/进程管理	沙箱
PermissionManagerService.java	权限检查	授权
AppOpsManager.java	开关管理	细粒度控制
system/sepolicy/	策略定义	SELinux

公共路径：frameworks/base/services/core/java/com/android/server/、 frameworks/base/core/java/android/app/ 与 system/sepolicy/。行号以 r75 检索为准。

从进程隔离的基础开始，见 应用沙箱。