2. Android系统架构基础

理解 Android 的分层架构，是掌握 HAL 兼容性与 VTS 验证的前提。Android 并不是一个“大单体”，而是由应用框架、系统服务、原生库与运行时、HAL、Linux 内核与驱动自上而下堆叠而成的分层系统。每一层只通过明确定义的接口与相邻层交互，这种“接口契约”正是兼容性测试能够成立的根本原因。

一、五层架构与职责边界

从上层到下层，Android 的典型分层如下：

• 应用层（App）：普通 APK 与系统应用，只依赖 Android SDK 公开 API，不直接接触硬件。
• 应用框架层（Framework）：以 Java/Kotlin 为主，提供 ActivityManager、WindowManager、CameraManager 等 API，是开发者最熟悉的接口面。
• 系统服务与原生层（System Services / Native）：system_server 中的各类 Service、Binder IPC、libbinder、libhardware，以及 ART 运行时。它们把上层请求翻译成对 HAL 的调用。
• HAL 层（Hardware Abstraction Layer）：一组标准化的硬件接口，把“厂商私有实现”封装在统一接口之后，使 Framework 无需关心具体芯片。
• 内核与驱动层（Kernel / Driver）：Linux 内核、设备驱动、设备树，直接操作寄存器、总线和外设。

关键点在于：Framework 不直接调用驱动。上层通过 Binder 进入系统服务，系统服务再通过 HAL 接口访问硬件，HAL 实现最终通过 ioctl、sysfs 或内核子系统与驱动通信。这条链路决定了 HAL 是“承上启下”的枢纽。

二、HAL 在生态中的定位

HAL 的核心价值是解耦。Android 需要支持成百上千种芯片与外设组合，如果 Framework 直接依赖每家厂商的私有驱动接口，系统升级将寸步难行。HAL 通过定义稳定的接口（早期为 HIDL，Android 11 起主推 AIDL），让 Framework 只面向接口编程，厂商只负责实现接口。

因此 HAL 在生态中同时承担三种角色：

1. 对上层是“标准件”：Framework 看到的是一组固定方法、固定参数、固定回调的接口。
2. 对下层是“适配器”：厂商在实现内部自由使用自家驱动、DSP、固件，只要满足接口语义即可。
3. 对测试是“契约面”：VTS 正是围绕 HAL 接口做一致性验证，检查实现是否符合 AOSP 定义的接口规范。

三、一次相机拍照请求的分层流转

以相机拍照为例，可以清晰看到各层如何协作：

App: CameraManager.openCamera() / CaptureRequest
  → Framework: CameraService（system_server 中的系统服务）
    → Binder IPC: 跨进程调用进入 native 层
      → Camera HAL: ICameraDeviceSession::processCaptureRequest()
        → 厂商 HAL 实现: 配置 ISP、Sensor、DMA 通道
          → Kernel Driver: V4L2 / ioctl 操作摄像头硬件
            ← 图像数据经 HAL 回调返回
          ← Framework 封装为 ImageReader 输出
        ← App 收到 onImageAvailable 回调

这条链路中，任何一层接口语义不一致，都会导致拍照失败、花屏或超时。VTS 的相机测试正是针对 HAL 接口的参数合法性、状态机流转和回调时序进行校验。

四、分层职责与验证关注点对照

五、常见误区与复盘