相机版本支持

本页详细介绍了 Camera HAL、API 和相关的 Android 兼容性测试套件 (CTS) 测试中的版本差异。还介绍了在 Android 7.0 中为增强和提高相机框架安全性而进行的几项架构更改,以及供应商在其相机实现中为支持这些更改所必须进行的更新。

术语

本页中用到以下术语:

Camera API1
Android 4.4 及更低版本设备上的应用级相机框架,通过 android.hardware.Camera 类提供。
Camera API2
Android 5.0 及更高版本设备上的应用级相机框架,通过 android.hardware.camera2 包提供。
Camera HAL
由 SoC 供应商实现的相机模块层。该应用级公共框架基于 Camera HAL 构建而成。
Camera HAL3.1
随 Android 4.4 发布的相机设备 HAL 版本。
Camera HAL3.2
随 Android 5.0 发布的相机设备 HAL 版本。
Camera API1 CTS
在 Camera API1 之上运行的相机兼容性测试套件 (CTS) 测试集。
Camera API2 CTS
在 Camera API2 之上运行的另一个相机 CTS 测试集。

相机 API

Android 包含以下相机 API。

Camera API1

Android 5.0 已弃用 Camera API1,而且随着新平台开发的重点放在 Camera API2 上,Camera API1 会逐渐被淘汰。但是,该淘汰期限将会很长,而且 Android 版本将会在一段时间内继续支持 Camera API1 应用。具体来说,将继续为以下内容提供支持:

  • 应用的 Camera API1 接口。在 Camera API1 之上构建的相机应用应该与运行早期 Android 版本的设备一样工作。
  • Camera HAL 版本。包括对 Camera HAL1.0 的支持。

Camera API2

Camera API2 框架为应用提供较低级别的相机控件,包括高效的零复制连拍/视频流以及曝光、增益、白平衡增益、颜色转换、去噪、锐化等方面的每帧控件。有关详细信息,请观看 Google I/O 视频概览

Android 5.0 及更高版本包括 Camera API2;但是,运行 Android 5.0 及更高版本的设备可能并非支持所有 Camera API2 功能。应用可以通过 Camera API2 接口查询的 android.info.supportedHardwareLevel 属性会报告以下支持级别之一:

  • LEGACY。这些设备通过 Camera API2 接口为应用提供功能,而且这些功能与通过 Camera API1 接口提供给应用的功能大致相同。旧版框架代码在概念上将 Camera API2 调用转换为 Camera API1 调用;旧版设备不支持 Camera API2 功能,例如每帧控件。
  • FULL。这些设备支持 Camera API2 的所有主要功能,并且必须使用 Camera HAL 3.2 或更高版本以及 Android 5.0 或更高版本。
  • LIMITED。这些设备支持部分(但不是全部)Camera API2 功能,并且必须使用 Camera HAL 3.2 或更高版本。

各项功能通过 Camera API2 接口中的 android.request.availableCapabilities 属性提供。FULL 设备需要 MANUAL_SENSORMANUAL_POST_PROCESSING 等功能。即使对于 FULL 设备,RAW 功能也是可选的。 LIMITED 设备可以播发这些功能的任何子集,包括空子集。但是,必须始终定义 BACKWARD_COMPATIBLE 功能。

设备支持的硬件级别及其支持的特定 Camera API2 功能采用以下功能标记的形式提供,以允许 Google Play 过滤 Camera API2 相机应用。

  • android.hardware.camera.hardware_level.full
  • android.hardware.camera.capability.raw
  • android.hardware.camera.capability.manual_sensor
  • android.hardware.camera.capability.manual_post_processing

CTS 要求

运行 Android 5.0 及更高版本的设备必须通过 Camera API1 CTS、Camera API2 CTS 和 CTS 验证程序相机测试。

不具备 Camera HAL3.2 实现且不能支持完整的 Camera API2 接口的设备仍必须通过 Camera API2 CTS 测试。但是,该设备将在 Camera API2 LEGACY 模式下运行(在该模式下,Camera API2 调用在概念上映射到 Camera API1 调用),因此与 Camera API1 之外的特征或功能相关的任何 Camera API2 CTS 测试都将自动跳过。

在旧版设备上,未跳过的 Camera API2 CTS 测试使用现有的公共 Camera API1 接口和功能,没有新的要求。显示的错误(并导致 Camera API2 CTS 失败)是设备现有 Camera HAL 中已经存在的错误,因此可由现有 Camera API1 应用找到。我们预计不会出现太多此类错误(但是,任何此类错误均必须修复,才能通过 Camera API2 CTS 测试)。

相机框架强化

为了增强媒体和相机框架安全性,Android 7.0 已将相机服务从 mediaserver 中移出。供应商可能需要根据正在使用的 API 和 HAL 版本对 Camera HAL 进行更改。以下部分详细介绍了在 HAL1 和 HAL3 的 AP1 和 AP2 中进行的架构更改,以及常规要求。

API1 的架构更改

