1.camera provider進(jìn)程介紹：

其中的pid是736，說明camera provider進(jìn)程啟動(dòng)的時(shí)機(jī)比較早，而且權(quán)限組是 cameraserver

手機(jī)上運(yùn)行的android.hardware.camera.provider@2.4-service進(jìn)程是支持camera運(yùn)行的重要進(jìn)

程。

上面這張圖比較清楚的表現(xiàn)了camera provider進(jìn)程在camera架構(gòu)中位置，作為承上啟下的部分，

和cameraserver進(jìn)程和底層的驅(qū)動(dòng)交互，camera provider進(jìn)程非常重要，camera HAL層幾乎全部

運(yùn)行在camera provider進(jìn)程中完成。

2.camera provider進(jìn)程啟動(dòng)流程

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

接下來看具體的流程：

cameraserver 與 provider 這兩個(gè)進(jìn)程啟動(dòng)、初始化的調(diào)用邏輯

總體邏輯順序：

provider 進(jìn)程啟動(dòng)，注冊；

cameraserver 進(jìn)程啟動(dòng)，注冊，初始化；

cameraserver 獲取遠(yuǎn)端 provider（此時(shí)實(shí)例化 CameraProvider 并初始化）。

上圖中，實(shí)線箭頭是調(diào)用關(guān)系。左邊是 cameraserver 進(jìn)程中的動(dòng)作，右邊則是 provider 進(jìn)程中的

動(dòng)作，它們之間通過 ICameraProvider 聯(lián)系在了一起，而這個(gè)東西與 HIDL 相關(guān)，我們可以不用關(guān)

心它的實(shí)現(xiàn)方式。

由圖可見：

cameraserver 一側(cè)，Cameraservice 類依舊是主體。它通過 CameraProviderManager 來管理對

CameraProvider 的操作。此處初始化的最終目的是連接上 CameraProvider。

provider 一側(cè)，最終主體是 CameraProvider。初始化最終目的是得到一個(gè) mModule，通過它可以

直接與 HAL 接口定義層進(jìn)行交互。

3.CameraProvider的啟動(dòng)與注冊?

NO1: 在系統(tǒng)初始化的時(shí)候，系統(tǒng)會(huì)去運(yùn)行android.hardware.camera.provider@2.4-service.rc程序

啟動(dòng)Provider進(jìn)程，并加入HW Service Manager中接受統(tǒng)一管理，在該過程中實(shí)例化了一個(gè)

LegacyCameraProviderImpl_2_4對象，并在其構(gòu)造函數(shù)中通過hw_get_module標(biāo)準(zhǔn)方法獲取HAL

的camera_module_t結(jié)構(gòu)體,并將其存入CameraModule對象中，之后通過調(diào)用該camera_modult_t

結(jié)構(gòu)體的init方法初始化HAL Module，緊接著調(diào)用其get_number_of_camera方法獲取當(dāng)前HAL支

持的Camera數(shù)量，最后通過調(diào)用其set_callbacks方法將LegcyCameraProviderImpl_2a_4

（LegcyCameraProviderImpl_2_4繼承了camera_modult_callback_t）作為參數(shù)傳入CamX-CHI

中，接受來自CamX-CHI中的數(shù)據(jù)以及事件，當(dāng)這一系列動(dòng)作完成了之后，Camera Provider進(jìn)程

便一直便存在于系統(tǒng)中，監(jiān)聽著來自Camera Service的調(diào)用。

?NO2:?通過HAL3Module::GetInstance()靜態(tài)方法實(shí)例化了HAL3Module對象，在其構(gòu)造方法里面通

過HwEnvironment::GetInstance()靜態(tài)方法又實(shí)例化了HwEnvironment對象，在其構(gòu)造方法中，實(shí)

例化了SettingsManager對象，然后又在它構(gòu)造方法中通過OverrideSettingsFile對象獲取了位

