嵌入式平台Camera HAL层移植适配与工程案例 - 第1节
1.1 Camera HAL 在 Android 系统中的位置
Camera HAL（Hardware Abstraction Layer）位于 Android 相机框架的中间层，向上对接 Framework 层的 CameraService，向下直接控制硬件驱动。它的核心作用是屏蔽不同 SoC 平台（Qualcomm、MediaTek、Rockchip、Allwinner 等）和 Sensor 模组（OV、Sony、Samsung 等）的硬件差异，为上层提供统一的相机能力接口。
关键位置特征：HAL 是 Android 相机系统中唯一允许由芯片厂商或设备 OEM 修改的标准化层，也是移植适配工作的主要战场。
1.2 HAL 层的作用与设计哲学
核心作用
- 硬件抽象：将不同 Sensor、ISP、Flash、AF 马达的硬件操作封装为标准接口，上层无需关心具体寄存器配置。
- 资源管理：管理 Camera 设备的打开/关闭、Stream 流配置、Buffer 分配与流转、Request 调度。
- 元数据传递：负责将硬件能力（分辨率、帧率、AE/AWB/AF 状态）以标准化的 Camera Metadata 形式上报给 Framework。
- 性能隔离：通过 BufferQueue 和同步机制，隔离应用层与驱动层的时序依赖，避免 UI 卡顿。
设计哲学
| 设计原则 | 说明 |
|---|---|
| 接口标准化 | 所有平台必须实现相同的 HAL 接口（hardware/libhardware/include/hardware/camera.h），上层不感知具体实现。 |
| 性能优先 | HAL 层运行在 Camera 服务进程内，要求零拷贝、低延迟、高吞吐，避免不必要的内存复制。 |
| 可移植性 | HAL 实现应尽量与具体硬件解耦，通过设备树、配置文件或回调机制适配不同 Sensor 和 ISP。 |
| 向后兼容 | HAL1 和 HAL3 接口共存，旧平台可继续使用 HAL1，新平台推荐 HAL3 以获得更优的控制粒度。 |
移植经验：实际项目中，HAL 层 80% 的适配工作集中在 Sensor 驱动适配、ISP tuning 参数加载、以及 Metadata 能力表的正确填充上。
1.3 HAL3 vs HAL1 核心差异
HAL1 是 Android 早期（4.x ~ 7.x）使用的相机 HAL 接口，设计上以“预览-拍照-录像”三个固定 Pipeline 为核心。HAL3 从 Android 5.0 引入，基于 Request-Result 模型，支持更灵活的流配置和更精细的控制。下表从多个维度对比两者的核心差异：
| 对比维度 | HAL1 | HAL3 |
|---|---|---|
| 引入版本 | Android 4.0+ | Android 5.0+ |
| 架构模型 | 固定 Pipeline（预览/拍照/录像三路） | Request-Result 模型，每帧独立配置 |
| 流配置 | 固定 3 路流，不可动态增减 | 支持多路自定义 Stream，可动态配置 |
| 控制粒度 | 粗粒度，只能设置整体模式 | 逐帧控制 AE/AWB/AF、Sensor 参数、ISP 参数 |
| Buffer 管理 | HAL 内部管理 Buffer，上层被动接收 | Framework 通过 BufferQueue 管理，HAL 按需填充 |
| Metadata 传递 | 少量固定参数，通过回调传递 | 完整的 CameraMetadata 结构，双向传递 |
| 多摄像头支持 | 有限，通常只支持主摄 | 原生支持多摄像头、逻辑摄像头、超广角/长焦切换 |
| 移植复杂度 | 较低，适合功能机或低端平台 | 较高，需要实现完整的 Request 调度和 Metadata 处理 |
| 推荐场景 | 低端嵌入式、功能机、Android 7.x 以下 | 中高端嵌入式、AI 相机、多摄、Android 8.0+ |
移植选型建议：对于 Android 8.0 以上的嵌入式平台，即使硬件性能有限，也建议优先实现 HAL3 接口。HAL1 在 Android 10 之后已被标记为 deprecated，Google 不再保证兼容性。如果平台确实无法支持 HAL3 的复杂调度（如无独立 ISP、内存极低），可考虑使用 Camera HAL3 的 backward compatibility 模式，但会损失部分性能。