camera API详细步骤
1. Requests
该应用框架向相机子系统发送了一系列捕获数据请求。每个请求对应着结果中的一个单元，并包含了关于捕获数据与处理流程的所有配置信息。例如：分辨率、像素格式、传感器调节、镜头与闪光灯控制等细节均被包含在内。在这一过程中考虑了大量有关结果数据输出与处理机制的内容，并采用了多线程同步的技术以确保准确性。此外，在这一过程中还实现了多线程同步的技术支持下的一次性多线程同步的数据采集功能，并且整个过程采用非阻塞模式进行操作以减少资源浪费
Figure1. Camera model
2. The HAL and camera subsystem
该相机子系统整合了摄像头流水线上的各组组件的实现工作。如3A算法及其相关处理控制流程也得到了集成实现。其中Hal层则为各组件提供了接口功能。为了保证能够与其他不同品牌相机及图像信号处理器（ISP或 camera sensor）兼容工作,Camera流水线模块被设计成了虚拟化结构，并未直接关联任何真实存在的ISP资源。尽管如此,但其设计与真实处理流水线极为相似,从而允许将其高效映射到硬件架构上。此外,该模块具有高度抽象性特征,无论是在性能表现、质量水平还是跨设备兼容性方面,均无需作出任何性能上的牺牲即可支持多种不同的算法和指令执行。
该摄像头流水线不仅具备触发器支持功能，在应用框架启动时能够初始化并启动相应的摄像头流水线工作流程。例如，在自动完成对焦操作的过程中，默认情况下就能够实现相机设备的启动与配置。当发生自动聚焦异常时，该流水线将向应用框架发送相关错误通知，并根据接收到的信息采取相应的处理措施以恢复正常的图像采集能力。
Figure2. Camera pipeline
请特别注意，在早期版本中，上述图表中的某些图像处理模块的定义不够完善。Camera流水线基于以下假设进行了设计：
·输出的RAW Bayer数据在ISP内部没有经过任何处理；
·生成的统计数据是基于raw sensor的输出数据；
·ISP中，在将raw sensor的输出数据转译为YUV格式的过程中涉及多个不同功能模块，并且这些不同功能模块不遵循明确的操作顺序
虽然呈现了多种尺度变化以及裁剪模式的展示，并且所有缩放操作均共享一个统一的输出区域调节机制（如数字变焦功能）。值得注意的是，在此过程中，并非所有放大操作都采用相同的设置参数——每个模块都可以根据需求独立配置其目标像素尺寸与像素深度设置。
注：数字变焦依据预设倍数，在原始图像中提取相应区域后放大至原分辨率。由于直接采用缩放算法放大处理，则输出图像的质量将有所下降。上图展示了三个缩放/裁剪模块，并共享一个统一的输出控制模块。The application framework layer requires that the topmost scaling module processes raw sensor data for cropping and scaling. The middle module handles YUV data that has undergone ISP processing. The middle module performs cropping and scaling on YUV data before invoking a JPEG encoder to compress it into JPEG format. The lower module performs cropping and scaling on YUV data, delivering outputs at varying resolutions. These three modules have the flexibility to either process or bypass cropping and scaling based on specific requirements.
API使用总结
该应用提供安卓摄像头API使用步骤的简明扼要介绍。参考文档中提供了'Startup and expected operation sequence'这一节的具体内容描述及其实现细节。
1 监听并枚举所有camera设备；
2 打开设备并连接监听器；
3 配置目标用例所需的输出信息（比如静态图片，视频录制等）
4 根据目标用例创建请求；
5 发送或者重复发送这些请求；
6 接收输出的元数据和图像数据；
7 切换用例，则跳转到第3步；
HAL层操作总结
1 Framework层发送捕获数据的异步请求。
HAL层设备必须依次处理请求。对于每个请求而言，HAL层负责输出元数据以及一到多个图像数据。
3 对所有请求与结果而言，均需遵守先进先出的处理方式；该数据流会被后续请求作为数据源使用。
对于同一份请求的所有输出数据的时间戳必须保持一致；这有助于框架层实现同步输出数据的处理
在请求与结果数据总量中，所有被捕获的数据及其相关信息（除3A处理外），均需进行封装处理。
camera API的详细步骤
这段具体说明了如何调用camera API的详细步骤。其中涉及的关键数据结构及其相关函数请参考文件：平台/硬件/libhardware/include/hardware/camera3.h
Framework层调用函数camera_module_t->common.open()后会得到一个hardware_device_t类型的结构体
在框架层通过检查字段hardware_device_t->version的基础上获取该字段的信息后，在此基础上生成一个与当前硬件设备兼容的camera硬件设备句柄。例如当该字段的值为CAMERA_DEVICE_API_VERSION_3_0时，则会生成一个与该硬件设备兼容的camera3_device_t句柄。
该框架层将触发camera3_device_t->ops->initialize()功能，并提供相应的回调指针。该功能仅能执行一次；此外，在执行该操作后，在其他操作之前禁止再次触发。
该层通过调用函数camera3_device_t->ops->configure_streams()向HAL层设备提供了输入/输出流的信息。
5 在框架层初始化grallocbuffer；随后调用camera3_device_t->ops->register_stream_buffers()函数，并确保至少一个configure_streams中的输出流被成功配置。规定同一输出流不得重复注册以避免冲突。
Framework层调用camera3_device_t->ops->construct_default_request_settings()方法获取default settings。该操作可在第三步之后的任何地方执行。
7 首先采用预设配置方案中的一个实例，在框架层级上实现默认设置的配置，并确保已预先注册了一个或多个输出流。
随后生成并发送给 HAL 层的第一个捕获请求。
该请求将由 camera3_device_t 对象的操作流程处理模块执行发送操作。
只有当 HAL 层准备好接收后续的捕获请求时才会阻止当前操作返回。
8 在框架层上会依次提交请求；其中一部分会被用来注册未注册的流；同时也会被用来获取其他测试案例所需的默认设置
在传感器启动曝光过程的瞬间，在执行过程中会触发camera3_callback_ops_t->notify()函数以报告上层SHUTTER事件，并包含该帧号的时间戳。在处理该帧号相关数据之前,HAL层必须发送相应的SHUTTER指令
生产流程持续一段时间后启动使用 camera3_callback_ops_t->process_capture_result() 函数向 framework 层生成并返回处理完成后的图像数据。这些返回的数据保持与提交请求的一致顺序。多个请求可以在同一时间段内一起提交，并受到 camera HAL 层设备生产流程深度的影响。
在执行一段时间后, framework组件可能暂停提交新请求, 并等待所有现有请求完成并返回结果(确保所有缓冲区填满), 然后会再次调用该函数 configure_streams(). 这一操作是为了重新启动cameras的硬件和流水线流程. 前面配置的一些数据流会被重复利用;特别地, 如果这些数据流已经在HAL层次进行了注册, 它们将不再进行额外注册. 如果当前存在一个已被注册的数据输出流, 则framework组件将在第七步处重新开始操作;否则, 将继续执行第五步的操作.
12 在Framework层上实现了一个负责结束camera会话的功能（通过调用函数camera3_device_t->common->close()）。当框架层没有任何其他操作时，在任意时刻都可以执行该操作（尽管此操作可能会阻塞一段时间直至当前所有捕获均完成）。该功能返回后将禁止HAL层对camera3_callback_ops_t类别的任何操作。一旦执行了此功能，则框架层将无法访问任何HAL层级的功能。
当遇到错误或其他异步事件时，在 HAL 层必须通过调用函数 camera3_callback_ops_t->notify() 将相关信息传递给上层系统以供处理。当一个与设备相关的致命错误被通知到上层后，在 HAL 层必须取消或完成所有未结束的数据捕获操作以确保后续处理能够顺利进行。值得注意的是，在通过 notify() 函数传递致命错误信息之前必须先完成相关数据捕获工作；除了类似函数 close() 的行为外，在其他情况下若出现设备异常情况则应返回-ENODEV或者NULL。
整理 转自