📚 课程目录第3章 HAL基础概念

3. HAL基础概念

在 Android 系统分层中，HAL（Hardware Abstraction Layer，硬件抽象层）位于系统框架与 Linux 内核之间，是连接“通用 Android 软件”与“具体硬件能力”的关键桥梁。它的核心价值在于：让上层框架不必关心底层芯片、外设、驱动实现差异，只需面向统一接口调用；同时让硬件厂商在相对稳定的边界内实现私有逻辑，降低系统升级与硬件适配的耦合成本。

HAL 的本质不是“驱动”，而是“硬件能力的标准化封装”。驱动运行在内核态，直接操作寄存器与总线；HAL 通常运行在用户态，把驱动能力包装成 Android 框架可调用的接口。

一、HAL 的定义与边界

从工程视角看，HAL 是一组由 Android 定义的接口规范，加上由厂商提供的具体实现。上层通过 CameraService、AudioFlinger、SensorService 等系统服务访问 HAL；HAL 再通过 ioctl、sysfs、netlink、字符设备或厂商私有通道与内核驱动交互。因此，HAL 的边界可以概括为：向上提供稳定接口，向下屏蔽硬件差异。

HAL 模块通常以动态库或独立进程形式存在，具备明确的模块 ID、版本号和接口方法。例如摄像头 HAL 会暴露 open、configure_streams、process_capture_request 等能力；音频 HAL 会暴露 open_output_stream、write、set_parameters 等能力。模块化设计使同一套 Android 框架可以适配不同 SoC 与不同外设。

二、HAL 模块、接口与实现方式

HAL 模块一般由三部分构成：模块描述符、接口方法集和具体实现。模块描述符负责声明模块 ID、版本与入口符号；接口方法集定义上层可调用的函数指针或 Binder 方法；具体实现则完成寄存器配置、数据搬运、状态机控制和错误处理。

HAL 模块：按硬件类别划分，如 Camera HAL、Audio HAL、Sensor HAL、Bluetooth HAL、Graphics HAL 等。
HAL 接口：传统方式多为 C 语言函数指针结构体，Treble 后逐步转为 HIDL/AIDL 接口。
HAL 实现方式：可分为直通式（passthrough）、绑定式（binderized）、以及早期 legacy 实现。

传统 HAL 常见形式是 hw_module_t 与 hw_device_t。厂商实现一个 .so，系统通过 hw_get_module() 加载并调用。Treble 之后，HAL 被拆分为独立进程，通过 Binder 化 IPC 与框架通信，接口由 HIDL 或 AIDL 描述。

// 传统 HAL 模块入口示意
struct camera_module_t HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version = CAMERA_MODULE_API_VERSION_2_4,
        .hal_api_version = HARDWARE_HAL_API_VERSION,
        .id = CAMERA_HARDWARE_MODULE_ID,
        .name = "Vendor Camera HAL",
        .author = "Vendor",
        .methods = &camera_module_methods,
    },
    .get_number_of_cameras = get_number_of_cameras,
    .get_camera_info = get_camera_info,
};

三、传统 HAL 与 Treble HAL 的区别

Android 8.0 引入 Treble 计划，核心目标是把“系统框架”与“厂商实现”解耦，使系统升级不再强依赖厂商 HAL 重编译。传统 HAL 与 Treble HAL 的差异，不只是接口写法变化，更是进程模型、通信机制和升级路径的整体重构。

对比维度	传统 HAL	Treble HAL
运行形态	多为共享库，加载进系统进程	独立 HAL 进程，或直通模式
接口定义	C 结构体函数指针	HIDL / AIDL 接口
通信方式	直接函数调用	Binder IPC / 直通调用
升级影响	框架升级常需厂商同步适配	Vendor 与 System 可独立升级
进程隔离	弱，HAL 崩溃可能拖垮系统进程	强，HAL 进程崩溃影响可控
典型目录	`hardware/libhardware`	`hardware/interfaces`、`vendor/...`

四、典型场景与排障思路

以 Camera 为例，应用调用 CameraManager.openCamera() 后，请求会经过 CameraService，再进入 Camera HAL。若 HAL 进程未启动、接口版本不匹配或权限配置错误，常见日志会出现在 logcat 与 dmesg 中：

adb shell dmesg | grep -i camera
adb logcat | grep -i "CameraHal\|HIDL\|AIDL"
adb shell lshal | grep camera
adb shell dumpsys media.camera

排障时先确认 HAL 服务是否注册，再检查接口版本与 manifest.xml、compatibility_matrix.xml 是否匹配，最后定位驱动节点、权限与时钟、电源域等底层问题。若 HAL 进程反复重启，应优先查看 tombstone 与 SELinux 拒绝日志。

常见误区：把 HAL 当成驱动来写，或在 HAL 中直接操作寄存器。正确做法是让 HAL 聚焦“能力封装与接口适配”，把寄存器、总线、中断等底层细节留在内核驱动中。

五、核心关系图解

下图展示应用、系统服务、HAL 接口、HAL 实现、内核驱动与硬件之间的层次关系，并对比传统 HAL 与 Treble HAL 在进程与通信上的差异。

理解 HAL 的关键，是把它放在“框架—HAL—驱动—硬件”这条链路上看：HAL 既不是纯软件抽象，也不是裸驱动，而是 Android 生态中承上启下的标准化适配层。掌握传统 HAL 与 Treble HAL 的差异，才能理解后续 HIDL、AIDL、VNDK、manifest 与 compatibility matrix 等机制的设计动机。