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方法。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。