2. Camera HAL 架构基础：Android Camera HAL3 接口定义、Pipeline 模型、Capture Request 与 Result 流程
2.1 Android Camera HAL3 接口定义
Android Camera HAL3（HAL v3）是 Android 从 Lollipop（API 21）开始引入的下一代相机硬件抽象层接口。与 HAL1 的“黑盒”设计不同，HAL3 将相机传感器、ISP、镜头等硬件能力以 Capability 和 Metadata 的形式暴露给上层框架，使 Camera Service 能够精细控制每一帧的采集与处理参数。
核心设计理念：HAL3 不再提供固定的预览/拍照/录像模式，而是通过
Capture Request 描述“每一帧想要什么”，通过 Capture Result 描述“这一帧实际得到了什么”。这种 Request-Result 模型为 AI 场景识别在 HAL 层的动态调度提供了精确的注入点。
2.2 HAL3 核心接口与数据结构
| 接口/结构体 | 方向 | 关键职责 |
|---|---|---|
camera3_device_t |
Framework → HAL | 设备打开、关闭、初始化操作 |
camera3_callback_ops_t |
HAL → Framework | 通知框架：Buffer 就绪、Result 返回、错误上报 |
camera3_stream_t |
Framework → HAL | 定义数据流类型（预览/拍照/视频）、分辨率、格式 |
camera3_stream_buffer_t |
双向 | 单个 Buffer 的句柄、状态、Fence 同步 |
camera3_capture_request_t |
Framework → HAL | 单帧采集请求：目标流、Metadata、物理 Camera ID |
camera3_capture_result_t |
HAL → Framework | 单帧采集结果：输出 Buffer、Metadata、部分结果标记 |
AI 优化切入点：
camera3_capture_request_t 中的 settings（Metadata）是 AI 场景识别注入 3A 参数、HDR 策略、降噪强度的关键通道。HAL 层可以在 process_capture_request 回调中修改该 Metadata 后再下发到 ISP Pipeline。
2.3 Pipeline 模型：从 Request 到 Result 的流水线
HAL3 的 Pipeline 模型将相机处理链路抽象为一条可配置的流水线。每一帧从 Sensor 曝光开始，经过 ISP、统计引擎、后处理模块，最终输出到指定的 Stream Buffer。Pipeline 的核心特征包括：
- 深度流水线（Deep Pipeline）： 允许同时有多个 Request 在 Pipeline 中处于不同阶段，提高帧率。
- 部分结果（Partial Result）： HAL 可以在 ISP 完成统计后立即返回
Partial Result，框架无需等待全帧处理完成即可开始 3A 计算。 - 同步 Fence： 通过
acquire_fence和release_fence实现 Buffer 的跨硬件同步，避免撕裂。
2.4 Capture Request 与 Result 完整流程
一次完整的 Capture 会话从 Framework 下发 Request 开始，到 HAL 返回 Result 结束。以下是标准流程的 6 个关键步骤：
- Request 下发： Camera Service 调用
process_capture_request()，传入camera3_capture_request_t，包含目标 Stream、Metadata、Input Buffer（若适用）。 - HAL 预处理： HAL 解析 Metadata，根据场景识别结果（如夜景、人像、运动）动态调整 AE/AGC/AWB 目标值、降噪强度、边缘增强参数。
- Sensor 曝光： HAL 驱动 Sensor 按照 Request 中的曝光时间、增益、帧间隔进行曝光，输出 RAW 数据。
- ISP 管线处理： RAW 数据经过黑电平校正、去马赛克、白平衡、颜色校正、Gamma、缩放等模块，输出 YUV/JPEG/HEIC。
- 统计与部分结果： ISP 统计引擎计算 AE/AWB/AF 统计数据，HAL 通过
process_capture_result()返回Partial Result。 - 最终结果返回： 所有输出 Buffer 填充完成，HAL 返回
Final Result，包含完整的 Metadata 和 Buffer 句柄。
AI 调度关键约束：HAL 必须在
process_capture_request() 返回前完成所有 Metadata 修改。一旦 Request 进入 Pipeline，AI 场景识别模块不能再修改该帧的参数。因此，AI 推理必须在 Request 下发前或下发瞬间完成，通常采用“提前一帧推理”策略。
2.5 Request-Result 生命周期与同步模型
| 阶段 | 触发时机 | AI 介入点 |
|---|---|---|
| Request 排队 | Framework 调用 process_capture_request |
AI 场景分类器在此阶段修改 Metadata |
| Sensor 曝光 | HAL 驱动 Sensor 开始曝光 | 无（硬件锁定） |
| ISP 处理 | RAW 数据进入 ISP 管线 | 可注入 ISP 调色 LUT 或降噪强度 |
| 统计返回 | ISP 完成统计计算 | AI 可基于统计结果调整后续 Request |
| Result 返回 | 所有 Buffer 填充完成 | AI 可分析 Result 中的实际参数用于模型更新 |
2.6 HAL3 与 AI 场景识别的接口适配要点
在 HAL 层实现 AI 场景识别调度，需要重点关注以下接口适配：
- Metadata 动态修改： 在
process_capture_request()中，通过ACameraMetadata_copyEntry()读取 Request 中的ANDROID_CONTROL_AE_MODE、ANDROID_CONTROL_AWB_MODE等 Tag，根据 AI 场景分类结果改写后写回。 - Stream 配置协商： 在
configure_streams()阶段，AI 场景识别可以影响 Stream 的分辨率选择（如夜景模式降低分辨率换取信噪比）。 - Partial Result 加速： AI 场景识别模块可以订阅
Partial Result中的统计信息，提前判断场景是否发生变化，避免等待完整帧。 - 错误恢复： 当 AI 注入的参数导致 Sensor 过曝或欠曝时，HAL 需要回退到保守参数，并通过
notify()上报错误。
最佳实践：建议在 HAL 层维护一个 AI 场景状态机，缓存最近 3~5 帧的场景识别结果，避免单帧误判导致参数剧烈抖动。状态机输出稳定的场景标签后，再修改 Metadata 下发到 Pipeline。