Android Camera - camera provider启动流程_android.hardware.camera.provider@2.4-service

1.camera provider进程介绍：

其中的pid是736，说明camera provider进程启动的时机比较早，而且权限组是 cameraserver

手机上运行的android.hardware.camera.provider@2.4-service进程是支持camera运行的重要进

程。

上面这张图比较清楚的表现了camera provider进程在camera架构中位置，作为承上启下的部分，

和cameraserver进程和底层的驱动交互，camera provider进程非常重要，camera HAL层几乎全部

运行在camera provider进程中完成。

2.camera provider进程启动流程

首先看下camera provider所在源码中的位置：hardware/interfaces/camera/provider/

接下来看具体的流程：

cameraserver 与 provider 这两个进程启动、初始化的调用逻辑

总体逻辑顺序：

provider 进程启动，注册；

cameraserver 进程启动，注册，初始化；

cameraserver 获取远端 provider（此时实例化 CameraProvider 并初始化）。

上图中，实线箭头是调用关系。左边是 cameraserver 进程中的动作，右边则是 provider 进程中的

动作，它们之间通过 ICameraProvider 联系在了一起，而这个东西与 HIDL 相关，我们可以不用关

心它的实现方式。

由图可见：

cameraserver 一侧，Cameraservice 类依旧是主体。它通过 CameraProviderManager 来管理对

CameraProvider 的操作。此处初始化的最终目的是连接上 CameraProvider。

provider 一侧，最终主体是 CameraProvider。初始化最终目的是得到一个 mModule，通过它可以

直接与 HAL 接口定义层进行交互。

3.CameraProvider的启动与注册 

NO1: 在系统初始化的时候，系统会去运行android.hardware.camera.provider@2.4-service.rc程序

启动Provider进程，并加入HW Service Manager中接受统一管理，在该过程中实例化了一个

LegacyCameraProviderImpl_2_4对象，并在其构造函数中通过hw_get_module标准方法获取HAL

的camera_module_t结构体,并将其存入CameraModule对象中，之后通过调用该camera_modult_t

结构体的init方法初始化HAL Module，紧接着调用其get_number_of_camera方法获取当前HAL支

持的Camera数量，最后通过调用其set_callbacks方法将LegcyCameraProviderImpl_2a_4

（LegcyCameraProviderImpl_2_4继承了camera_modult_callback_t）作为参数传入CamX-CHI

中，接受来自CamX-CHI中的数据以及事件，当这一系列动作完成了之后，Camera Provider进程

便一直便存在于系统中，监听着来自Camera Service的调用。

 NO2: 通过HAL3Module::GetInstance()静态方法实例化了HAL3Module对象，在其构造方法里面通

过HwEnvironment::GetInstance()静态方法又实例化了HwEnvironment对象，在其构造方法中，实

例化了SettingsManager对象，然后又在它构造方法中通过OverrideSettingsFile对象获取了位

于/vendor/etc/camera/camoverridesettings.txt文件中的平台相关的配置信息（通过这种Override机

制方便平台厂商加入自定义配置），该配置文件中，可以加入平台特定的配置项，比如可以通过设

置multiCameraEnable的值来表示当前平台是否支持多摄，或者通过设置overrideLogLevels设置项

来配置CamX-CHI部分的Log输出等级等等。

NO3: 同时在HwEnvironment构造方法中会调用其Initialize方法，在该方法中实例化了

CSLModeManager对象，并通过CSLModeManager提供的接口，获取了所有底层支持的硬件设备

信息，在这个过程中会去打开底层支持的所有子设备，其中包括了Camera Request Manager、

CAPS模块（该驱动模块主要用于CSL获取Camera平台驱动信息，以及IPE/BPS模块的电源控制）

以及Sensor/IPE/Flash等硬件模块，并且通过调用CSLHwInternalProbeSensorHW方法获取了当前

设备安装的Sensor模组信息，并且将获取的信息暂存起来，等待后续阶段使用，总得来说在

HwEnvironment初始化的过程中,通过探测方法获取了所有底层的硬件驱动模块，并将其信息存储

下来供后续阶段使用。

NO4: 之后通过调用HwEnvironment对象中的ProbeChiCompoents方法

在/vendor/lib64/camera/components路径下找寻各个Node生成的So库，并获取Node提供的标准对

外接口，这些Node不但包括CHI部分用户自定义的模块，还包括了CamX部分实现的硬件模块，并

最后都将其都存入ExternalComponentInfo对象中，等待后续阶段使用。

NO5:另外在初始化阶段还有一个比较重要的操作就是CamX 与CHI是通过互相dlopen对方的So

库，获取了对方的入口方法，最后通过彼此的入口方法获取了对方操作方法集合，之后再通过这些

操作方法与对方进行通讯，其主要流程见下图：

 

从上图不难看出，在HAL3Module构造方法中会去通过dlopen方法加载com.qti.chi.override.so库，

并通过dlsym映射出CHI部分的入口方法chi_hal_override_entry，并调用该方法将HAL3Module对

像中的成员变量m_ChiAppCallbacks(CHIAppCallbacks)传入CHI中，其中包含了很多函数指针，

这些函数指针分别对应着CHI部分的操作方法集中的方法，一旦进入到CHI中，就会将CHI本地的

操作方法集合中的函数地址依次赋值给m_ChiAppCallbacks，这样CamX后续就可以通过这个成员

变量调用到CHI中方法，从而保持了与CHI的通讯。

同样地，CHI中的ExtensionModule在初始化的时候，其构造方法中也会通过调用dlopen方法加载

camera.qcom.so库，并将其入口方法ChiEntry通过dlsym映射出来，之后调用该方法，将

g_chiContextOps（ChiContextOps，该结构体中定义了很多指针函数）作为参数传入CamX中，

一旦进入CamX中，便会将本地的操作方法地址依次赋值给g_chiContextOps中的每一个函数指

针，这样CHI之后就可以通过g_chiContextOps访问到CamX方法。