多Camera HAL配置与兼容性调试全流程 - 第1节

1.1 多摄像头手机发展史

多摄像头系统并非一蹴而就,其演进经历了从“单摄补全”到“多摄融合”的四个关键阶段。理解这段历史有助于把握当前 HAL 层设计的核心矛盾——硬件异构性与软件统一抽象之间的平衡。

阶段 时间 代表机型 核心驱动力 HAL 层挑战
萌芽期 2011–2013 HTC EVO 3D、LG Optimus 3D 3D 拍摄、景深辅助 双 Sensor 独立流,无同步需求
爆发期 2016–2018 iPhone 7 Plus、华为 P9 双摄变焦、人像虚化 主副 Sensor 同步、FOV 对齐
普及期 2019–2021 华为 P30 Pro、小米 10 Ultra 超广角 + 长焦 + 微距 多路 MIPI 复用、Camera ID 映射
融合期 2022–至今 小米 13 Ultra、vivo X100 Pro 计算摄影、多摄融合 RAW 多 Sensor 同时 Streaming、HAL 级融合
关键洞察: 从“物理多摄”到“逻辑多摄”的转变,是 HAL 层从 camera_module_t 单设备模型向 camera_device_t 多设备组模型演进的根本原因。

1.2 多 Camera 核心应用场景

多摄像头系统在用户侧主要解决三个核心问题:变焦连续性、景深可控性、视场角覆盖。每个场景对 HAL 层的同步精度、数据流拓扑、ISP 管线配置都有不同要求。

1.2.1 变焦(Zoom)

  • 光学变焦 vs 混合变焦: 光学变焦依赖物理镜头移动(潜望式),混合变焦通过多摄融合实现 2x–10x 无损裁切。
  • HAL 关键点: 变焦过程中需要动态切换 activeArraySize 和 sensorCropRegion,同时保持 AE/AWB 平滑过渡。
  • 典型配置: 广角(0.6x)+ 主摄(1x)+ 长焦(3x)+ 潜望(5x/10x)。

1.2.2 虚化(Bokeh / Portrait)

  • 双摄虚化原理: 主摄 + 景深/副摄,通过视差计算深度图,再对背景做高斯模糊或散景模拟。
  • HAL 关键点: 需要双路 SYNC_SENSOR 同步,且副摄通常只输出 YUV(不参与 ISP 全流程)。
  • 避坑提示: 副摄分辨率过低会导致深度图边缘锯齿,HAL 层需做 depthMap 上采样。

1.2.3 广角(Ultra-Wide)

  • 视场角覆盖: 超广角通常 120°–130°,主摄 80°–90°,长焦 30°–50°。
  • HAL 关键点: 超广角镜头畸变校正(distortionCorrection)必须在 HAL 层完成,否则会影响多摄融合对齐。
  • 典型问题: 超广角与主摄之间的色温差异(CCT Shift)需要 HAL 层做白平衡补偿。
调试建议: 在 camera_metadata 中检查 ANDROID_LENS_DISTORTION 和 ANDROID_SENSOR_INFO_PHYSICAL_SIZE,这两个 tag 是判断多摄对齐精度的基础。

1.3 多 Camera HAL 架构概览

Android 多 Camera HAL 架构自 Treble 项目后经历了重大重构。当前主流方案基于 HIDL HAL 3.x 或 AIDL HAL,核心设计模式为 Camera Provider + Camera Device 两级模型。

多 Camera HAL 架构概览图 多 Camera HAL 架构概览(HIDL / AIDL 模型) Android Framework (Camera2 API) Camera Service (cameraserver) Camera Provider HAL (android.hardware.camera.provider) ICameraProvider :: ICameraDeviceCallback CameraDevice 0 主摄 (IMX989) CameraDevice 1 超广角 (IMX858) CameraDevice 2 长焦 (OV64B) Kernel V4L2 / MIPI CSI Driver (Sensor + Actuator + OIS) 架构要点: • 每个 CameraDevice 对应一个物理 Sensor,但可通过逻辑 Camera 组合多个 Device。 • Provider 负责枚举设备,Service 负责策略调度,Framework 负责应用交互。

1.3.1 关键 HAL 接口与职责

接口/组件 职责 多摄相关关键方法
ICameraProvider 枚举 Camera 设备、管理设备生命周期 getCameraIdList()、setCallback()
ICameraDevice 单个 Camera 设备的会话管理、流配置 configureStreams()、processCaptureRequest()
ICameraDeviceSession 处理具体的 Capture Request 和 Result processCaptureRequest_3_4()、flush()
CameraMetadata 携带静态/动态参数,多摄对齐依赖此结构 ANDROID_LOGICAL_MULTI_CAMERA_* 系列 Tag

1.3.2 逻辑多摄(Logical Multi-Camera)与物理多摄

Android 10 引入 Logical Multi-Camera 概念,允许将多个物理 CameraDevice 抽象为一个逻辑 Camera 暴露给上层。这是多摄 HAL 配置中最核心的设计模式。

常见陷阱: 逻辑 Camera 的 physicalCameraIds 列表顺序决定了 SYNC_SENSOR 的主从关系。如果主摄不在列表第一位,可能导致 AE/AWB 锁定异常。调试时务必检查 ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS 的排列顺序。

1.3.3 多摄同步机制

多摄 HAL 必须保证多路 Sensor 的 帧级同步,否则融合算法会出现鬼影。同步机制分为硬件级和软件级:

  • 硬件同步(HW SYNC): 通过 Sensor 的 VSYNC 信号共享同一时钟源,精度可达微秒级。需要 SoC 平台支持(如 Qualcomm MDP、MTK Camsys)。
  • 软件同步(SW SYNC): 在 HAL 层通过 processCaptureRequest 的时间戳对齐,精度通常为 1–2 帧延迟。适用于低端平台或非实时场景。
  • 混合同步: 主摄使用 HW SYNC,副摄使用 SW SYNC 回退,通过 ANDROID_SENSOR_TIMESTAMP 做后对齐。
// 多摄同步配置示例(HAL 层 metadata 设置)
// 主摄:硬件同步使能
metadata.update(ANDROID_SYNC_SENSOR, ANDROID_SYNC_SENSOR_HARDWARE);
// 副摄:软件同步使能
metadata.update(ANDROID_SYNC_SENSOR, ANDROID_SYNC_SENSOR_SOFTWARE);
// 逻辑 Camera 同步模式
metadata.update(ANDROID_LOGICAL_MULTI_CAMERA_SYNC_TYPE,
                ANDROID_LOGICAL_MULTI_CAMERA_SYNC_TYPE_CALIBRATED);
调试检查点: 在 dump() 日志中搜索 syncType 和 sensorTimestamp,如果发现两路 Sensor 的 timestamp 差值超过 16ms(1 帧),说明同步失效,需要检查 MIPI CLK 配置或 HAL 层的 waitForFrameSync 实现。