Android Binder框架实现之Native层getService详解之请求的发送
Android Binder框架实现目录：
Android Binder框架实现之Binder的设计思想
Android Binder框架实现之何为匿名/实名Binder
Android Binder框架实现之Binder中的数据结构
Android Binder框架实现之Binder相关的接口和类
Android Binder框架实现之Parcel详解之基本数据的读写
Android Binder框架实现之Parcel read/writeStrongBinder实现
Android Binder框架实现之servicemanager守护进程
Android Binder框架实现之defaultServiceManager()的实现
Android Binder框架实现之Native层addService详解之请求的发送
Android Binder框架实现之Native层addService详解之请求的处理
Android Binder框架实现之Native层addService详解之请求的反馈
Android Binder框架实现之Binder服务的消息循环
Android Binder框架实现之Native层getService详解之请求的发送
Android Binder框架实现之Native层getService详解之请求的处理
Android Binder框架实现之Native层getService详解之请求的反馈
Android Binder框架实现之Binder Native Service的Java调用流程
Android Binder框架实现之Java层Binder整体框架设计
Android Binder框架实现之Framework层Binder服务注册过程源码分析
Android Binder框架实现之Java层Binder服务跨进程调用源码分析
Android Binder框架实现之Java层获取Binder服务源码分析
引言
在前面的篇章中，我们以MediaPlayerService为例，介绍了Service服务是如何通过addService请求添加到ServiceManager中的(其中的艰难困苦，你懂的)。本文，将以MediaPlayer获取MediaPlayerService服务为例，来介绍Client端是如何通过发起getService请求，进而从ServiceManager中获取到MediaPlayerServer远程代理对象。在本文的getService请求中，MediaPlayer是Client端，它要获取的Server接入点是MediaPlayerService。和前面介绍addService篇章一样，在分析getService时，会将文章分为请求的发送，请求的处理，和请求的反馈这三部分来分别进行介绍(不要问我为啥是三部分，因为内容太多)。
注意：本文是基于Android 7.xx版本进行介绍的，其中涉及的源码路径为：
frameworks/native/libs/binder/IServiceManager.cpp
frameworks/native/libs/binder/Static.cpp
frameworks/native/libs/binder/ProcessState.cpp
kernel/drivers/staging/android/binder.c
kernel/include/linux/list.h
kernel/drivers/staging/android/uapi/binder.h
external/kernel-headers/original/uapi/linux/android/binder.h
frameworks/native/include/binder/ProcessState.h
frameworks/native/include/binder/BpBinder.h
frameworks/native/libs/binder/BpBinder.cpp
frameworks/native/include/binder/IPCThreadState.h
frameworks/native/libs/binder/IPCThreadState.cpp
frameworks/native/include/binder/IInterface.h
frameworks/native/libs/binder/IInterface.cpp
frameworks/native/include/binder/IBinder.h
frameworks/native/libs/binder/Binder.cpp
frameworks/av/media/mediaserver/main_mediaserver.cpp
frameworks/native/cmds/servicemanager/service_manager.c
/frameworks/av/media/libmedia/IMediaDeathNotifier.cpp
- 在正式开始介绍Native层的getService具体逻辑分析前，我们先奉上整体架构示意图，如下所示：
- 接着在正式开始进行源码分析前，先看看Native Binder类图如下：
一. getService整体概述
老规矩，在大讲特讲之前，还是让我们上图说话，这样让读者先从整体上有一个了解，然后再深入细节，这个可不是谈女朋友额。上图：
猛地一看，你会发现该时序图和Android Binder机制(六) addService详解之请求的发送中的时序图几乎是一模一样的，难道是换了马甲不成，还不允许别人长一个样了啊，天下美女不还都差不多啊。
下面我们分步讲解，一一攻破，手到擒来：
(1) 先是MediaPlayer进程将getService以BC_TRANSACTION事务的方式发给Binder驱动。
(2) Binder驱动收到之后，对内容进行解析；然后唤醒ServiceManager，同时反馈一个BR_TRANSACTION_COMPLETE给MediaPlayer。反馈的BR_TRANSACTION_COMPLETE是告诉MediaPlayer，它的getService请求已经被Binder驱动成功收到。
(3) 接着，MediaPlayer就进入等待状态，等待ServiceManager的反馈。 ServiceManager被唤醒之后，读取Binder驱动传递给它的BR_TRANSACTION事务。在得知是获取MediaPlayerService的请求之后，就从缓冲中取出MediaPlayerService的相关信息；然后和BC_REPLY指令一起反馈给Binder驱动。
(4) Binder驱动收到ServiceManager的反馈之后，将内容进一步反馈给MediaPlayer，并将MediaPlayer唤醒。
(5) MediaPlayer被唤醒之后，从Binder驱动反馈的BR_REPLY中解析出MediaPlayerService的相关信息；这样，MediaPlayer就成功获取到了MediaPlayerService的接入点。
二. getService的代码解析
1 MediaPlayer客户端的getService入口
const sp<IMediaPlayerService>
IMediaDeathNotifier::getMediaPlayerService()
{
ALOGV("getMediaPlayerService");
Mutex::Autolock _l(sServiceLock);
if (sMediaPlayerService == 0) {
sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder;
do {
binder = sm->getService(String16("media.player"));//参见章节2
if (binder != 0) {
break;
}
ALOGW("Media player service not published, waiting...");
usleep(500000); // 0.5 s
} while (true);
if (sDeathNotifier == NULL) {
sDeathNotifier = new DeathNotifier();
}
binder->linkToDeath(sDeathNotifier);
sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);
}
ALOGE_IF(sMediaPlayerService == 0, "no media player service!?");
return sMediaPlayerService;
}
如上代码是在C++层获取MediaPlayerService代理对象的代码，定义在./frameworks/av/media/libmedia/IMediaDeathNotifier.cpp文件里面，也许会有读者说这个和我们在App看到的获取MediaPlayerService的不一样，这个会在后续说明(最终通过JNI调用到这里)，下面来详细解读一下该段代码：
(1) sMediaPlayerService是sp成员，初始化为null。因此if(sMediaPlayerService==0)为true。
(2) 调用defaultServiceManager()获取IServiceManager对象，该对象实际上是BpServiceManager类的实例。defaultServiceManager()的详细流程请参考Android Binder机制(五) defaultServiceManager()的实现，此时可能会出现服务还没有添加成功的可能，那么等待0.5秒继续获取知直到成功。
(3) 接着就是调用sm->getService(String16(“media.player”))获取MediaPlayerService对象。
2 BpServiceManager::getService()
virtual sp<IBinder> getService(const String16& name) const
{
unsigned n;
for (n = 0; n < 5; n++){//会尝试5次
if (n > 0) {
ALOGI("Waiting for service %s...", String8(name).string());
sleep(1);
}
sp<IBinder> svc = checkService(name);
if (svc != NULL) return svc;
}
return NULL;
}
virtual sp<IBinder> checkService( const String16& name) const
{
Parcel data, reply;//这个是不是有似曾相识的感觉
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}
如上代码在Android源码的frameworks/native/libs/binder/IServiceManager.cpp中，下面我么解读一下该段代码：
(1) getService()是通过调用checkService()来获取IBinder对象的。如果获取失败，它会调用sleep()休眠1ms之后再次尝试；若尝试5次都失败，则返回null。之所以要尝试5次，是由于可能此时MediaPlayerService服务还没有准备好。有没有种谈女朋友向其表白，被拒绝不死心继续表白，如果实在不行那就只能拉到了呗，难不成大老爷们一棵树上吊着不成。
(2) 下面看看checkService()，它和"Android Binder机制(六) addService详解之请求的发送中的addService()"很多内容都相似。 checkService()会先调用writeInterfaceToken()写入一个消息头：“4字节的整型数” + “字符串android.os.IServiceManager”。然后，再调用writeString16(name)将服务名"media.player"写入到data中。 最后，调用remote()->transact()进行事务交互，其中remote()返回的是BpBinder对象。
3 BpBinder::transact()
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);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}
如上代码在frameworks/native/libs/binder/BpBinder.cpp中，是不是很熟悉的感觉，它最后会调用IPCThreadState::transact()。
4 IPCThreadState::transact()
status_t IPCThreadState::transact(int32_t handle,
uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
{
status_t err = data.errorCheck();
flags |= TF_ACCEPT_FDS;
...
if (err == NO_ERROR) {
...
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);//具体参见章节4.1
}
...
if ((flags & TF_ONE_WAY) == 0) {
if (reply) {
err = waitForResponse(reply);//参见章节4.2
} else {
...
}
...
} else {
...
}
return err;
}
该代码在frameworks/native/libs/binder/IPCThreadState.cpp中。它会先通过writeTransactionData()将要发送的指令和数据打包到binder_transaction_data中，然后调用waitForResponse()和Binder驱动进行通信。由于在前面addService中已经仔细解读过，在这里就一笔带过了。
4.1 IPCThreadState::writeTransactionData()
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;
tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */
tr.target.handle = handle;
tr.code = code;
tr.flags = binderFlags;
tr.cookie = 0;
tr.sender_pid = 0;
tr.sender_euid = 0;
const status_t err = data.errorCheck();
if (err == NO_ERROR) {
tr.data_size = data.ipcDataSize();
tr.data.ptr.buffer = data.ipcData();
tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
tr.data.ptr.offsets = data.ipcObjects();
} else if (statusBuffer) {
...
} else {
...
}
mOut.writeInt32(cmd);
mOut.write(&tr, sizeof(tr));
return NO_ERROR;
}
该函数会读取Parcel中的数据，然后将其打包到tr中，tr是binder_transaction_data结构体的对象。之后，将"指令"+"数据"写入到mOut中。指令(cmd)=BC_TRANSACTION，数据就是tr。
4.2 IPCThreadState::waitForResponse()
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
int32_t cmd;
int32_t err;
while (1) {
//先通过talkWithDriver()和Binder驱动交互，具体参见章节4.3
if ((err=talkWithDriver()) < NO_ERROR) break;
err = mIn.errorCheck();
if (err < NO_ERROR) break;
if (mIn.dataAvail() == 0) continue;
//然后读取返回接口，再根据结果进行处理
cmd = (uint32_t)mIn.readInt32();
switch (cmd) {
case BR_TRANSACTION_COMPLETE:
...
case BR_DEAD_REPLY:
...
case BR_FAILED_REPLY:
...
case BR_ACQUIRE_RESULT:
...
case BR_REPLY:
...
default:
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}
finish:
...
return err;
}
如果读者有细读addService的章节，那么这里就so easy了，waitForResponse()会先调用talkWithDriver()和Binder驱动交互，然后根据反馈结果来进行处理。
4.3 IPCThreadState::talkWithDriver()
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
...
binder_write_read bwr;
// Is the read buffer empty?
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
bwr.write_size = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data();
// This is what we'll read.
if (doReceive && needRead) {
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
...
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
bwr.write_consumed = 0;
bwr.read_consumed = 0;
status_t err;
do {
...
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
...
} while (err == -EINTR);
if (err >= NO_ERROR) {
//清空已写的数据
if (bwr.write_consumed > 0) {
if (bwr.write_consumed < mOut.dataSize())
mOut.remove(0, bwr.write_consumed);
else
mOut.setDataSize(0);
}
//设置已读数据
if (bwr.read_consumed > 0) {
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);
}
...
return NO_ERROR;
}
return err;
}
不对代码详细分析了，如果你是空降部队看到这个地方请翻阅前面篇章，talkWithDriver()会先初始化bwr(binder_write_read类型的变量)，然后将bwr通过ioctl()发送给Binder驱动。初始化之后的bwr各个成员的值如下：
bwr.write_size = outAvail; // mOut中数据大小，大于0
bwr.write_buffer = (long unsigned int)mOut.data(); // mOut中数据的地址
bwr.write_consumed = 0;
bwr.read_size = mIn.dataCapacity(); // 256
bwr.read_buffer = (long unsigned int)mIn.data(); // mIn.mData，实际上为空
bwr.read_consumed = 0;
bwr初始化完成之后，调用ioctl(,BINDER_WRITE_READ,)和Binder驱动进行交互。
5 Binder驱动中binder_ioctl()的BINDER_WRITE_READ相关部分的源码
前面的章节我带领读者在用户层对addService的处理流程进行了代码跟读处理，那么接下来我们将要开车深入驱动层，探讨Binder驱动中对addServer处理的流程了，各位请做好了，车要开动了。
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
int ret;
struct binder_proc *proc = filp->private_data;
struct binder_thread *thread;
unsigned int size = _IOC_SIZE(cmd);
void __user *ubuf = (void __user *)arg;
...
//中断等待函数
// 1. 当binder_stop_on_user_error < 2为true时；不会进入等待状态；直接跳过。
// 2. 当binder_stop_on_user_error < 2为false时，进入等待状态。
// 当有其他进程通过wake_up_interruptible来唤醒binder_user_error_wait队列，并且binder_stop_on_user_error < 2为true时；
// 则继续执行；否则，再进入等待状态。
ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
...
binder_lock(__func__);
//在proc进程中查找该线程对应的binder_thread;若查找失败，则新建一个binder_thread，并添加到proc->threads中。
thread = binder_get_thread(proc);
...
switch (cmd) {
case BINDER_WRITE_READ: {
struct binder_write_read bwr;
...
//将binder_write_read从“用户空间”拷贝到“内核空间”
if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {
ret = -EFAULT;
goto err;
}
...
//如果write_size>0，则进行写操作
if (bwr.write_size > 0) {
ret = binder_thread_write(proc, thread, bwr.write_buffer, bwr.write_size, &bwr.write_consumed);
...
}
//如果read_size>0，则进行读操作
if (bwr.read_size > 0) {
ret = binder_thread_read(proc, thread, bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK);
...
}
...
if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {
ret = -EFAULT;
goto err;
}
break;
}
...
}
ret = 0;
...
return ret;
}
兜兜转转，最后又到了这里，是不是非常熟悉，这个词都说好多遍了，后面依然会说。首先，代码中会将binder_write_read从用户空间拷贝到内核空间之后。拷贝之后，读取出来的bwr.write_size和bwr.read_size都>0，因此先写后读。即，先执行binder_thread_write()，然后执行binder_thread_read()。
5.1 Binder驱动中binder_thread_write()的源码
static int binder_thread_write(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed)
{
uint32_t cmd;
void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
void __user *ptr = buffer + *consumed;
void __user *end = buffer + size;
//读取binder_write_read.write_buffer中的内容。
//每次读取32bit(即四个字节)
while (ptr < end && thread->return_error == BR_OK) {
// 从用户空间读取32bit到内核中，并赋值给cmd。
if (get_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
...
switch (cmd) {
...
case BC_TRANSACTION:
case BC_REPLY: {
struct binder_transaction_data tr;
if (copy_from_user(&tr, ptr, sizeof(tr)))
return -EFAULT;
ptr += sizeof(tr);
binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
break;
}
...
}
//更新bwr.write_consumed的值
*consumed = ptr - buffer;
}
return 0;
}
此时MediaPlayer发送的指令是BC_TRANSACTION，这里只关心与BC_TRANSACTION相关的部分。在通过copy_from_user()将数据拷贝从用户空间拷贝到内核空间之后，就调用binder_transaction()进行处理。
5.2 Binder驱动中binder_transaction()的源码
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
{
struct binder_transaction *t;
struct binder_work *tcomplete;
binder_size_t *offp, *off_end;
binder_size_t off_min;
struct binder_proc *target_proc;
struct binder_thread *target_thread = NULL;
struct binder_node *target_node = NULL;
struct list_head *target_list;
wait_queue_head_t *target_wait;
struct binder_transaction *in_reply_to = NULL;
struct binder_transaction_log_entry *e;
uint32_t return_error;
...
//此时参数reply的值为0，所以会进入非replay分支
if (reply) {
...
} else {
//此时handle的值为0
if (tr->target.handle) {
...
} else {
//该getService是从ServiceManager中获取MediaPlayer;
//因此事务目标对象是ServiceManager得binder实体。
target_node = binder_context_mgr_node;
...
}
...
//设置处理事务的目标进程
target_proc = target_node->proc;
...
}
if (target_thread) {
...
} else {
target_list = &target_proc->todo;
target_wait = &target_proc->wait;
}
...
//分配一个特处理事务t，t是binder事务(binder_transaction对象)
t = kzalloc(sizeof(*t), GFP_KERNEL);
...
//分配一个待完成的工作tcomplete，tcomplete是binder_work对象
tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL);
...
t->debug_id = ++binder_last_id;
...
//设置from，表示该事务是MediaPlayer线程发起的
if (!reply && !(tr->flags & TF_ONE_WAY))
t->from = thread;
else
t->from = NULL;
//下面的一些赋值是初始化事务t
t->sender_euid = proc->tsk->cred->euid;
//事务将交给target_proc进程进行处理
t->to_proc = target_proc;
//事务将交给target_thread线程进行处理
t->to_thread = target_thread;
//事务编码
t->code = tr->code;
//事务标志
t->flags = tr->flags;
//事务优先级
t->priority = task_nice(current);
...
//分配空间
t->buffer = binder_alloc_buf(target_proc, tr->data_size,
tr->offsets_size, !reply && (t->flags & TF_ONE_WAY));
...
t->buffer->allow_user_free = 0;
t->buffer->debug_id = t->debug_id;
//保存事务
t->buffer->transaction = t;
// 保存事务的目标对象(即处理该事务的binder对象)
t->buffer->target_node = target_node;
trace_binder_transaction_alloc_buf(t->buffer);
if (target_node)
binder_inc_node(target_node, 1, 0, NULL);
offp = (binder_size_t *)(t->buffer->data +
ALIGN(tr->data_size, sizeof(void *)));
// 将"用户空间的数据"拷贝到内核中
// tr->data.ptr.buffer就是用户空间数据的起始地址，tr->data_size就是数据大小
if (copy_from_user(t->buffer->data, (const void __user *)(uintptr_t)
tr->data.ptr.buffer, tr->data_size)) {
...
}
// 将"用户空间的数据中所含对象的偏移地址"拷贝到内核中
// MediaPlayer中不包含对象，offp=null
if (copy_from_user(offp, (const void __user *)(uintptr_t)
tr->data.ptr.offsets, tr->offsets_size)) {
...
}
...
// Mediaplayer中不包含对象，off_end为null
off_end = (void *)offp + tr->offsets_size;
off_min = 0;
// MediaPlayer中不包含对象, offp=off_end
for (; offp < off_end; offp++) {
...
}
if (reply) {
...
} else if (!(t->flags & TF_ONE_WAY)) {
BUG_ON(t->buffer->async_transaction != 0);
t->need_reply = 1;
t->from_parent = thread->transaction_stack;
//将当前事务添加到当前线程的事务栈中
thread->transaction_stack = t;
} else {
...
}
//设置事务的类型为BINDER_WORK_TRANSACTION
t->work.type = BINDER_WORK_TRANSACTION;
//将事务添加到target_list队列中，即target_list的待处理事务中
list_add_tail(&t->work.entry, target_list);
// 设置待完成工作的类型为BINDER_WORK_TRANSACTION_COMPLETE
tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE;
// 将待完成工作添加到thread->todo队列中，即当前线程的待完成工作中。
list_add_tail(&tcomplete->entry, &thread->todo);
//唤醒目标进程
if (target_wait)
wake_up_interruptible(target_wait);
return;
...
}
此时参数reply=0，表明这是个请求事务，而不是反馈。binder_transaction新建会新建"一个待处理事务t"和"待完成的工作tcomplete"，并根据请求的数据对它们进行初始化。接着前面的分析，让我们逐步详解其余逻辑：
(1) MediaPlayer的getService请求是提交给ServiceManager进行处理的，因此，"待处理事务t"会被添加到ServiceManager的待处理事务队列中。此时的target_thread是ServiceManager对应的线程，而target_proc则是ServiceManager对应的进程上下文环境。
(2) 此时，Binder驱动已经收到了MediaPlayer的getService请求；于是，将一个BINDER_WORK_TRANSACTION_COMPLETE类型的"待完成工作tcomplete"添加到当前线程(即，MediaPlayer线程)的待处理事务队列中。目的是告诉MediaPlayer，Binder驱动已经收到它的getService请求了。
(3) 最后，调用wake_up_interruptible(target_wait)将Service Manager唤醒。
接下来，还是先分析完MediaPlayer线程，再看ServiceManager被唤醒后做了些什么。
binder_transaction()执行完毕之后，就会返回到binder_thread_write()中。binder_thread_write()更新bwr.write_consumed的值后，就返回到binder_ioctl()继续执行"读"动作。即执行binder_thread_read()。
5.3 Binder驱动中binder_thread_read()的源码
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
void __user *ptr = buffer + *consumed;
void __user *end = buffer + size;
int ret = 0;
int wait_for_proc_work;
//如果*consumed=0，则写入BR_NOOP到用户传进来的bwr.read_buffer缓存区
if (*consumed == 0) {
if (put_user(BR_NOOP, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
}
retry:
//等待proc进程的事务标记。
//当线程的事务栈为空 并且 待处理事务队列为空时，该标记位true。
wait_for_proc_work = thread->transaction_stack == NULL &&
list_empty(&thread->todo);
...
thread->looper |= BINDER_LOOPER_STATE_WAITING;
if (wait_for_proc_work)
proc->ready_threads++;
...
if (wait_for_proc_work) {
...
} else {
if (non_block) {
...
} else
ret = wait_event_freezable(thread->wait, binder_has_thread_work(thread));
}
binder_lock(__func__);
if (wait_for_proc_work)
proc->ready_threads--;
thread->looper &= ~BINDER_LOOPER_STATE_WAITING;
...
while (1) {
uint32_t cmd;
struct binder_transaction_data tr;
struct binder_work *w;
struct binder_transaction *t = NULL;
//如果当前线程的"待完成工作"不为空，则取出待完成工作
if (!list_empty(&thread->todo))
w = list_first_entry(&thread->todo, struct binder_work, entry);
else if (!list_empty(&proc->todo) && wait_for_proc_work)
...
else {
if (ptr - buffer == 4 && !(thread->looper & BINDER_LOOPER_STATE_NEED_RETURN)) /* no data added */
goto retry;
break;
}
...
switch (w->type) {
...
case BINDER_WORK_TRANSACTION_COMPLETE: {
cmd = BR_TRANSACTION_COMPLETE;
// 将BR_TRANSACTION_COMPLETE写入到用户缓冲空间中
if (put_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
binder_stat_br(proc, thread, cmd);
...
//待完成事务已经处理完毕，将其从待完成事务队列中删除
list_del(&w->entry);
kfree(w);
binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);
} break;
...
}
if (!t)
continue;
...
//更新bwr.read_consumed的值
*consumed = ptr - buffer;
...
return 0;
}
代码虽然不多，但是信息量还是比较大的，下面让我们来逐层分析，步步为营：
(1) 先看看函数的参数，此时bwr.read_consumed=0，即if (*consumed == 0)为true。因此，会将BR_NOOP写入到bwr.read_buffer中。
(2) thread->transaction_stack不为空，thread->todo也不为空。因为，前面在binder_transaction()中有将一个BINDER_WORK_TRANSACTION_COMPLETE类型的待完成工作添加到thread的待完成工作队列中。因此，wait_for_proc_work为false。
(3) binder_has_thread_work(thread)为true。因此，在调用wait_event_interruptible()时，不会进入等待状态，而是继续运行。
(4) 进入while循环后，通过list_first_entry()取出待完成工作w。w的类型w->type=BINDER_WORK_TRANSACTION_COMPLETE，进入到对应的switch分支。随后，将BR_TRANSACTION_COMPLETE写入到bwr.read_buffer中。此时，待处理工作已经完成，将其从当前线程的待处理工作队列中删除。
(5) 最后，更新bwr.read_consumed的值。
经过binder_thread_read()处理之后，bwr.read_buffer中包含了两个指令：BR_NOOP和BR_TRANSACTION_COMPLETE。
再回到binder_ioctl()中，在将bwr拷贝到用户空间之后，binder_ioctl()的工作就完成了。于是就返回到talkWithDriver()中。
6 重返IPCThreadState::transact()
通过前面分析可知，此时代码已经从驱动层返回到了应用层，那么让我们一起跟着代码的脚步来到应用层继续分析吗！
6.1 IPCThreadState::talkWithDriver()
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
...
binder_write_read bwr;
// Is the read buffer empty?
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
bwr.write_size = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data();
// This is what we'll read.
if (doReceive && needRead) {
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
...
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
bwr.write_consumed = 0;
bwr.read_consumed = 0;
status_t err;
do {
...
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
...
} while (err == -EINTR);
if (err >= NO_ERROR) {
//清空已写的数据
if (bwr.write_consumed > 0) {
if (bwr.write_consumed < mOut.dataSize())
mOut.remove(0, bwr.write_consumed);
else
mOut.setDataSize(0);
}
//设置已读数据
if (bwr.read_consumed > 0) {
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);
}
...
return NO_ERROR;
}
return err;
}
ioctl()从驱动层返回以后的返回值为0，所以err=NO_ERROR,此时退出while循环。接着代码往下执行：
(1) 从Binder驱动返回后，bwr.write_consumed>0，因此调用mOut.setDataSize(0)将mOut中的数据清空。这意味着，MediaPlayer的请求Binder驱动已经收到，并且已经将请求数据读取完毕。
(2) bwr.read_consumed也>0，因此会执行if(bwr.read_consumed>0)中的代码，更新mIn中的mDataSize和mDataPos。这意味着，Binder驱动反馈给MediaPlayer的数据不为空。接下来，MediaPlayer线程肯定会读取Binder驱动反馈的数据(BR_NOOP和BR_TRANSACTION_COMPLETE)。在读取完这些数据之后，MediaPlayer线程会再次调用ioctl(,BINDER_WRITE_READ,)进行读动作；而当执行到binder_thread_read()时，由于此时MediaPlayer线程的待处理工作队列为空，因此MediaPlayer线程会进入中断等待状态。待ServiceManager守护进程处理完MediaPlayer的请求之后，就会将MediaPlayer唤醒。
写在最后
至此，getService请求的发送部分就介绍完了。在接下来的章节，就看看ServiceManager被唤醒后是如何获取MediaPlayerService代理对象，然后再将该代理对象反馈给MediaPlayer的。由于在前面的addService篇章里面已经对代码有过十分详细的讲解了，所以这里就没有详细分析了，如果有不清晰的地方可以翻阅前面的章节。
3905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
