【HAL】Framework和HAL之间的起始和基本执行流程

1. Framework调用camera_module_t->common.open()，返回hardware_device_t结构体。
2. Framework检查hardware_device_t->version字段，并为该版本的相机硬件设备实例化相应的句柄。如果是3.0版本，则将hardware_device_t映射为camera3_device_t。
3. Framework入参Framework的回调函数指针调用camera3_device_t->ops->initialize()。仅在open()之后，并且在调用ops结构体中的任何其他函数之前，被调用一次。
4. Framework调用camera3_device_t->ops->configure_streams()，将一串输入/输出stream传入HAL device。
5. 当<=3.1版本：Framework分配gralloc buffer调用camera3_device_t->ops->register_stream_buffers()给至少一个configure_streams罗列的输出stream。相同的stream仅被注册一次。
   当>=3.2版本：camera3_device_t->ops->register_stream_buffers()不被调用必须置为NULL。
6. Framework通过调用camera3_device_t->ops->construct_default_request_settings()请求默认设置给一些use case。这可能在步骤3之后的任何时间发生。
7. Framework构建并发送第一个capture请求给HAL，入参传入其中一组默认设置和至少一个已经被Framework提前注册的输出stream。调用camera3_device_t->ops->process_capture_request()传入HAL。HAL必须阻塞此次调用的返回，直到准备好下一个将被发送的请求。
   当>=3.2版本：传入的camera3_capture_request_t中camera3_stream_buffer_t数组里的buffer_handle_t，可能对于HAL在任何被给新的请求里是全新从未见过的。
8. Framework持续提交请求，并调用construct_default_request_settings去获取其他use case的默认设置buffer。
   <=3.1版本：Framewrok此时可能为尚未注册的stream调用register_stream_buffers。
9. 当请求的capture开始时（sensor开始为这个capture曝光）或者reprocess请求开始执行时，HAL调用camera3_callback_ops_t->notify()发送SHUTTER事件，包括帧号和开始曝光的时间戳。对于reprocess请求，时间戳必须是输入图像的曝光开始，当process_capture_request被调用的时候，可以在camera3_capture_request_t.settings中的android.sensor.timestamp里查找到。
   (1) 当<=3.1版本：对于此帧号的调用，notify调用必须在第一次调用process_capture_result()之前。
   (2) 当>=3.2版本：发送SHUTTER 事件的camera3_callback_ops_t->notify()调用应该尽可能早被执行，因为Framework将无法向应用层提供（此帧的）gralloc buffers，直到拥有有效的曝光起始的时间戳（或者对于reprocess请求的输入图像的曝光起始的时间戳）。
   两者的partial metadata结果和gralloc buffer可能被发送给Framework，在SHUTTER事件之前或之后的任何时间。
10. 在一些pipeline延迟之后，HAL开始返回完成的capture给Framework，通过调用camera3_callback_ops_t->process_capture_result()回调。capture的返回是和请求的提交保持相同的顺序。多个请求可以被同时执行，取决于camera HAL device的pipeline depth。
    当>=3.2版本：
    一旦process_capture_result将buffer作为camera3_stream_buffer_t数组的一部分返回，并且由release_fence指定的fence发送信号（对于-1 fences无操作），该buffer的所有权被认为已转移回Framework。在那之后，HAL必须不再保留那个独有的buffer，Framework可能立刻对它清理内存。
    一帧可能调用process_capture_result多次，每次使用一块新的脱离的metadata，并且/或者 一组gralloc buffer。Framework会将这些部分metadata结果累积为一个结果。
    特别地，为帧N和帧N+1两者同时调用一个process_capture_result是合法的，只要gralloc buffer（输入和输出两者都）符合上述规则。
11. 过一段时间，Framework可能停止提交新的请求，等待现有的capture完成（所有buffer均填满，所有结果均返回），然后再次调用configure_streams()。这将为一组新的输入/输出stream重置camera硬件和pipeline。某些stream可以从以前的配置中重用；如果这些stream的buffer已经在HAL中注册，将不会再被注册。如果至少有一个注册过的stream，则Framework然后将从步骤7继续（否则首先需要执行步骤5）。
12. 或者，Framework可能调用camera3_device_t->common->close()去结束camera session。当Framework中没有其他调用处于活动状态时，可以随时调用此方法，尽管调用可能会阻塞直到所有正在进行的capture已经完成（所有buffer均填满，所有结果均返回）。close调用返回之后，HAL不允许再调用camera3_callback_ops_t函数。一旦close()调用正在进行，Framework不得调用任何其他HAL device的函数。
13. 如果发生错误或其他异步事件，HAL必须调用camera3_callback_ops_t->notify()发送相应的错误/事件信息。在从致命的device范围的通知返回后，HAL应该执行犹如调用了close()一样的行为。但是，HAL必须在调用notify()之前取消或完成所有未解决的capture，这样，一旦使调用notify()发送致命错误，Framework就不会再从device接收到回调。在notify()函数从致命错误消息返回后，除了close()之外的方法应返回-ENODEV或NULL。