《Android Camera架构》
《Android Camera进程间通信类总结》
《Android Camera模块解析之拍照》
《Android Camera模块解析之视频录制》
《Android Camera原理之CameraDeviceCallbacks回调模块》
《Android Camera原理之openCamera模块(一)》
《Android Camera原理之openCamera模块(二)》
《Android Camera原理之createCaptureSession模块》
《Android Camera原理之setRepeatingRequest与capture模块》
《Android Camera原理之编译》
《Android Camera原理之camera provider启动》
《Android Camera原理之cameraserver与cameraprovider是怎样联系的》
《Android Camera原理之camera service与camera provider session会话与capture request轮转》
《Android Camera原理之camera HAL底层数据结构与类总结》
《Android Camera原理之camera service类与接口关系》
我们熟知的camera架构是下面这张图:
底层是camera driver,和硬件强相关;camera driver上层是操作驱动的camera HAL层,这也是各家厂商camera的核心代码,厂商封装好自己的代码,不必遵守开源条件,camera HAL层也是修改优化的重点,这一块是跑在camera provider进程中的,下面会详细分析一下。camera service是camera provider和上层通信的桥梁,只是作为一个中间层。camera framework是开发者熟知的调用接口。
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(硬件抽象层)。
下面看下具体的hal代码例子。
编译的时候会自动生成 .h 文件,这个里面包含的接口可以保证camera provider与 camera service直接通信调用。
./out/soong/.intermediates/hardware/interfaces/camera/provider/2.4/[email protected]_genc++_headers/gen/android/hardware/camera/provider/2.4/ICameraProvider.h
./out/soong/.intermediates/hardware/interfaces/camera/provider/2.4/[email protected]_genc++_headers/gen/android/hardware/camera/provider/2.4/ICameraProviderCallback.h
言归正传,我们知道camera provider主要处理 camera HAL的功能,camera service要和camera provider通信,也是跨进程调用,原理和aidl类似的,也是需要注册service的。具体的注册过程如下:
下图反映了cameraprovider启动的时候,共注册了两个provider,一个名为 legacy/0 ,另一个是 external/0
具体的注册过程大家可以根据我上面图提示的代码路径去看一下,这儿不赘述了。
2.camera service如何调用camera provider?
camera provider注册的地方已经知道,有注册肯定有调用,调用的地方就在camera service,为了方便大家的理解,直接贴上一张时序图,大家可以对照代码自己看看。
从上面的调用流程来看,cameraservice初始化的时候,也会建立camera service和camera provider之间的联系,将建立的providerInfo放在内存中,之后直接取内存中的providerInfo,可以从camera service调用到camera provider了。
但是这儿我还是要讲一讲具体的联系过程:
status_t CameraProviderManager::initialize(wp listener,
ServiceInteractionProxy* proxy) {
std::lock_guard 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 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
¬ification) override {
return hardware::camera::provider::V2_4::ICameraProvider::registerForNotifications(
serviceName, notification);
}
virtual sp 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 mInterface;
ProviderInfo(const std::string &providerName,
sp& 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 cameraDeviceStatusChange(
const hardware::hidl_string& cameraDeviceName,
hardware::camera::common::V1_0::CameraDeviceStatus newStatus) override;
virtual hardware::Return 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& 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 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 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/[email protected]_genc++_headers/gen/android/hardware/camera/device/3.2/ICameraDevice.h
操作底层camera device硬件就是通过这个接口调用的。
感谢关注公众号JeffMony,持续给你带来音视频方面的知识。