于/vendor/etc/camera/camoverridesettings.txt文件中的平臺相關(guān)的配置信息（通過這種Override機(jī)

制方便平臺廠商加入自定義配置），該配置文件中，可以加入平臺特定的配置項(xiàng)，比如可以通過設(shè)

置multiCameraEnable的值來表示當(dāng)前平臺是否支持多攝，或者通過設(shè)置overrideLogLevels設(shè)置項(xiàng)

來配置CamX-CHI部分的Log輸出等級等等。

NO3: 同時(shí)在HwEnvironment構(gòu)造方法中會(huì)調(diào)用其Initialize方法，在該方法中實(shí)例化了

CSLModeManager對象，并通過CSLModeManager提供的接口，獲取了所有底層支持的硬件設(shè)備

信息，在這個(gè)過程中會(huì)去打開底層支持的所有子設(shè)備，其中包括了Camera Request Manager、

CAPS模塊（該驅(qū)動(dòng)模塊主要用于CSL獲取Camera平臺驅(qū)動(dòng)信息，以及IPE/BPS模塊的電源控制）

以及Sensor/IPE/Flash等硬件模塊，并且通過調(diào)用CSLHwInternalProbeSensorHW方法獲取了當(dāng)前

設(shè)備安裝的Sensor模組信息，并且將獲取的信息暫存起來，等待后續(xù)階段使用，總得來說在

HwEnvironment初始化的過程中,通過探測方法獲取了所有底層的硬件驅(qū)動(dòng)模塊，并將其信息存儲(chǔ)

下來供后續(xù)階段使用。

NO4:?之后通過調(diào)用HwEnvironment對象中的ProbeChiCompoents方法

在/vendor/lib64/camera/components路徑下找尋各個(gè)Node生成的So庫，并獲取Node提供的標(biāo)準(zhǔn)對

外接口，這些Node不但包括CHI部分用戶自定義的模塊，還包括了CamX部分實(shí)現(xiàn)的硬件模塊，并

最后都將其都存入ExternalComponentInfo對象中，等待后續(xù)階段使用。

NO5:另外在初始化階段還有一個(gè)比較重要的操作就是CamX 與CHI是通過互相dlopen對方的So

庫，獲取了對方的入口方法，最后通過彼此的入口方法獲取了對方操作方法集合，之后再通過這些

操作方法與對方進(jìn)行通訊，其主要流程見下圖：

?

從上圖不難看出，在HAL3Module構(gòu)造方法中會(huì)去通過dlopen方法加載com.qti.chi.override.so庫，

并通過dlsym映射出CHI部分的入口方法chi_hal_override_entry，并調(diào)用該方法將HAL3Module對

像中的成員變量m_ChiAppCallbacks(CHIAppCallbacks)傳入CHI中，其中包含了很多函數(shù)指針，

這些函數(shù)指針分別對應(yīng)著CHI部分的操作方法集中的方法，一旦進(jìn)入到CHI中，就會(huì)將CHI本地的

操作方法集合中的函數(shù)地址依次賦值給m_ChiAppCallbacks，這樣CamX后續(xù)就可以通過這個(gè)成員

變量調(diào)用到CHI中方法，從而保持了與CHI的通訊。

同樣地，CHI中的ExtensionModule在初始化的時(shí)候，其構(gòu)造方法中也會(huì)通過調(diào)用dlopen方法加載

camera.qcom.so庫，并將其入口方法ChiEntry通過dlsym映射出來，之后調(diào)用該方法，將

g_chiContextOps（ChiContextOps，該結(jié)構(gòu)體中定義了很多指針函數(shù)）作為參數(shù)傳入CamX中，

一旦進(jìn)入CamX中，便會(huì)將本地的操作方法地址依次賦值給g_chiContextOps中的每一個(gè)函數(shù)指

針，這樣CHI之后就可以通過g_chiContextOps訪問到CamX方法。

總結(jié)

以上是生活随笔為你收集整理的Camera - camera provider启动流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。