Android Framework:Binder(4)-Native Service的注册

时间 2020-03-20

标签 android framework binder native service 注册栏目 Android 繁體版

原文原文链接

Android Framework:Binder(4)-Native Service的注册
1、Native Service注册的概述
　　Android中不少Service是Native Service，本篇咱们挑选Native service中的cameraserver的启动注册来学习Native Service注册涉及的Binder机制。android

　　Native Service在启动后须要经过Binder驱动向ServiceManager进行注册，注册过程便是一次跨进程的操做，Native Service是Client端，ServiceManager是Server端。cookie

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模块的类的结构基本以下：app

　　其中蓝色的框的地方在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的读取，写入和请求处理框架。异步

2、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/tasksoop

　　咱们知道启动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();
1
　　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端的实现请求的地方,。
　总结一下：

3、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的方法。