defaultServiceManager()返回的是被IServiceManager包装的BpBinder类对象。
BpBinder对象调用transact函数会调用到IPCThreadState的transaction函数,改函数直接和binder驱动通信,向驱动写入数据binder_write_read。
Servicemanager守护进程会循环从binder读取驱动读取binder_write_read数据,解析数据进行相应的操作,如addService/checkService/getService。【该守护进程基本就做这些操作】。
【源码在frameworks/native/cmds/servicemanager下】
Binder交互:
BpServiceManager -> addService(const String16& name, const sp
bool allowIsolated)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
data.writeInt32(allowIsolated ? 1 : 0);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
【这里的remote就是BpBinder的实例】
}
BpBinder -> transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{ if (mAlive) {
status_t status = IPCThreadState::self()->transact( mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}
IPCThreadState->transact(int32_t handle, uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
这个函数就是构造一个binder_transaction_data结构体。
waitForResponse(Parcel *reply, status_t *acquireResult)
这个函数实际构造binder_write_read数据结构并和Driver通信,并等待reply。
ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)
调用ioctl函数和驱动交互,向驱动传递参数的同时,bwr会带回驱动的返回数据(如果有)
1.针对servicemanager服务,这里写入的binder_write_read数据结构会在servicemanager守护进程被读取,并执行相应的命令。
2.针对非servicemanager或者说是通过servicemanager添加到系统的服务,则在通过调用getService时【实际是checkService】,由于addService向binder中添加了实现了BnXXX接口的对象,则getService时就会返回这个对象。只是大多时候我们会给强制转换构造为BpXXX类对象。但是BpXXX类对象中还是调用BnXXX的transact函数。