Android Camera原理之cameraserver與cameraprovider是怎樣聯繫的

咱們熟知的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優化的重點。架構

1.camera provider是什麼時候註冊的?

就像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

 

具體的註冊過程你們能夠根據我上面圖提示的代碼路徑去看一下,這兒不贅述了。

2.camera service如何調用camera provider?

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>
            &notification) 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的橋接了。

3.CameraProviderManager→ProviderInfo數據結構

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順利運行。

4.ProviderInfo ----> DeviceInfo3數據結構

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硬件就是經過這個接口調用的。

相關文章
相關標籤/搜索