概述
前言
去年正式进入框架组的时候,啥也不会,瞎jb分析了一通 Android N 上面的 Camera 相关流程。其实基本上都是跟着别人的分析日志看代码,然后按照自己的理解记了些笔记而已。
不过当时感觉受益匪浅,并且后来在项目开发、维护的时候,很多相关的内容都派上了用场。
从正式进入项目到现在大概有 10 个月了吧,其中大概有一半时间在 Android N 上填坑,另一半就是填 Android O 上的坑了(虽然这些坑基本上都是自己人挖的)。现在终于感觉自己对 Android Camera 这块的架构也有一定的认识了。
然而,公司业务要往 HAL3 上迁移了,又要重新开始学习 Camera 流程了……
不过现在的我已经有一定的能力,可以自己跟踪流程去分析了。趁此机会,我就从比较简单的 Camera 服务启动流程开始,锻炼锻炼分析代码、抽象出主干思想的功力吧。
Camera 服务启动流程概览
在 Android O 中,系统启动时,就会启动 CameraProvider 服务。它将 Camera HAL 从 cameraserver
进程中分离出来,作为一个独立进程 android.hardware.camera.provider@2.4-service
来控制 HAL。
这两个进程之间通过 HIDL 机制进行通信。
这样的改动源自于 Android O 版本加入的 Treble 机制,它的主要功能(如下图所示)是将 service 与 HAL 隔离,以方便 HAL 部分进行独立升级。这其实和 APP 与 Framework 之间的 Binder 机制类似,通过引入一个进程间通信机制而针对不同层级进行解耦(从 Local call 变成了 Remote call)。
(这个图是部门里的大佬给的…)
如此一来 Camera 服务的启动流程就变得有些复杂了,但是最核心的部分其实没变,最终都要从动态库中获取连接 HAL 的结构,并保存下来以备未来对 Camera 设备进行操作。
这几天跟了一下代码流程,大概总结了一下 cameraserver 与 provider 这两个进程启动、初始化的调用逻辑,如下图。
总体逻辑顺序:
- provider 进程启动,注册;
- cameraserver 进程启动,注册,初始化;
- cameraserver 获取远端 provider(此时实例化 CameraProvider 并初始化)。
上图中,实线箭头是调用关系。左边是 cameraserver 进程中的动作,右边则是 provider 进程中的动作,它们之间通过 ICameraProvider
联系在了一起,而这个东西与 HIDL 相关,我们可以不用关心它的实现方式。
由图可见:
- cameraserver 一侧,
Cameraservice
类依旧是主体。它通过CameraProviderManager
来管理对CameraProvider
的操作。此处初始化的最终目的是连接上 CameraProvider。 - provider 一侧,最终主体是
CameraProvider
。初始化最终目的是得到一个mModule
,通过它可以直接与 HAL 接口定义层进行交互。
至此,我们就能对 Android O 上的 Camera 服务启动流程有一个大致的了解。但由于我个人功力尚浅,目前只能理解到这个地步,还无法轻易抽象出更容易理解的框架,所以图片中的流程还是比较凌乱的,可能需要对照相应代码才能理解。
下面是我分析代码时的一些笔记,有需要可以对照上图中的流程看看。
CameraProvider 的启动与注册
这个服务进程的启动很简单,主要动作是注册该 CameraProvider,以便 CameraServer 启动时能找到它。需要注意的是,此时 CameraProvider 还未实例化与初始化。
Service.cpp
文件位置:hardwareinterfacescameraprovider2.4default
看代码:
- 第 6 行:与
/dev/vndbinder
进行某种关联,注释表明 Camera HAL 可能会通过它与其它 vendor 组件进行通信。 - 第 7 行:创建默认为直通模式(passthrough)的 CameraProvider 服务实现。
int main()
{
ALOGI("Camera provider Service is starting.");
// The camera HAL may communicate to other vendor components via
// /dev/vndbinder
android::ProcessState::initWithDriver("/dev/vndbinder");
return defaultPassthroughServiceImplementation<ICameraProvider>("legacy/0", /*maxThreads*/ 6);
}
LegacySupport.h
文件路径:systemlibhidltransportincludehidl
该函数做了这些事:
- 第 5 行:配置 RPC 线程池(当前设置最大线程为
6
)。 - 第 6 行:将 Interface(即 CameraProvider)以入参
legacy/0
为名注册到相应的管理服务中。 - 第 12 行:连接到线程池。
template<class Interface>
__attribute__((warn_unused_result))
status_t defaultPassthroughServiceImplementation(std::string name,
size_t maxThreads = 1) {
configureRpcThreadpool(maxThreads, true);
status_t result = registerPassthroughServiceImplementation<Interface>(name);
if (result != OK) {
return result;
}
joinRpcThreadpool();
return 0;
}
CameraService 的启动与初始化
一般来说应该是 Provider 服务先启动,然后 Cameraserver 再启动,并 ”连接“ 到 Provider。
前面已经分析了 Provider 的启动,现在就来看看 Cameraserver 的启动流程。
main_cameraserver.cpp
文件位置:frameworksavcameracameraserver
- 关于线程池配置的部分就忽略吧,主要关注第 11 行,在该进程中实例化了 CameraService。
- 实例化只有简单的一行代码,但实例化的过程并不那么简单。这个
instantiate()
接口并不是定义在 CameraService 类中的,而是定义在 BinderService 类里(而 CameraService 继承了它)。在此处,它的作用是创建一个 CameraService(通过new
的方式),并将其加入到 ServiceManager 中(注意,在这一过程中,CameraService 被强指针引用了)。
int main(int argc __unused, char** argv __unused)
{
signal(SIGPIPE, SIG_IGN);
// Set 3 threads for HIDL calls
hardware::configureRpcThreadpool(3, /*willjoin*/ false);
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
ALOGI("ServiceManager: %p", sm.get());
CameraService::instantiate();
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
CameraService.cpp
文件位置:frameworksavservicescameralibcameraservice
由于首次被强指针引用时,就会调用 onFirstRef()
函数执行初始化之类的业务逻辑,所以现在就看看 CameraService 在此处实现了什么逻辑。
onFirstRef
- 根据 12~ 17 行可以知道,初始化的主要逻辑实现应该在
enumerateProviders()
函数中。 - 而最后在 19 行调用一个 ping 函数,可能是在尝试连接到服务代理吧,不管它。
void CameraService::onFirstRef()
{
ALOGI("CameraService process starting");
BnCameraService::onFirstRef();
// Update battery life tracking if service is restarting
BatteryNotifier& notifier(BatteryNotifier::getInstance());
notifier.noteResetCamera();
notifier.noteResetFlashlight();
status_t res = INVALID_OPERATION;
res = enumerateProviders();
if (res == OK) {
mInitialized = true;
}
CameraService::pingCameraServiceProxy();
}
enumerateProviders
- 函数内容略多,所以只截取需要重点关注的部分。
- 首先将
CameraProviderManager
实例化(第 2 行),然后调用initialize()
接口将其初始化(第 3 行),传入的参数是this
指针,指向当前 CameraService 实例的地址。
if (nullptr == mCameraProviderManager.get()) {
mCameraProviderManager = new CameraProviderManager();
res = mCameraProviderManager->initialize(this);
if (res != OK) {
ALOGE("%s: Unable to initialize camera provider manager: %s (%d)",
__FUNCTION__, strerror(-res), res);
return res;
}
}
CameraProviderManager.cpp
文件位置:frameworksavservicescameralibcameraservicecommon
initialize
在分析具体实现之前,可以先看看它在头文件中的声明:
- 用于初始化管理器,并给它设置一个状态监听(即 CameraService 实例)。选择性地接受一个与服务交互的代理。
- 默认的代理通过 Hardware 服务管理器进行通信。备用的代理可以用来进行测试。代理的生命周期必须要超过管理器的生命周期。
- 注意到在
enumerateProviders
中调用该接口时,只有一个入参,说明当前用的是默认代理。
/**
* Initialize the manager and give it a status listener; optionally accepts a service
* interaction proxy.
*
* The default proxy communicates via the hardware service manager; alternate proxies can be
* used for testing. The lifetime of the proxy must exceed the lifetime of the manager.
*/
status_t initialize(wp<StatusListener> listener,
ServiceInteractionProxy *proxy = &sHardwareServiceInteractionProxy);
接下来看看具体实现的逻辑:
- 第 11~19 行:通过服务代理作出一个注册动作。根据注释,注册会触发一个给所有已知 Provider 进行通知的动作。
- 第 22 行:这是我们主要关注的函数。注释翻译过来是这样,看看这是否为一个直通的 HAL,如果不是也没关系。注意传入的参数
kLegacyProviderName
,在文件开头有它的定义,即为字符串legacy/0
。
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);
return OK;
}
addProviderLocked
这个函数主要作用是将找到的这个 Provider 通过 ProviderInfo
记录下来并初始化。
- 第 2~8 行:检查已知的 Provider 中是否已有名为
legacy/0
的。 - 第 10~21 行:根据
legacy/0
从服务代理处获取 CameraProvider 接口,这里需要特别注意,因为此处真正地初始化了对应的 CameraProvider(怎么就在这初始化了?下一节继续分析)。 - 第 23~28 行:通过
ProviderInfo
来保存当前 Provider 相关信息。 - 第 30 行:记录当前 Provider。
status_t CameraProviderManager::addProviderLocked(const std::string& newProvider, bool expected) {
for (const auto& providerInfo : mProviders) {
if (providerInfo->mProviderName == newProvider) {
ALOGW("%s: Camera provider HAL with name '%s' already registered", __FUNCTION__,
newProvider.c_str());
return ALREADY_EXISTS;
}
}
sp<provider::V2_4::ICameraProvider> interface;
interface = mServiceProxy->getService(newProvider);
if (interface == nullptr) {
if (expected) {
ALOGE("%s: Camera provider HAL '%s' is not actually available", __FUNCTION__,
newProvider.c_str());
return BAD_VALUE;
} else {
return OK;
}
}
sp<ProviderInfo> providerInfo =
new ProviderInfo(newProvider, interface, this);
status_t res = providerInfo->initialize();
if (res != OK) {
return res;
}
mProviders.push_back(providerInfo);
return OK;
}
CameraProvider 的初始化
在 CameraService 的初始化过程中,CameraProvider 才开始进行初始化,只不过这个初始化是通过服务代理进行远端调用而进行的。
在 CameraProviderManager::addProviderLocked
函数的实现逻辑中,调用了 ICameraProvider::getService
接口,该接口最终会调用到一个名为 HIDL_FETCH_ICameraProvider
的函数。
CameraProvider.cpp
文件位置:hardwareinterfacescameraprovider2.4default
HIDL_FETCH_ICameraProvider
若传入的参数是 legacy/0
,则创建一个 CameraProvider
实例(构造函数中调用了它自身的初始化函数)并返回相应指针给函数调用者。
ICameraProvider* HIDL_FETCH_ICameraProvider(const char* name) {
if (strcmp(name, kLegacyProviderName) != 0) {
return nullptr;
}
CameraProvider* provider = new CameraProvider();
if (provider == nullptr) {
ALOGE("%s: cannot allocate camera provider!", __FUNCTION__);
return nullptr;
}
if (provider->isInitFailed()) {
ALOGE("%s: camera provider init failed!", __FUNCTION__);
delete provider;
return nullptr;
}
return provider;
}
initialize
整个函数实现比较冗长,只贴出我们需要关注的部分分析。
- 第 1~7 行:需要注意
rawModule
这个指针指向的结构,通过hw_get_module
函数获取到它的实例(从相应的 Camera HAL 动态库中加载得到)。实际上这个结构就是连接到 HAL 层的关键点,通过它就可以调用到 HAL 中的一些函数。 - (关于
hw_get_module
,我以前分析过 Android N 上相关的逻辑,在 O 上其实没有很大改动,如果要详细了解可以去看看那篇文章) - 第 9~15 行:基于
rawModule
创建CameraModule
实例并初始化。之后都是通过mModule
来对 HAL 进行操作的。(其实CameraModule
是对于camera_module_t
的一层封装,诸如 init、open 这样的操作,实际上都是通过调用camera_module_t
结构中函数指针指向的 HAL 层的具体实现函数来完成的) - 执行完这个函数,
CameraProvider
也就随之初始化完成了。
camera_module_t *rawModule;
int err = hw_get_module(CAMERA_HARDWARE_MODULE_ID,
(const hw_module_t **)&rawModule);
if (err < 0) {
ALOGE("Could not load camera HAL module: %d (%s)", err, strerror(-err));
return true;
}
mModule = new CameraModule(rawModule);
err = mModule->init();
if (err != OK) {
ALOGE("Could not initialize camera HAL module: %d (%s)", err, strerror(-err));
mModule.clear();
return true;
}
ALOGI("Loaded "%s" camera module", mModule->getModuleName());
小结
在 Android O 之前,Service 与 HAL 的耦合比较严重,而现在 Google 通过 HIDL 这个进程通信机制将他们分隔成两个进程,这使得 Service 与 HAL 之间的通路建立过程变得复杂了一些。
本文对 Android O 上,这两个进程的启动与初始化流程进行了简单的分析。总体来说是如下逻辑顺序:
- android.hardware.camera.provider@2.4-service 进程启动,仅注册 Provider;
- cameraserver 进程启动,实例化
CameraService
,并注册到ServiceManager
中; - 由于强指针首次引用,
CameraService::onFirstRef()
被调用,相当于进行初始化; - 在 CameraService 初始化过程中,通过
CameraProviderManager
来获取已注册的 Provider,并实例化、初始化CameraProvider
; - CameraProvider 初始化过程中,从动态库中加载了 HAL 层的关键结构,并将其封装到
CameraModule
中; - 将获取到的 CameraProvider 保存在
ProviderInfo
中,以便后续的使用。
这其实就相当于 Android N 之前,整个 cameraserver 的启动流程。殊途同归,最后都是通过 CameraModule 及其内部的 camera_module_t
连接到 Camera HAL。
最后
以上就是和谐唇膏为你收集整理的[Android O] Camera 服务启动流程简析前言Camera 服务启动流程概览CameraProvider 的启动与注册CameraService 的启动与初始化CameraProvider 的初始化小结的全部内容,希望文章能够帮你解决[Android O] Camera 服务启动流程简析前言Camera 服务启动流程概览CameraProvider 的启动与注册CameraService 的启动与初始化CameraProvider 的初始化小结所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复