以 AMS 为例
//ActivityManagerService.java
public void setSystemProcess( ){
ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
}
//ServiceManager.java
public static addService(String name, IBinder service, boolean allowIsolated){
getIServiceManager( ).addService(name, service, allowIsloted)
}
private static IServiceManager getIServiceManager(){
sServiceManager = ServiceManagerNative.getInterface(BinderInternal.getContextObject);
}
//android_utils_Binder.cpp
//该方法返回一个 Java 层的BinderProxy 对象，同时持有下面的 BpBinder(handle = 0)的句柄
static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz){
sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
return javaObjectForIBinder(env, b);
}
//ProcessState.cpp
//改方法返回一个 BpBinder(handle = 0)
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>&){
return getStrongProxyForHandle(0);
}
//ServiceManagerNative.java
static public IServiceManager asInterface(IBinder obj){
return new ServiceManagerProxy(obj)
}
经过一系列的反应，最后再 AMS 进程中，service_manager 在 AMS 中的代理表现为
ServiceManagerNativeBidnerProxy.java 对象内部有成员变量 mObject,表现为 native 层BpBinder.cpp对象。BpBinder.cpp 对象内部有一个 handle 为0，表示 service_manager 在 binder 驱动中的注册编号
--重头戏---
addService( )@ServiveManager.java
⤵️
addService( )@ServiceManagerNative$ServiceManagerProxy.java
⤵️
transact(ADD_SERVICE_TRANSACTION)@Binder$BinderProxy.java
⤵️
android_os_BinderProxy_transact()@android_util_Binder.cpp
⤵️
transact( )@BpBinder.cpp
⤵️
transact( )@IPCThreadState.cpp
⤵️
ioctl()@IPCThreadState.cpp使用的 cmd 就是 BINDER_WRITE_READ
接下来看每一层的数据打包过程。
①
//参数,name = "activity", service 是 ActivityManagerService, allowIsolated=true
public void addService(String name,IBinder service, boolean allowIsolated){
Parcel data = Parcel.obtain( )
Parcel reply = Parcel.obtain( )
data.writeInterfaceToken(IServiceManager.descriptor);
data.writeString(name);
data.writeStrongBinder(service);
data.writeInt(allowIsolated? 1 : 0);
mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
reply.recycle( );
data.recycle( );
}
关于 Parcel 打包，参见link
此时 Parcel data 打包了一些基础数据类型，将 ActivityManagerService.java 封装成了 flat_binder_object 打包进 Parcel。
//BinderProxy
//code 就是 ADD_SERVICE_TRANSACT, data 是封装了请求信息，reply 没有内容，flags=0
public boolean transact(int code, Parcel data, Parcel reply, int flags){
return transactNative(code, data, reply, flags)
}
//android_utils_Binder.cpp
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj, jint code, jobject dataObject, jobject replyObj, jint flags){
//从 Parcel.java 中的 mNativePtr 获得 native 层的 Parcel.cpp
Parcel* data = parcelForJavaObject(env, dataObj);
Parcel* reply = parcelForJavaObject(env, replyObj);
//从 BinderProxy.java 获得 BpBinder
//此处 BpBinder 中的 handle = 0，代表 service_manager
IBinder* target = (IBinder*) env->GetLongField(obj, gBinderProxyOffsets.mObject);
status_t err = target->transact(code, *data, reply, flags)
}
//BpBinder.cpp
status BpBinder::transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){
status_t status = IPCThreadState::self()->transact(mHandle, code, data, reply. flags);
}
//IPCThreadState.cpp
status_t IPCThreadState::transact(int32_t handle, uint32_T code, const Parcel& data, Parcel* reply, uint32_t flags){
//表示通讯 cmd 是 BC_TRANSACTION，表示向 Binder 驱动发送消息
//handle = 0 表示向 handle = 0 的服务，即 service_manager 发送消息
//code = ADD_SERVICE,该码用来给目标服务表示要调用的方法
//data 包含了请求的参数
//于是 handle，code，data 包含了目标对象，目标方法，方法参数
writeTransactionData(BC_TRANSACTION, flags, handle, code, data);
//真正发起 RPC 通讯
waitForResponse(reply)
}
status_t IPCThreadStatus::writeTransactionData(int32_t cmd, uint32_t binderFlags, int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer){
//IPCThreadStatus 层的包装协议是 binder_transaction_data,在目标进程也按照该协议进行拆箱
//cmd = BC_TRANSACTION 是该层的命令协议
//封装的 binder_transaction_data 连同 cmd 打包进了 mOut
binder_transaction_data tr;
tr.target.ptr = 0;
tr.target.handle = handle;
tr.code = code;
tr.flags = binderFlags;
tr.cookie=0
tr.sender_pid = 0;
tr.sender_euid = 0;
tr.data_size = data.ipcDataSize( );
tr.data.ptr.buffer = data.ipcData();
tr.offsets_size = data.ipcObjecCount()*sizeof(binder_size_t);
tr.data.ptr.offet = data.ipcObjects( );
mOut.writeInt32(cmd)
mout.write(&tr, sizeof(tr))
}
status_t IPCThreadStatus::waitForResponse(Parcel * reply, status_t *acquireResult){
//进行 PRC
talkWithDriver();
//处理 RPC 返回结果
...
}
status_t IPCThreadStatus::talkWithDriver(boolean doReceive){
//与 Binder 驱动交换数据
binder_write_read bwr;
bwr.write_siez = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data()
ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)
}
- 一级通讯 cmd 为 BINDER_WRITE_READ，像 Binder 驱动表示此次 RPC 需求读写内容
- 二级 cmd 为 BC_TRANSACTION
- 三级 cmd 为 ADD_VERSION
接下来看通讯的解包装
//binder.c，此时是在 kernel中运行
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long args){
//获得发起请求的进程 binder_proc 结构
struct binder_proc *proc = filp->private_data;
struct binder_thread *thread;
//用户空间的 binder_write_read 的指针
void __user *ubuf = (void __user *)arg;
//kernal将当前进程，即发起请求的进程进行休眠。直到被唤醒
//如果 binder_stop_on_user_error < 2则直接跳过不会挂起
wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error <2);
//获得发起 RPC 请求的现场
thread = binder_get_thread(proc);
switch(cmd){
//符合一级通讯 cmd
case BINDER_WRITE_READ{
struct binder_write_read bwr;
//将用户进程的 binder_write_read 拷贝到内核空间
copy_from_user(&bwr, ubuf, sizeof(bwr))
//本次请求符合
if(bwr.write_size >0){
binder_thread_write(proc, thread, bwr.write_buffer, bwr.write_size, &bwr.write_consumed);
}
}
}
}
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;//此时指针子 bwr 中 write_buffer 的 data
void __user *end = buffer+size
swicth(cmd){
//二级通讯 cmd
case BC_TRANSACTION:
binder_transaction_data tr;
//再次拆箱，拆出 binder_transaction_data
copy_from_user(&tr, ptr, sizeof(tr));
//真正发起 RPC，这里可以看到，binder 驱动将 BC_TRANSACTION换成了 BC_REPLY
binder_transaction(proc, thread, &tr, cmd = BC_REPLY);
}
}
binder_transaction( )函数格外复杂。简而言之是根据请求中目标进程的 handle(此处为 0)，多啰嗦一句，所有的 Binder 实体经过 Binder 驱动，都会被记录到一个 binder_node 节点并且插入到 Binder 驱动的 2 颗红黑树(key 不同)。在这里因为 handle 为 0，于是找到对应的 Binder 实体对应的进程，随后创建一个事务binder_transaction,将其挂载到目标进程 traget_list 即 todo 队列。随后唤醒目标进程。
在此处，调用wait_event_interruptible()尝试休眠 AMS 进程是，因为 binder_stop_on_user_error < 2成立，因此不会休眠进程。在进行binder_thread_write()进行 rpc 调用后，在binder_thread_read()会通过wait_event_freezable_exclusive()休眠当前线程，知道 service_manager.cpp 返回请求结果。
而 service_manager.cpp 进入 loop 后，就是一直阻塞在binder_thread_read()中的wait_event_freezable_exclusive()去尝试获取请求。当 binder_has_proc_work()符合条件，即进程所造的 todo 队列有内容，才会唤醒。
当 AMS 将此次 RPC 请求投递到 service_manager.cpp 所在的 todo 队列，service_manager.cpp 就会被唤醒，读取处理请求。同事 AMS 会在wait_event_freezable_exclusive()挂起线程，直到有某个事务(其他进程或者 service_manager.cpp 返回了结果)被投递到 AMS 进程所在的 todo 队列
Binder 的通讯大致过程都相似，如果是同步请求 A 进程像 Binder 发送 RPC，内核休眠 A 进程，唤醒目标 B 进程，处理请求，回复 Binder 驱动，唤醒 A 进程。
网友评论