Camera HAL多路图像流开发与采集链路集成 - 第1节
1.1 Camera HAL 在 Android 相机架构中的位置
Android 相机架构采用分层设计，从上至下依次为 应用层、框架层、HAL 层 和 内核驱动层。Camera HAL（Hardware Abstraction Layer）位于框架层与内核驱动之间，是连接 Android 相机服务与具体硬件传感器的关键桥梁。
架构定位：HAL 层将相机硬件差异封装在统一接口之下，使得上层框架无需关心底层是 Qualcomm、MediaTek、Exynos 还是其他平台的 ISP 实现。
1.2 HAL 层的作用与设计目标
核心作用
- 硬件抽象：将不同厂商、不同型号的摄像头传感器、ISP、闪光灯、对焦马达等硬件差异封装在 HAL 内部，上层通过标准接口调用。
- 资源管理：负责摄像头设备的打开/关闭、Stream 的创建/销毁、Buffer 的分配/回收、请求的排队与调度。
- 元数据传递：将硬件能力（如支持的分辨率、帧率、AE/AWB 范围）以
CameraMetadata形式上报给框架，同时接收框架下发的控制参数。 - 性能与功耗优化：在 HAL 层实现低延迟预览、快速对焦、功耗感知的帧率调节等硬件级优化策略。
设计目标
| 设计目标 | 说明 |
|---|---|
| 接口标准化 | 定义固定的 HAL 接口（HAL1 / HAL3 / HIDL），厂商只需实现接口，无需修改框架代码。 |
| 厂商差异化 | 允许厂商在 HAL 内部集成私有算法（如降噪、HDR、美颜），不暴露给上层。 |
| 向后兼容 | HAL3 设计时保留了 HAL1 的部分语义，便于老设备升级。 |
| 低耦合 | HAL 与框架通过 Binder/HIDL 通信，进程隔离，HAL 崩溃不会直接导致系统重启。 |
| 可测试性 | 提供 Camera HAL Test Harness，支持在无硬件环境下模拟 HAL 行为。 |
实战视角：在嵌入式开发中，HAL 层是调试相机问题最频繁的层次——驱动报错、帧率不足、预览花屏等问题，往往需要从 HAL 日志和 Stream 配置入手定位。
1.3 HAL3 与 HAL1 的主要区别
HAL1 是 Android 4.0 引入的早期相机抽象接口，采用 同步/阻塞 模型，每个操作（预览、拍照、录像）对应独立的函数入口。HAL3 从 Android 5.0 开始成为主流，基于 请求-结果 异步流水线模型，大幅提升了灵活性和性能。
关键差异对比表
| 对比维度 | HAL1 | HAL3 |
|---|---|---|
| 接口模型 | 同步阻塞，函数调用直到完成才返回 | 异步非阻塞，请求提交后立即返回，结果通过回调通知 |
| Stream 支持 | 同一时间只能有一个活跃的 Stream（预览/拍照/录像互斥） | 支持多个 Stream 并发（如同时预览 + 拍照 + 录像） |
| Buffer 管理 | HAL 内部管理 Buffer，框架无法直接操作 | 框架通过 StreamBuffer 机制与 HAL 共享 Buffer，支持零拷贝 |
| 元数据传递 | 通过固定结构体传递，扩展性差 | 使用 CameraMetadata 键值对，支持动态扩展 |
| 3A 控制 | HAL 内部自动完成 AE/AWB/AF，框架干预有限 | 框架可下发精细的 3A 控制参数，支持手动模式 |
| 性能 | 低吞吐，高延迟，适合简单场景 | 高吞吐，低延迟，支持高速连拍和高帧率录像 |
| 适用场景 | 低端设备、功能机、兼容性要求高的场景 | 中高端 Android 设备、多摄像头、计算摄影 |
避坑提示：在 HAL3 开发中，Stream 配置错误（如分辨率不匹配、Format 不支持、Buffer 数量不足）是导致
configureStreams() 返回 -EINVAL 或 -ENODEV 的最常见原因。务必在初始化阶段验证硬件能力列表。
迁移建议
- 新项目：一律使用 HAL3 接口，Android 8.0 之后已废弃 HAL1 的强制支持。
- 老设备升级：如果硬件不支持 HAL3 的异步模型（如老旧 Sensor 无硬件同步能力），可保留 HAL1 兼容层，但框架层会降级使用 Camera1 API。
- 调试工具：使用
dumpsys media.camera查看当前设备使用的 HAL 版本和 Stream 配置状态。