API1 视频录制可能会假定相机和视频编码器存在于同一进程中。在以下对象上使用 API1 时:

  • HAL3,其中相机服务使用 BufferQueue 在进程之间传递缓冲区,不需要供应商更新

    HAL3 上 API1 中的 Android 7.0 相机和媒体堆栈

    图 1. HAL3 上 API1 中的 Android 7.0 相机和媒体堆栈。

  • HAL1,支持在视频缓冲区中传递元数据,供应商必须更新 HAL 才能使用 kMetadataBufferTypeNativeHandleSource(Android 7.0 中不再支持 kMetadataBufferTypeCameraSource)。

    HAL1 上 API1 中的 Android 7.0 相机和媒体堆栈

    图 2. HAL1 上 API1 中的 Android 7.0 相机和媒体。

API2 的架构更改

对于 HAL1 或 HAL3 上的 API2,BufferQueue 会传递缓冲区,以便这些路径继续工作。以下对象上用于 API2 的 Android 7.0 架构:

  • HAL1 不受 cameraservice 移动的影响,并且不需要供应商更新
  • HAL3 会受到影响,但不需要供应商更新

    HAL2 上 API2 中的 Android 7.0 相机和媒体堆栈

    图 3. HAL3 上 API2 中的 Android 7.0 相机和媒体堆栈。

其他要求

