Android Framework:Binder(4)-Native Service的注册
一、Native Service注册的概述
Android中很多Service是Native Service，本篇我们挑选Native service中的cameraserver的启动注册来学习Native Service注册涉及的Binder机制。
Native Service在启动后需要通过Binder驱动向ServiceManager进行注册，注册过程即是一次跨进程的操作，Native Service是Client端，ServiceManager是Server端。
1. Native Service注册至ServiceManager示意图：
1.Service启动的时候会去获取ServiceManager的代理实例，即BpServiceManager(BpBinder(0)),通过ServiceManager的代理实例向ServiceManager中注册Service的name和Service实例：通过ioctl()将注册信息写入至binder驱动，由binder驱动通知ServiceManager进程；
2.另一端ServiceManager在系统启动开始初始化时主线程及进入死循环binder_loop，不断的读取binder驱动，查询是否有Client端的请求消息。
2.Binder架构中的重要类
2.1. ServiceManager模块中的Binder类框架：
Binder Native层涉及到的类比较多，关系也很复杂，关于ServiceManager模块的类的结构基本如下：
其中蓝色的框的地方在Android N上的代码中并未实现，Android M及之前的code上还是可以看到部分相关code，但是只是定义未使用。
一般的Native Service端会继承实现了通过BnInterface模板类构造出的IXXXService接口的BnXXXService，通过调用构造出的BBinder的transact方法来实现调用Service端的onTransact()方法来进行Service端的操作。
而ServiceManager进程可以直接与Binder驱动通信，不需要依赖这一套继承体系。 这里将ServiceManger当做一个普通的Server端，以便说明Android中一般情况下的Binder通信架构。
简单说明下：
1.BpInterface和BnInterface其实就是为了连接业务类和Binder类。不同的是BpInterface通过继承BpRefBase来持有一个BpBinder对象，而BnInterface是通过继承的方式来成为一个BBinder对象。BpXXXService和BnXXXService继承 ‘通过BpInterface和BnInterface模板类构造出的IXXXService接口,实现XXXService的业务函数。
2.BpServiceManager，在Client端获取service或者Service在注册时，需要通过ServiceManager的对象去查询，获取或添加service，而Client端获取到的不是ServiceManager的对象而是ServiceManager的对象的代理对象，及BpServiceManager(BpBinder(0))。
3.BpBinder和BBinder继承自IBinder接口，实现与Binder驱动交互的接口。
2.2. Binder通信类ProcessState,IPCThreadState
同一个进程里只有一个ProcessState，ProcessState负责打开Binder驱动，建立IPC线程池，设置进程基本信息。
IPCthreadState负责着Binder的读取，写入和请求处理框架。
二、CameraService的启动初始化
android系统在启动时会去解析各种rc文件，然后做各种操作，比如启动主要的service，我们要分析的cameraserver的rc文件如下：
frameworks\av\camera\cameraserver\cameraserver.rc
service cameraserver /system/bin/cameraserver
class main
user cameraserver
group audio camera input drmrpc
ioprio rt 4
writepid /dev/cpuset/camera-daemon/tasks /dev/stune/top-app/tasks我们知道启动cameraserver时会走入口函数main:
frameworks\av\camera\cameraserver\main_cameraserver.cpp
int main(int argc __unused, char** argv __unused)
{
sp<ProcessState> proc(ProcessState::self());//获得一个ProcessState实例
sp<IServiceManager> sm = defaultServiceManager();//需要得到ServiceManager实例以注册该服务
CameraService::instantiate();//Cameraserver实例化
//线程池管理
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
cameraserver的main函数中主要的初始化流程如下图：
下面我们来详细的看下cameraserver启动时走的流程。
1. 打开Binder驱动中映射一块内存保存进程基本信息
每个进程只有一个ProcessState,如下是ProcessState的单例获取方式：
/frameworks/native/libs/binder/ProcessState.cpp
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState;
return gProcess;
}如果没有gProcess实例则在ProcessState的构造函数中进行构造：
ProcessState::ProcessState()
: mDriverFD(open_driver()) //注意在新建ProcessState时打开了Binder驱动
, mVMStart(MAP_FAILED)//映射内存的起始地址
, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
, mExecutingThreadsCount(0)
//一般进程的最大binder线程数是15，system_server的最大binder线程数是32
, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
, mStarvationStartTimeMs(0)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
if (mDriverFD >= 0) {
// mmap the binder, providing a chunk of virtual address space to receive transactions.
//在binder驱动中进行内存映射，
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
...
}
} 这个构造函数里面调用open_driver()打开了/dev/binder设备驱动文件，返回文件描述符。这样我们就能通过这个mDriverFd来和binder驱动交互了。
open_driver()，获取文件描述符并设置最大binder线程数量：
/frameworks/native/libs/binder/ProcessState.cpp
static int open_driver()
{ //打开binder驱动获得文件描述符,这里及调到上篇文章中说的binder_open的驱动函数了
int fd = open("/dev/binder", O_RDWR | O_CLOEXEC);
if (fd >= 0) {
size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
...
}
...
return fd;
} 小结：
这一步主要就是打开Binder驱动，为该Service的进程在binder驱动中映射一段内存，设置了基本的进程信息；
2. defaultServiceManager获取serviceManager的代理对象
cameraserver初始化需要将自己加到serviceManager的管理list中，因此需要先获取到serviceManager的实例：
sp<IServiceManager> sm = defaultServiceManager(); defaultServiceManager的实现：
frameworks/native/libs/binder/IServiceManager.cpp
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
//获取ServiceManager的代理对象
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
}
}
return gDefaultServiceManager;
}可看到获取servicemanager实例也是通过单例方式获得，第一次获取时是通过下面的方法：
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL)); 这里可以看到是两部分，
2.1.我们先看ProcessState::self()->getContextObject(NULL)做了什么得到什么：
/frameworks/native/libs/binder/ProcessState.cpp
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{
return getStrongProxyForHandle(0);
}传下去的参数handle是0，最终返回了一个BpBinder(0)的对象：
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<IBinder> result;
AutoMutex _l(mLock);
//根据hanle值查找对应的handle实体，若未发现对应实体则会创建一个新的项返回
handle_entry* e = lookupHandleLocked(handle);
if (e != NULL) {
IBinder* b = e->binder;
if (b == NULL || !e->refs->attemptIncWeak(this)) {
...
b = new BpBinder(handle);//这里返回handle为0的BpBinder对象
e->binder = b;
if (b) e->refs = b->getWeakRefs();
result = b;
}
}
return result;
}=================
BpBinder和BBinder的关系：(摘自《深入理解Android卷1-邓凡平》)
BpBinder和BBinder都是从IBinder类中派生而来，如图：
BpBinder是客户端用来与Server交互的代理类，p指proxy的意思;
BBinder则是与proxy相对的一端，是proxy交互的目的端，及代表服务端。这里的BpBinder和BBinder通过handle值是一一对应的.
BpBinder::BpBinder(int32_t handle)
: mHandle(handle)
, mAlive(1)
, mObitsSent(0)
, mObituaries(NULL)
{
ALOGV("Creating BpBinder %p handle %d\n", this, mHandle);
extendObjectLifetime(OBJECT_LIFETIME_WEAK);
IPCThreadState::self()->incWeakHandle(handle);
}================
2.2 模板类的替换
接着看获取ServiceManager实例方法,即这里可以这么替换：
gDefaultServiceManager = interface_cast<IServiceManager>(
new BpBinder(0));这里interface_cast是一个模板函数，定义如下：
/frameworks/native/include/binder/IInterface.h
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}因此这里相当于
inline sp<IServiceManager> interface_cast(const sp<IBinder>& obj)
{
return IServiceManager::asInterface(obj);
}所以我们接着看IServiceManager接口类：
frameworks/native/include/binder/IServiceManager.h
class IServiceManager : public IInterface
{
public:
DECLARE_META_INTERFACE(ServiceManager);//关键的宏
//下面是ServiceManager所提供的业务函数。
//getService是阻塞的，如果不存在的话会阻塞几秒
virtual sp<IBinder> getService( const String16& name) const = 0;
virtual sp<IBinder> checkService( const String16& name) const = 0;//非阻塞的
virtual status_t addService( const String16& name,const sp<IBinder>& service,bool allowIsolated = false) = 0;
virtual Vector<String16> listServices() = 0;
enum {
GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION,
CHECK_SERVICE_TRANSACTION,
ADD_SERVICE_TRANSACTION,
LIST_SERVICES_TRANSACTION,
};
};
sp<IServiceManager> defaultServiceManager();
template<typename INTERFACE>
status_t getService(const String16& name, sp<INTERFACE>* outService)
{
const sp<IServiceManager> sm = defaultServiceManager();
if (sm != NULL) {
*outService = interface_cast<INTERFACE>(sm->getService(name));
if ((*outService) != NULL) return NO_ERROR;
}
return NAME_NOT_FOUND;
}
bool checkCallingPermission(const String16& permission);
bool checkCallingPermission(const String16& permission,
int32_t* outPid, int32_t* outUid);
bool checkPermission(const String16& permission, pid_t pid, uid_t uid);
}; // namespace android
#endif // ANDROID_ISERVICE_MANAGER_H上面关键的宏的定义和实现：
frameworks/native/include/binder/IInterface.h
//宏定义
#define DECLARE_META_INTERFACE(INTERFACE) \
static const android::String16 descriptor; \
static android::sp<I##INTERFACE> asInterface( \
const android::sp<android::IBinder>& obj); \
virtual const android::String16& getInterfaceDescriptor() const; \
I##INTERFACE(); \
virtual ~I##INTERFACE();
//宏实现
#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
const android::String16 I##INTERFACE::descriptor(NAME); \
const android::String16& \
I##INTERFACE::getInterfaceDescriptor() const { \
return I##INTERFACE::descriptor; \
} \
android::sp<I##INTERFACE> I##INTERFACE::asInterface( \
const android::sp<android::IBinder>& obj) \
{ \
android::sp<I##INTERFACE> intr; \
if (obj != NULL) { \
intr = static_cast<I##INTERFACE*>( \
obj->queryLocalInterface( \
I##INTERFACE::descriptor).get()); \
if (intr == NULL) { \
intr = new Bp##INTERFACE(obj); \
} \
} \
return intr; \
} \
I##INTERFACE::I##INTERFACE() { } \
I##INTERFACE::~I##INTERFACE() { } \因此：
gDefaultServiceManager = interface_cast<IServiceManager>(new BpBinder(0));
及可以等价为：
gDefaultServiceManager = IServiceManager::asInterface(BpBinder(0))我们重点看IServiceManager::asInterface(obj);的实现方法，对应函数模板可以同效展开为：
android::sp<IServiceManager> IServiceManager::asInterface(
const android::sp<android::IBinder>& obj)
{
android::sp<IServiceManager> intr;
if (obj != NULL) {
intr = static_cast<IServiceManager*>(
obj->queryLocalInterface(
IServiceManager::descriptor).get());
if (intr == NULL) {
intr = new BpServiceManager(obj);//obj及之前创建的BpBinder(0)
}
}
return intr;
}到这里我们可以看出gDefaultServiceManager被赋值的是一个BpServiceMananger对象，即defaultServiceManager()得到一个BpServiceManager(BpBinder(0))的对象;
BpServiceManager分析：
我们看到BpServiceManager继承自BpInterface的类模,由下面分析BpServiceManager是继承了IServiceManager和BpRefBase接口的，因此BpServiceManager中实现了IServiceManager中的接口函数：
/frameworks/native/libs/binder/IServiceManager.cpp::class BpServiceManager
class BpServiceManager : public BpInterface<IServiceManager>
{
BpServiceManager(const sp<IBinder>& impl):BpInterface<IServiceManager>(impl){}//调用父类的构造函数，传入impl即BpBinder(0)
virtual sp<IBinder> BpServiceManager(const String16& name) {sp<IBinder> svc = checkService(name);return svc;}
virtual sp<IBinder> checkService( const String16& name) {remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply)}
virtual status_t addService(const String16& name,,){remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);}
virtual Vector<String16> listServices() {remote()->transact(LIST_SERVICES_TRANSACTION, data, &reply);}
}父类BpInterface中可以看到BpInterface继承类public INTERFACE, public BpRefBase，替换掉INTERFACE即BpServiceManager继承了两个父类：IServiceManager和BpRefBase：
/frameworks/native/include/binder/IInterface.h :: BpInterface
class BpInterface : public INTERFACE, public BpRefBase
{
public:BpInterface(const sp<IBinder>& remote);
protected:virtual IBinder* onAsBinder();
};
inline BpInterface<INTERFACE>::BpInterface(const sp<IBinder>& remote)
: BpRefBase(remote) //基类的构造函数
{
}BpInterface的实现代码如下：
BpRefBase::BpRefBase(const sp<IBinder>& o)
: mRemote(o.get()), mRefs(NULL), mState(0)
{
extendObjectLifetime(OBJECT_LIFETIME_WEAK);
if (mRemote) {
mRemote->incStrong(this); // Removed on first IncStrong().
mRefs = mRemote->createWeak(this); // Held for our entire lifetime.
}
} 在这里看到BpBinder(0)传递给了BpServiceManager的祖先类对象BpRefBase对象的mRemote变量中。
BpBinderServiceManager小结：
我们通过defaultServiceManager()方法得到得到了BpServiceManager(BpBinder(0))对象,BpServiceManager对象实现了IServiceManager的业务函数，是ServiceManager的代理，通过这个对象我们就可以调用ServiceManager所暴露出来的各个方法,通过BpServiceManager这个代理来转达给ServiceManager。
首先，我们通过ProcessState::self()->getContextObject(NULL)得到了BpBinder(0)对象。
然后，我们用interface_cast(BpBinder(0))这个模版，将BpBinder(0)转换为IServiceManager类型的BpServiceManager对象。
至此，我们得到了ServiceManager的代理对象。
3.Cameraserver注册至ServiceManager：
CameraService未实现父类BinderService的方法instantiate();所以会调用父类的方法：
/frameworks/native/include/binder/BinderService.h
static void instantiate() { publish(); }
public:
static status_t publish(bool allowIsolated = false) {
sp<IServiceManager> sm(defaultServiceManager());
return sm->addService(
String16(SERVICE::getServiceName()),//将service的名字传给SM
new SERVICE(), allowIsolated);//将service的实例传给SM
}
//getServiceName()在子类中实现，返回"media.camera"
/frameworks/av/services/camera/libcameraservice/CameraService.h
static char const* getServiceName() { return "media.camera"; } 我们看到，NativeService在初始化的过程就是把自己注册为独立Service name的Service的过程，同时把Service对象传递给ServiceManager。
在publish中我们又看到defaultServiceManager()获取到sm，由上面小节的分析我们知道sm是ServiceManager的代理对象，事实上是一个BpServiceManager(BpBinder(0))，执行sm->addService()会调到BpServiceManager类中的addService方法。
frameworks/native/libs/binder/IServiceManager.cpp::BpServiceManager
virtual status_t addService(const String16& name, const sp<IBinder>& service,
bool allowIsolated)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
data.writeInt32(allowIsolated ? 1 : 0);
//transact函数在IPCThreadState.h中默认值是0代表oneway,异步无需等待结果继续执行
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//操作指令是add service，service名字在data里
return err == NO_ERROR ? reply.readExceptionCode() : err;
} 这里的remote()返回的是mRemote，是BpBinder对象；由上面BpServiceManager的介绍中知道BpServiceManager的构造函数中BpBinder(0)这个对象最终是赋给了BpServiceManager的父类BpRefBase的mRemote成员变量，而此时我们通过remote()函数得到的对象应该就是BpBinder(0)这个对象。因此，remote()->transact()即是BpBinder(0)->transact()。
下面看BpBinder的transact方法，发现transact方法的具体实现是在IPCThreadState中:
/frameworks/native/libs/binder/BpBinder.cpp
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
// Once a binder has died, it will never come back to life.
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);//这里的handle是0，code是ADD_SERVICE_TRANSACTION，data中是service名字等信息
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}我们看到BpBinder里调用了IPCThreadState的transact方法：
/frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::transact(int32_t handle,uint32_t code, const Parcel& data,Parcel* reply, uint32_t flags)
{
if (err == NO_ERROR) {
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
}
if ((flags & TF_ONE_WAY) == 0) {
if (reply) {
err = waitForResponse(reply);
} else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}
...
} else {
err = waitForResponse(NULL, NULL);
}
return err;
}首先数据封装，writeTransactionData()将数据封装至mOut中，每个线程都有一个IPCThreadState.cpp，每个IPCThreadState中有一个mIn,一个mOut,其中mIn是用来接收来自Binder设备的数据，mOut则是用来存储发往Binder设备的数据
status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{
binder_transaction_data tr;//向binder驱动中传输数据的数据结构
tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */
tr.target.handle = handle;
tr.code = code;
tr.flags = binderFlags;
...
mOut.writeInt32(cmd);
mOut.write(&tr, sizeof(tr));//将tr中保存的数据写到mOut中
return NO_ERROR;
}通过waitForResponse()传输数据：
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
uint32_t cmd;
int32_t err;
while (1) {
if ((err=talkWithDriver()) < NO_ERROR) break;//向binder驱动交换数据操作
cmd = (uint32_t)mIn.readInt32();//从mIn中获取binder驱动传过来的命令
switch (cmd) {
case BR_TRANSACTION_COMPLETE: break;//binder驱动返回对端transact成功
case BR_DEAD_REPLY:err = DEAD_OBJECT;goto finish;//
case BR_FAILED_REPLY: err = FAILED_TRANSACTION;goto finish;
case BR_ACQUIRE_RESULT://暂时未实现
//binder驱动给Client进程传递Server进程的回复
case BR_REPLY:{...}goto finish;
default:
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}
finish:
...
return err;
}在talkWithDriver()函数中通过ioctl方式来和binder驱动进行数据交换操作:把mOut中的内容发送给binder驱动，同时从mIn读取binder驱动传来的数据
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
binder_write_read bwr;//用来与binder设备交换数据的结构
...
bwr.write_buffer = (uintptr_t)mOut.data();//mOut中的数据放置bwr的write_buffer中
if (doReceive && needRead) {//从mIn中读取binder驱动传来的数据
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
...
status_t err;
#if defined(__ANDROID__)
//通过ioctrl向binder驱动中mProcess->mDriverFD几点进行BINDER_WRITE_READ操作，数据在&bwr中
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0) err = NO_ERROR;
...
} while (err == -EINTR);
...
return err;
} 在service_manager进程中，service_manager正在不断的向binder驱动中查询是否有向自己发的请求，经过上一步的ioctl()后，service_manager进程会不断循环检测是否有请求需执行，随后执行service_manager的do_add_service方法将该camaraservice信息加到service_manager的service管理链表中。
这样就完成了service向ServiceManager的注册过程，具体可以看上篇文章有关ServiceManager的流程-Android Framework:Binder(2)-Service Manager
至此完成addService的操作。
小结：
通过上面的过程即通过ServiceManager的代理BpServiceManager(BpBinder(0))将CameraService的servicename和实例注册到了ServiceManager中了;
4.Service线程池管理，处理请求
作为一个Service，向ServiceManager注册完自己之后，Service就需要有检测自己被调用的机制了，这里的检测机制就是CameraService搭建的线程池检测机制：
ProcessState::self()->startThreadPool();//新启动一个线程来和Binder驱动进行交互
IPCThreadState::self()->joinThreadPool();//主线程也与Binder设备进行交互startThreadPool()中新启动一个线程：
frameworks\native\libs\binder\ProcessState.cpp
void ProcessState::startThreadPool()
{
AutoMutex _l(mLock);
if (!mThreadPoolStarted) {
mThreadPoolStarted = true;
spawnPooledThread(true);
}
}这里的isMain是true：
void ProcessState::spawnPooledThread(bool isMain)
{
if (mThreadPoolStarted) {
String8 name = makeBinderThreadName();
sp<Thread> t = new PoolThread(isMain);
t->run(name.string());
}
}跑起来一个PoolThread类型的线程：
frameworks\native\libs\binder\ProcessState.cpp
class PoolThread : public Thread
{
public:
PoolThread(bool isMain)
: mIsMain(isMain)
{
}
protected:
virtual bool threadLoop()
{
IPCThreadState::self()->joinThreadPool(mIsMain)//这里
return false;
}
const bool mIsMain;
}
...
}startThreadPool()中spawnPooledThread()出的新线程同样执行了joinThreadPool()函数,区别是子线程中参数是true，而主线程中设置的参数为默认参数false ：
void IPCThreadState::joinThreadPool(bool isMain)
{
//如果isMain是true则进入循环，否则注册准备进入循环
mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);
set_sched_policy(mMyThreadId, SP_FOREGROUND);
status_t result;
do {
processPendingDerefs();
result = getAndExecuteCommand();//在循环中获取是否有需要执行的指令
...
} while (result != -ECONNREFUSED && result != -EBADF);
mOut.writeInt32(BC_EXIT_LOOPER); //向mOut中写上退出循环标志,BC_XXX是进程发送给binder驱动的命令
talkWithDriver(false);//
}在IPCThreadState的joinThreadPool函数中的do-while死循环中先talkwithdriver()从binder驱动中读取Client端请求的数据：
status_t IPCThreadState::getAndExecuteCommand()
{
status_t result;
int32_t cmd;
result = talkWithDriver();
if (result >= NO_ERROR) {
...
cmd = mIn.readInt32();
//处理收到的消息
result = executeCommand(cmd);
...
}
return result;
}循环中得到请求后，mIn中有binder驱动有回复的Client端的请求数据，则执行executeCommand()函数，将Client端请求重新打包成Parcel数据发送给Service的BBinder对象即Service端代理去执行相应的请求：
status_t IPCThreadState::executeCommand(int32_t cmd)
{
BBinder* obj;
RefBase::weakref_type* refs;
status_t result = NO_ERROR;
switch ((uint32_t)cmd) {
case BR_ERROR:result = mIn.readInt32();break;
case BR_OK: break;
case BR_ACQUIRE:mOut.writeInt32(BC_ACQUIRE_DONE); break;
case BR_RELEASE:break;
case BR_INCREFS: break;
case BR_DECREFS: break;
case BR_ATTEMPT_ACQUIRE:break;
case BR_TRANSACTION:
{
binder_transaction_data tr;
result = mIn.read(&tr, sizeof(tr));//从mIn中读取数据放至tr中
...
Parcel reply;
status_t error;
if (tr.target.ptr) {
//获取目标对象的强引用
if (reinterpret_cast<RefBase::weakref_type*>( tr.target.ptr)->attemptIncStrong(this)) {
//BBinder的transact()函数，即执行Server端的transact函数
error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer,&reply, tr.flags);
reinterpret_cast<BBinder*>(tr.cookie)->decStrong(this);
}
}
...
}
break;
case BR_DEAD_BINDER:break;
case BR_CLEAR_DEATH_NOTIFICATION_DONE: break;
case BR_FINISHED:result = TIMED_OUT;break;
case BR_NOOP: break;
//binder驱动回复的消息用来创建一个新线程用来和Binder通信
case BR_SPAWN_LOOPER:mProcess->spawnPooledThread(false); break;
...
}
}对于CameraService将会调用Service的BBinder中onTransact()接口的实现函数：
frameworks\av\services\camera\libcameraservice\CameraService.cpp::onTransact
status_t CameraService::onTransact(uint32_t code, const Parcel& data, Parcel* reply,
uint32_t flags) {
const int pid = getCallingPid();
const int selfPid = getpid();
// Permission checks
switch (code) {
case BnCameraService::NOTIFYSYSTEMEVENT: {
if (pid != selfPid) {
// Ensure we're being called by system_server, or similar process with
// permissions to notify the camera service about system events
if (!checkCallingPermission(
String16("android.permission.CAMERA_SEND_SYSTEM_EVENTS"))) {
const int uid = getCallingUid();
ALOGE("Permission Denial: cannot send updates to camera service about system"
" events from pid=%d, uid=%d", pid, uid);
return PERMISSION_DENIED;
}
}
break;
}
}
return BnCameraService::onTransact(code, data, reply, flags);
} 至此调用到Service端的实现请求的地方,。
总结一下：
三、Native Service注册总结：
Service在启动时需要向ServiceManager注册自己的信息，从而可使client端通过ServiceManager查询和获取该service的实例和调用方法。
Native Service中camera server初始化时主要经过以下几个步骤：
1. 获取本进程的ProcessState实例，并确保ProcessState的初始化中打开binder驱动一次，将进程的基本信息写入至Binder驱动中。
2. 获取ServiceManager的代理对象：BpServiceManager(BpBinder(0)),通过该代理对象调用ServiceManager的addService方法将Service的name及实例通过ioctl()方法传至Binder驱动。
3. ServiceManager端在开机启动后便一直在读取Binder驱动中是否有自己的Client端的请求，此时有addService的请求，因此ServiceManager会将Binder驱动中的Service请求数据重新解析然后注册至自身的svclist的链表中;
4. CameraServer注册完之后会搭建自身的监听请求的机制：会起个IPC的线程池，不断的talkWithDriver向binder驱动中查询是否有Client端的请求，如果有打包请求数据，执行IPC线程中的executeCommand()的函数获取Server端的BBinder对象执行transact函数，从而执行Service的方法。
参考博客：
Binder源码分析之Native层（原）：
http://blog.csdn.net/u010961631/article/details/20922145
Binder 通信笔记（native）：
http://www.itwendao.com/article/detail/62406.html
Binder系列5—注册服务(addService)：
http://gityuan.com/2015/11/14/binder-add-service/
1914
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
