Android HAL3 Open Camera2 流程图

  1. 在 Android O 中,系统启动时,就会启动 CameraProvider 服务。它将 Camera HAL 从 cameraserver 进程中分离出来,作为一个独立进程 android.hardware.camera.provider@2.4-service 来控制 HAL。
    这两个进程之间通过 HIDL 机制进行通信。

这样的改动源自于 Android O 版本加入的 Treble 机制,它的主要功能(如下图所示)是将 service 与 HAL 隔离,以方便 HAL 部分进行独立升级。这其实和 APP 与 Framework 之间的 Binder 机制类似,通过引入一个进程间通信机制而针对不同层级进行解耦(从 Local call 变成了 Remote call)。
在这里插入图片描述

大概总结了一下 cameraserver 与 provider 这两个进程启动、初始化的调用逻辑,如下图。
在这里插入图片描述

  1. 在 Android O 之前,Service 与 HAL 的耦合比较严重,而现在 Google 通过 HIDL 这个进程通信机制将他们分隔成两个进程,这使得 Service 与 HAL 之间的通路建立过程变得复杂了一些。
    本文对 Android O 上,这两个进程的启动与初始化流程进行了简单的分析。总体来说是如下逻辑顺序:

android.hardware.camera.provider@2.4-service 进程启动,仅注册 Provider;
cameraserver 进程启动,实例化 CameraService,并注册到 ServiceManager 中;
由于强指针首次引用,CameraService::onFirstRef() 被调用,相当于进行初始化;
在 CameraService 初始化过程中,通过 CameraProviderManager 来获取已注册的 Provider,并实例化、初始化 CameraProvider;
CameraProvider 初始化过程中,从动态库中加载了 HAL 层的关键结构,并将其封装到 CameraModule 中;
将获取到的 CameraProvider 保存在 ProviderInfo 中,以便后续的使用。
这其实就相当于 Android N 之前,整个 cameraserver 的启动流程。殊途同归,最后都是通过 CameraModule 及其内部的 camera_module_t 连接到 Camera HAL。

  1. Camera HAL3 构建连路的过程,其总体框架可以通过下图直观地感受一下。 
    

红色虚线是上行路线,黑色虚线则是下行路线。
在这里插入图片描述
接下来关于打开相机流程分析的系列文章,都将基于这个总体框架来跟踪代码,分析流程。

总的来说,会分成三大部分来分析:

从 App 连接到 CameraService;
从 CameraService 连接到 HAL Service;
从 HAL Service 连接到 Camera HAL
‘’

从 App 连接到 CameraService;
从 Application 连接到 CameraService,这涉及到 Android 架构中的三个层次:App 层,Framework 层,Runtime 层。
其中,App 层直接调用 Framework 层所封装的方法,而 Framework 层需要通过 Binder 远程调用 Runtime 中 CameraService 的函数。
在这里插入图片描述

1.1 根据流程追踪
我们可以描绘一个比较简单直观的连路框架图,如下。
其中黑色虚线表示下行(控制)路线,红色虚线表明上行(状态、数据)路线
在这里插入图片描述

接下来要分析的是从 CameraService 到 HAL Service 的连接过程。

由于 Android O 中加入了 Treble 机制,它带来的一个巨大变化就是将原本的 CameraServer 进程分隔成 CameraServer 与 Provider service 两个进程,它们之间通过 HIDL(一个类似 Binder 的机制)进行通信。
在这种情况下,CameraServer 一端主体为 CameraService,它将会寻找现存的 Provider service,将其加入到内部的 CameraProviderManager 中进行管理,相关操作都是通过远端调用进行的。
而 Provider service 一端的主体为 CameraProvider,它在初始化时就已经连接到 libhardware 的 Camera HAL 实现层,并以 CameraModule 来进行管理。

这两个进程的启动与初始化是在系统启动时就进行的,相关的分析可以参照我的另一篇博文。
进程的启动后,连路的 “载体” 就搭建完成了(需要注意,此时 QCamera3HWI 还未创建),可用下图简单表示。
在这里插入图片描述
而在打开相机时,该层的完整连路会被创建出来。
这一部分的主要调用逻辑如下图
在这里插入图片描述

2.1
根据流程追踪,我们可以描绘出一个比较简单直观的连路框架图,如下。
在这里插入图片描述

现在需要分析最后的阶段,即从 HAL Service 连接到 Camera HAL 的部分。
现在只需要分析它的构造与初始化部分,
在 HAL3 中,Camera HAL 的接口转化层(以及流解析层)由 QCamera3HardwareInterface 担当,而接口层与实现层与 HAL1 中基本没什么差别,都是在 mm_camera_interface.c 与 mm_camera.c 中。
那么接口转化层的实例是何时创建的,又是怎么初始化的,创建它的时候,与接口层、实现层又有什么交互?通过下图展示的主要调用流程可以简单了解了解。
在这里插入图片描述

在这一部分,连路的最终面貌可以简单地表示如下图。
注意图中的 captureResultCb 相关的内容我并没有分析,这是一个回调函数,应该是在拍照和预览数据上传时用到的,这里提及一下,表明它与 mCallbackOps 有这么一个联系。
在这里插入图片描述

接下来应该只要 APP 按照流程下发 Preview 的 Request 就可以开始获取预览数据了。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页