2. Android系统架构基础
Android 并不是一个“单层操作系统”，而是一套自下而上分层、层间通过明确接口通信的软件栈。理解这套分层结构，是后续做安全审计与故障定位的前提：任何一次越权、崩溃、卡顿或数据泄露，最终都能被映射到某一层或某两层之间的边界上。本节从下往上梳理 Linux 内核、HAL、Native 库、ART、Framework 与应用层，并重点标注每层之间的安全边界。
一、分层结构与安全边界总览
Android 的经典分层自底向上为：Linux 内核 → HAL（硬件抽象层）→ Native C/C++ 库与 ART 运行时 → Java API Framework → 系统应用与第三方应用。层与层之间并非“随便调用”，而是由若干条安全边界隔开，这些边界正是审计的关注点。
二、各层职责与关键安全机制
Linux 内核层是 Android 安全的最终执行者。它提供进程隔离、内存管理、文件权限，并承载 Android 特有的 Binder 驱动、Ashmem 匿名共享内存、Wakelock 电源锁等。SELinux 以 LSM 形式挂载在内核中，把“进程能访问哪些资源”从传统的 UID 模型升级为强制访问控制（MAC）。审计时若发现某进程能读取本不该读的文件，往往不是应用代码问题，而是 SELinux 策略或文件标签配置过宽。
HAL 层把硬件差异封装成标准接口。Android 8.0 之后引入 Treble，HAL 通过 HIDL（后续为 AIDL）以独立进程运行，与 Framework 之间通过 Binder 通信。这条边界的安全价值在于：HAL 进程拥有访问硬件节点的权限，而普通应用没有。若 HAL 接口未做调用方校验，应用就可能绕过 Framework 直接操作硬件。
Native 库与 ART 是承上启下的关键。Native 库提供 bionic、libbinder、图形与多媒体能力；ART 负责 DEX 加载、AOT/JIT 编译、GC 与 JNI 桥接。安全审计中，Native 层是内存漏洞（缓冲区溢出、UAF）的高发区，而 ART 层则涉及类加载校验、反射限制与 JNI 引用管理。
Framework 层由 system_server 中的 AMS、PMS、WMS 等系统服务构成，是权限判定与组件调度的中枢。应用通过 Binder IPC 调用这些服务，每次调用都会经过权限检查、AppOps 校验与 SELinux 域检查。这一层是“边界①”的实际执行点。
应用层运行在独立沙箱中，每个应用有唯一 UID，数据目录私有，组件通过 Intent 与 Binder 交互。应用层的安全依赖签名、权限声明与运行时授权。
三、一次跨层调用的完整路径
以“应用拍照”为例，可以清晰看到数据如何穿越各层边界：
- 应用调用 Camera API，请求经 Binder 进入 system_server 的 CameraService；
- CameraService 做权限与 AppOps 检查，确认 CAMERA 权限已授予；
- CameraService 通过 HIDL/AIDL 调用 Camera HAL 进程；
- HAL 进程访问 /dev/video* 等设备节点，由内核驱动完成实际采集；
- 图像数据经 BufferQueue 与 Gralloc 返回，最终由应用渲染。
这条链路上任意一环被绕过，都会形成安全缺口。例如 HAL 接口缺少调用方 UID 校验，或内核设备节点权限为 0666，都会让“权限检查”形同虚设。
四、分层安全边界对照清单
| 边界 | 跨越对象 | 主要机制 | 常见审计点 |
|---|---|---|---|
| ① 应用 ↔ Framework | App → system_server | Binder IPC、Permission、AppOps | 权限绕过、PendingIntent 劫持、导出组件未校验 |
| ② Framework ↔ Native | Java → C/C++ | JNI、引用管理、异常传递 | JNI 局部引用泄漏、类型混淆、未校验输入长度 |
| ③ Native ↔ HAL | Framework → HAL 进程 | HIDL/AIDL、SELinux 标签 | HAL 接口未校验调用方、接口暴露过宽 |
| ④ HAL ↔ 内核 | 用户态 → 内核态 | syscall、设备节点、SELinux LSM | 设备节点权限过宽、ioctl 参数未校验、驱动漏洞 |
五、典型误区与复盘
误区一：把“应用有权限”等同于“操作一定安全”。权限只是第一道门，后面还有 AppOps、SELinux 与 HAL 校验。审计时要逐层确认，而不是只看 Manifest。
误区二：忽略 HAL 与内核之间的边界。很多提权漏洞的根因在设备节点权限或驱动 ioctl 校验缺失，而非应用代码。
误区三：认为 ART 只是“跑 Java 的”。ART 的类加载、反射与 JNI 桥接都是攻击面，尤其是动态加载 DEX 的场景。
定位建议：遇到异常时先判断“问题发生在哪一层”。用 logcat 看 Java 层异常，用 dmesg 看内核与驱动报错，用 dumpsys 看系统服务状态，用 ls -lZ 看文件与 SELinux 标签。分层定位能显著缩短排障时间。
# 查看进程 SELinux 域与 UID
ps -A -Z | grep camera
# 查看设备节点权限与标签
ls -lZ /dev/video*
# 查看内核与驱动层报错
dmesg | grep -i -E "avc|denied|camera"
# 查看系统服务状态
dumpsys media.camera | head -n 40掌握这套分层结构与四条安全边界，后续无论是分析权限提升、定位 Native 崩溃，还是排查 HAL 通信失败，都能快速把现象归位到具体层级，从而选择正确的工具与审计路径。