为增强媒体和相机框架安全性而进行的架构更改包括以下附加设备要求。

  • 常规。由于 IPC,设备需要额外带宽,这可能会影响对时间敏感的相机使用情况,例如高速视频录制。供应商可以通过运行 android.hardware.camera2.cts.PerformanceTest 和 Google 相机应用进行 120/240 FPS 高速视频录制,以衡量实际影响。设备还需要少量额外的 RAM 来创建新进程。
  • 在视频缓冲区中传递元数据(仅限 HAL1)。如果 HAL1 在视频缓冲区中存储元数据而非实际的 YUV 帧数据,则 HAL 必须使用 kMetadataBufferTypeNativeHandleSource 作为元数据缓冲区类型,并在视频缓冲区中传递 VideoNativeHandleMetadatakMetadataBufferTypeCameraSource 在 Android 7.0 中不再受支持)。通过 VideoNativeHandleMetadata,相机和媒体框架能够正确地对原生句柄进行序列化和反序列化,从而在进程之间传递视频缓冲区。
  • 缓冲区句柄地址不一定始终存储相同的缓冲区(仅限 HAL3)。对于每个捕获请求,HAL3 会获取缓冲区句柄的地址。HAL 不能使用地址来识别缓冲区,因为地址可能会在 HAL 返回缓冲区之后存储另一个缓冲区句柄。您必须更新 HAL,以便使用缓冲区句柄来标识缓冲区。例如:HAL 接收缓冲区句柄地址 A,该地址存储缓冲区句柄 A。在 HAL 返回缓冲区句柄 A 之后,缓冲区句柄地址 A 可能在 HAL 下次接收到它时存储缓冲区句柄 B。
  • 更新用于 cameraserver 的 SELinux 策略。如果设备特定的 SELinux 策略向 mediaserver 授予运行相机的权限,则您必须更新 SELinux 策略,以授予 cameraserver 正确的权限。我们建议不要为 cameraserver 复制 mediaserver 的 SELinux 策略(因为 mediaserver 和 cameraserver 通常在系统中需要不同的资源)。Cameraserver 应仅具有执行相机功能所需的权限,并且 mediaserver 中任何不必要的相机相关权限均应被删除。

    验证

    对于包含相机且运行 Android 7.0 的所有设备,请通过运行 Android 7.0 CTS 来验证相关实现。尽管 Android 7.0 不包含验证相机服务更改的新 CTS 测试,但如果您尚未进行上述更新,则现有 CTS 测试将失败。

    Camera HAL 版本历史记录

    有关可用于评估 Android Camera HAL 的测试列表,请参阅 Camera HAL 测试核对清单

    3.4

    对受支持的元数据添加了少许内容并对 data_space 支持进行了更改:

    • 如果支持 RAW_OPAQUE 格式,则必须强制添加 ANDROID_SENSOR_OPAQUE_RAW_SIZE 静态元数据。
    • 如果支持任何 RAW 格式,则必须强制添加 ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE 静态元数据。
    • 使用数据空间编码的版本 0 定义,将 camera3_stream_t data_space 字段切换为更灵活的定义。
    • 可用于 HALv3.2 或更高版本的常规元数据添加项:
      • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
      • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
      • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
      • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
      • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
      • ANDROID_SENSOR_OPAQUE_RAW_SIZE
      • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

    3.3

    扩展功能 HAL 的小修订:

    • OPAQUE 和 YUV 重新处理 API 更新。
    • 对深度输出缓冲区的基本支持。
    • camera3_stream_t 添加了 data_space 字段。
    • camera3_stream_t 添加了旋转字段。
    • camera3_stream_configuration_t 添加了 camera3 流配置操作模式。

    3.2

    扩展功能 HAL 的小修订:

    • 弃用了 get_metadata_vendor_tag_ops。在 camera_common.h 中改用 get_vendor_tag_ops
    • 弃用了 register_stream_buffers。框架在 process_capture_request 中提供给 HAL 的所有 gralloc 缓冲区在任何时候可能都是新的。
    • 添加了部分结果支持。在获得完整结果之前,通过多次调用 process_capture_result 可以获得可用结果的子集。
    • camera3_request_template 添加了手动模板。应用可以使用此模板直接控制捕获设置。
    • 重新制定双向和输入流规范。
    • 更改输入缓冲区返回路径。缓冲区在 process_capture_result 而不是 process_capture_request 中返回。

    3.1

    扩展功能 HAL 的小修订:

    • configure_streams 将消耗方使用标记传递给 HAL。
    • 刷新调用以尽可能快地丢弃所有传输中的请求/缓冲区。

    3.0

    扩展功能 HAL 的首次修订:

    • 重要版本更改,因为 ABI 完全不同。在所需的硬件功能或操作模式方面,与 2.0 相比没有更改。
    • 重新设计了输入请求和流队列接口:框架调用 HAL 且后续请求和流缓冲区已经出队。包含同步框架支持,这是高效实现所必需的。
    • 已将触发器移动到请求中,将大多数通知移动到结果中。
    • 将框架中的所有回调合并到一个结构中,并将所有设置方法合并到单个 initialize() 调用中。
    • 将信息流配置整合到单个调用中,从而简化信息流管理。双向信息流替代 STREAM_FROM_STREAM 构造。
    • 为较旧/受限的硬件设备限制了模式语义。

    2.0

    初始版本的扩展功能 HAL (Android 4.2) [camera2.h]:

    • 足够实现现有 android.hardware.Camera API。
    • 允许用于相机服务层中的 ZSL 队列。
    • 未针对任何新功能(如手动捕获控制、Bayer RAW 捕获,RAW 数据的重新处理等)进行测试。

    1.0

    初始 Android Camera HAL (Android 4.0) [camera.h]:

    • 已从 C++ CameraHardwareInterface 抽象层进行转换。
    • 支持 android.hardware.Camera API。

    相机模块版本历史记录

    本部分基于 camera_module_t.common.module_api_version 提供了相机硬件模块的模块版本控制信息。两个最重要的十六进制数字表示主要版本,而两个最不重要的数字表示次要版本。

    2_4

    此相机模块版本添加了以下 API 更改:

    1. 手电筒模式支持。框架可以为具有闪光灯元件的任何相机设备打开手电筒模式,而无需打开相机设备。相机设备对闪光灯单元的访问优先级高于相机模块;如果已通过模块接口启用手电筒,则打开相机设备会关闭手电筒。当出现任何资源冲突时(例如调用 open() 以打开相机设备),Camera HAL 模块必须通过手电筒模式状态回调通知框架,指明手电筒模式已关闭。
    2. 外部相机(如 USB 热插拔相机)支持。仅当相机已连接且准备好用于外部热插拔相机时,API 更新才会指明相机静态信息可用。当相机状态不是 CAMERA_DEVICE_STATUS_PRESENT 时,获取静态信息的调用将为无效调用。框架仅依赖设备状态更改回调来管理可用的外部相机列表。
    3. 相机仲裁提示。添加了相关支持,以明确指明可以同时打开和使用的相机设备数量。要指定有效的设备组合,应始终在由 get_camera_info 调用返回的 camera_info 结构中设置 resource_costconflicting_devices 字段。
    4. 模块初始化方法。在加载 HAL 模块后由相机服务调用,以允许初始化 HAL 一次。该方法在调用任何其他模块方法之前调用。

    2_3

    该相机模块版本添加了对打开旧版 Camera HAL 设备的支持。如果同一设备可以支持多个设备 API 版本,则框架利用该支持可以打开相机设备作为较低设备 HAL 版本的 HAL 设备。标准硬件模块打开调用 (common.methods->open) 会继续使用支持的最新版本(即 camera_info_t.device_version 中列出的版本)打开相机设备。

    2_2

    该相机模块版本添加了模块供应商标记支持,并且弃用了以前只能通过打开设备才可访问的旧版 vendor_tag_query_ops

    2_1

    该相机模块版本添加了对从 Camera HAL 模块到框架的异步回调支持,利用该支持可以通知框架关于相机模块状态的更改。提供有效 set_callbacks() 方法的模块必须至少报告此版本号。

    2_0

    报告此版本号的相机模块会实现相机模块 HAL 接口的第二个版本。可通过此模块打开的相机设备可能支持 1.0 版本或 2.0 版本的相机设备 HAL 接口。camera_info 的 device_version 字段始终有效;如果 device_version 字段为 2.0 或更高版本,则 camera_infostatic_camera_characteristics 字段有效。

    1_0

    报告这些版本号的相机模块实现了初始相机模块 HAL 接口。可通过此模块打开的所有相机设备仅支持版本 1 的相机设备 HAL。camera_infodevice_versionstatic_camera_characteristics 字段无效。只有 android.hardware.Camera API 受该模块及其设备的支持。