咱們熟知的camera架構是下面這張圖:android
底層是camera driver,和硬件強相關;camera driver上層是操做驅動的camera HAL層,這也是各家廠商camera的核心代碼,廠商封裝好本身的代碼,沒必要遵照開源條件,camera HAL層也是修改優化的重點,這一塊是跑在camera provider進程中的,下面會詳細分析一下。camera service是camera provider和上層通訊的橋樑,只是做爲一箇中間層。camera framework是開發者熟知的調用接口。c++
camera架構 (1).jpgcookie
camera framework和camera service層你們可能都比較熟悉,可是camera provider,就是咱們熟知的Camera HAL層,這一塊咱們還不是很清楚。咱們本文主要就是想幫助你們理解清楚camera service與camera provider之間的聯繫。數據結構
前面已經講了不少camera framework與camera service之間的調用聯繫和相互關係,這兒不展開描述了,camera HAL層一直比較神祕,由於google真是爲了保證各家廠商能夠完整保護本身的硬件源碼,纔在camera driver基礎上搞了一個camera HAL,便於各家廠商封裝本身的接口,因此各家廠商的camera HAL層實際上是不開源的,這也是各家廠商camera優化的重點。架構
就像aidl是framework和service之間IPC的通訊方式,實際上經過Binder IPC,camera provider與camera service之間的通訊也會藉助一個載體hal ----> hardware abstract layer(硬件抽象層)。ide
下面看下具體的hal代碼例子。函數
image.png優化
編譯的時候會自動生成 .h 文件,這個裏面包含的接口能夠保證camera provider與 camera service直接通訊調用。ui
./out/soong/.intermediates/hardware/interfaces/camera/provider/2.4/android.hardware.camera.provider@2.4_genc++_headers/gen/android/hardware/camera/provider/2.4/ICameraProvider.h
./out/soong/.intermediates/hardware/interfaces/camera/provider/2.4/android.hardware.camera.provider@2.4_genc++_headers/gen/android/hardware/camera/provider/2.4/ICameraProviderCallback.hthis
言歸正傳,咱們知道camera provider主要處理 camera HAL的功能,camera service要和camera provider通訊,也是跨進程調用,原理和aidl相似的,也是須要註冊service的。具體的註冊過程以下:
下圖反映了cameraprovider啓動的時候,共註冊了兩個provider,一個名爲 legacy/0 ,另外一個是 external/0
camera provider註冊流程.jpg
具體的註冊過程你們能夠根據我上面圖提示的代碼路徑去看一下,這兒不贅述了。
camera provider註冊的地方已經知道,有註冊確定有調用,調用的地方就在camera service,爲了方便你們的理解,直接貼上一張時序圖,你們能夠對照代碼本身看看。
camera provider調用流程.jpg
從上面的調用流程來看,cameraservice初始化的時候,也會創建camera service和camera provider之間的聯繫,將創建的providerInfo放在內存中,以後直接取內存中的providerInfo,能夠從camera service調用到camera provider了。
可是這兒我仍是要講一講具體的聯繫過程:
status_t CameraProviderManager::initialize(wp<CameraProviderManager::StatusListener> listener, ServiceInteractionProxy* proxy) { std::lock_guard<std::mutex> lock(mInterfaceMutex); if (proxy == nullptr) { ALOGE("%s: No valid service interaction proxy provided", __FUNCTION__); return BAD_VALUE; } mListener = listener; mServiceProxy = proxy; // Registering will trigger notifications for all already-known providers bool success = mServiceProxy->registerForNotifications( /* instance name, empty means no filter */ "", this); if (!success) { ALOGE("%s: Unable to register with hardware service manager for notifications " "about camera providers", __FUNCTION__); return INVALID_OPERATION; } // See if there's a passthrough HAL, but let's not complain if there's not addProviderLocked(kLegacyProviderName, /*expected*/ false); addProviderLocked(kExternalProviderName, /*expected*/ false); return OK; }
上面是CameraProviderManager的初始化過程,CameraProviderManager就是管理camera Service與camera provider之間通訊的工程管理類,兩個參數,其中第二個參數就是遠程代理類。這個參數已是默認賦值了。不信能夠看下CameraProviderManager::initialize的定義。
status_t initialize(wp<StatusListener> listener, ServiceInteractionProxy *proxy = &sHardwareServiceInteractionProxy);
這是定義,默認值就是 ----> sHardwareServiceInteractionProxy,這個sHardwareServiceInteractionProxy是 ----> HardwareServiceInteractionProxy 的實例,能夠看出在HardwareServiceInteractionProxy定義中,已經直接調用了ICameraProvider--->getService(...)了。
// Standard use case - call into the normal generated static methods which invoke // the real hardware service manager struct HardwareServiceInteractionProxy : public ServiceInteractionProxy { virtual bool registerForNotifications( const std::string &serviceName, const sp<hidl::manager::V1_0::IServiceNotification> ¬ification) override { return hardware::camera::provider::V2_4::ICameraProvider::registerForNotifications( serviceName, notification); } virtual sp<hardware::camera::provider::V2_4::ICameraProvider> getService( const std::string &serviceName) override { return hardware::camera::provider::V2_4::ICameraProvider::getService(serviceName); } };
CameraProviderManager::initialize 中加入了兩個ProviderName,就是咱們camera provider的兩個service name -----> (legacy/0 extrenal/0)
addProviderLocked(kLegacyProviderName, /expected/ false);
addProviderLocked(kExternalProviderName, /expected/ false);
這兒就實現了camera service與camera provider的橋接了。
CameraProviderManager中提供了一個ProviderInfo來保存Camera provider信息,方便管理camera service調用 camera provider,下面分析一下ProviderInfo是怎麼樣的?方便咱們接下來從這個爲切入掉分析camera provider裏面代碼。
struct ProviderInfo : virtual public hardware::camera::provider::V2_4::ICameraProviderCallback, virtual public hardware::hidl_death_recipient { const std::string mProviderName; const sp<hardware::camera::provider::V2_4::ICameraProvider> mInterface; ProviderInfo(const std::string &providerName, sp<hardware::camera::provider::V2_4::ICameraProvider>& interface, CameraProviderManager *manager); status_t initialize(); status_t addDevice(const std::string& name, hardware::camera::common::V1_0::CameraDeviceStatus initialStatus = hardware::camera::common::V1_0::CameraDeviceStatus::PRESENT, /*out*/ std::string *parsedId = nullptr); // ICameraProviderCallbacks interface - these lock the parent mInterfaceMutex virtual hardware::Return<void> cameraDeviceStatusChange( const hardware::hidl_string& cameraDeviceName, hardware::camera::common::V1_0::CameraDeviceStatus newStatus) override; virtual hardware::Return<void> torchModeStatusChange( const hardware::hidl_string& cameraDeviceName, hardware::camera::common::V1_0::TorchModeStatus newStatus) override; // hidl_death_recipient interface - this locks the parent mInterfaceMutex virtual void serviceDied(uint64_t cookie, const wp<hidl::base::V1_0::IBase>& who) override; //...... };
ProviderInfo繼承了 hardware::camera::provider::V2_4::ICameraProviderCallback 與 hardware::hidl_death_recipient,其中ProviderInfo 第 2個參數就是camera service與cameraprovider通訊的IPC接口,保證兩層能夠順利通訊。
ICameraProviderCallback 是 camera provider的 回調接口,也是能夠IPC間通訊的,hardware::hidl_death_recipient 是hal層的死亡回調接口,方便在底層死亡的時候通知上層。
initialize() ----> initialize 函數的主要做用是初始化camera provider,而且IPC調用到camera provider 獲取camera device信息,而後調用 addDevice接口將獲取的camera device保存在內存中。
addDevice ----> 將底層獲取的camera device信息保存在camera service中,防止屢次跨進程調用。
cameraDeviceStatusChange 與 torchModeStatusChange 都是 ICameraProviderCallback 的回調函數,當camera provider發生變化的時候須要通知上層這些變化。
serviceDied 是 hardware::hidl_death_recipient 的回調函數,當底層發生問題的時候會通知上層變化。
咱們在camera service中就是使用 ProviderInfo 來和底層的camera provider通訊,保存camera device順利運行。
ProviderInfo中還有幾個DeviceInfo類型的數據結構,可是最新的都是採用了DeviceInfo3數據結構,因此這裏只關注DeviceInfo3
// HALv3-specific camera fields, including the actual device interface struct DeviceInfo3 : public DeviceInfo { typedef hardware::camera::device::V3_2::ICameraDevice InterfaceT; const sp<InterfaceT> mInterface; virtual status_t setTorchMode(bool enabled) override; virtual status_t getCameraInfo(hardware::CameraInfo *info) const override; virtual bool isAPI1Compatible() const override; virtual status_t dumpState(int fd) const override; virtual status_t getCameraCharacteristics( CameraMetadata *characteristics) const override; DeviceInfo3(const std::string& name, const metadata_vendor_id_t tagId, const std::string &id, uint16_t minorVersion, const hardware::camera::common::V1_0::CameraResourceCost& resourceCost, sp<InterfaceT> interface); virtual ~DeviceInfo3(); private: CameraMetadata mCameraCharacteristics; };
DeviceInfo3中定義的InterfaceT 是 hardware::camera::device::V3_2::ICameraDevice 類型。
./hardware/interfaces/camera/device/3.2/ICameraDevice.hal ----> ./out/soong/.intermediates/hardware/interfaces/camera/device/3.2/android.hardware.camera.device@3.2_genc++_headers/gen/android/hardware/camera/device/3.2/ICameraDevice.h
操做底層camera device硬件就是經過這個接口調用的。