承接上文,从getService开始,要开始走binder的通讯机制了。
首先是上文的java层 /frameworks/base/core/java/android/os/ServiceManagerNative.java:
118 public IBinder getService(String name) throws RemoteException {
119 Parcel data = Parcel.obtain();
120 Parcel reply = Parcel.obtain();
121 data.writeInterfaceToken(IServiceManager.descriptor);
122 data.writeString(name);
123 mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
124 IBinder binder = reply.readStrongBinder();
125 reply.recycle();
126 data.recycle();
127 return binder;
128 }
1.建立2个Parcel数据data和reply,一个是入口数据,一个是出口数据;
2.data中写入要获取的service的name;
3.关键:走mRemote的transact函数;
4.读取出口数据;
5.回收资源,返回读取到的binder对象;
mRemote是个什么东西?看代码:
29 /**
30 * Cast a Binder object into a service manager interface, generating
31 * a proxy if needed.
32 */
33 static public IServiceManager asInterface(IBinder obj)
34 {
35 if (obj == null) {
36 return null;
37 }
38 IServiceManager in =
39 (IServiceManager)obj.queryLocalInterface(descriptor);
40 if (in != null) {
41 return in;
42 }
43
44 return new ServiceManagerProxy(obj);
45 }
110 public ServiceManagerProxy(IBinder remote) {
111 mRemote = remote;
112 }
/frameworks/base/core/java/android/os/ServiceManager.java:
33 private static IServiceManager getIServiceManager() {
34 if (sServiceManager != null) {
35 return sServiceManager;
36 }
37
38 // Find the service manager
39 sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
40 return sServiceManager;
41 }
/frameworks/base/core/java/com/android/internal/os/BinderInternal.java:
83 /**
84 * Return the global "context object" of the system. This is usually
85 * an implementation of IServiceManager, which you can use to find
86 * other services.
87 */
88 public static final native IBinder getContextObject();
可以看到,是个IBinder对象,obj.queryLocalInterface(descriptor);这句话是IBinder定义的一个接口,实现在/frameworks/base/core/java/android/os/Binder.java:
248 /**
249 * Use information supplied to attachInterface() to return the
250 * associated IInterface if it matches the requested
251 * descriptor.
252 */
253 public IInterface queryLocalInterface(String descriptor) {
254 if (mDescriptor.equals(descriptor)) {
255 return mOwner;
256 }
257 return null;
258 }
插一句,这个descriptor是个描述符String类型的,费劲找了半天,在/frameworks/base/core/java/android/os/IServiceManager.java里面有定义:
63 static final String descriptor = "android.os.IServiceManager";
用来表示当前是ServiceManager。ServiceManagerProxy的构造传递进入的IBinder就是remote。就是BinderInternal.getContextObject()返回的。看下注释:“Return the global "context object" of the system”,是系统的上下文context。找到在native层的实现:
/frameworks/base/core/jni/android_util_Binder.cpp
899static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
900{
901 sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
902 return javaObjectForIBinder(env, b);
903}
904
要弄清楚到底这个remote是个什么玩意儿,还要继续看ProcessState这个类,一个c++类,看头文件定义:
/frameworks/native/include/binder/ProcessState.h
37 static sp<ProcessState> self();
是个单例,因为他是在native层,不是在驱动设备层,因此可以理解为每个进程一个。看看他的getContextObject干了什么吧:
85sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
86{
87 return getStrongProxyForHandle(0);
88}
179sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
180{
181 sp<IBinder> result;
182
183 AutoMutex _l(mLock);
184
185 handle_entry* e = lookupHandleLocked(handle);
186
187 if (e != NULL) {
188 // We need to create a new BpBinder if there isn't currently one, OR we
189 // are unable to acquire a weak reference on this current one. See comment
190 // in getWeakProxyForHandle() for more info about this.
191 IBinder* b = e->binder;
192 if (b == NULL || !e->refs->attemptIncWeak(this)) {
193 if (handle == 0) {
194 // Special case for context manager...
195 // The context manager is the only object for which we create
196 // a BpBinder proxy without already holding a reference.
197 // Perform a dummy transaction to ensure the context manager
198 // is registered before we create the first local reference
199 // to it (which will occur when creating the BpBinder).
200 // If a local reference is created for the BpBinder when the
201 // context manager is not present, the driver will fail to
202 // provide a reference to the context manager, but the
203 // driver API does not return status.
204 //
205 // Note that this is not race-free if the context manager
206 // dies while this code runs.
207 //
208 // TODO: add a driver API to wait for context manager, or
209 // stop special casing handle 0 for context manager and add
210 // a driver API to get a handle to the context manager with
211 // proper reference counting.
212
213 Parcel data;
214 status_t status = IPCThreadState::self()->transact(
215 0, IBinder::PING_TRANSACTION, data, NULL, 0);
216 if (status == DEAD_OBJECT)
217 return NULL;
218 }
219
220 b = new BpBinder(handle);
221 e->binder = b;
222 if (b) e->refs = b->getWeakRefs();
223 result = b;
224 } else {
225 // This little bit of nastyness is to allow us to add a primary
226 // reference to the remote proxy when this team doesn't have one
227 // but another team is sending the handle to us.
228 result.force_set(b);
229 e->refs->decWeak(this);
230 }
231 }
232
233 return result;
234}
说实话,看到这里有点头大了,在看操作系统源码的时候经常是一个东西牵扯一堆的概念或其他的对象,如果你想跳过去只看梗概,有时候还真不行,需要弄明白就需要深入了解。所以我们再接再厉。
lookupHandleLocked(handle);这句是根据handle查询得到handle_entry,这个里面存储着binder。那么这个handle有点像windows下的同名东西,只是个索引用来找到内容实体。
166ProcessState::handle_entry* ProcessState::lookupHandleLocked(int32_t handle)
167{
168 const size_t N=mHandleToObject.size();
169 if (N <= (size_t)handle) {
170 handle_entry e;
171 e.binder = NULL;
172 e.refs = NULL;
173 status_t err = mHandleToObject.insertAt(e, N, handle+1-N);
174 if (err < NO_ERROR) return NULL;
175 }
176 return &mHandleToObject.editItemAt(handle);
177}
注意,这个mHandleToObject是个Vector<handle_entry>mHandleToObject;在头文件中有定义。一个数组用来维护handle实体集合,而这些实体里面存放的就是binder。而这些东西都是在ProcessState里面的内容,而ProcessState是个单例,每个进程都唯一有一个。那么好吧,这么理解:每个android进程都存储一个所有本进程用到的binder的数组。
再继续看getStrongProxyForHandle,如果handle是0(实际传递进来的就是0,0指代的就是servicemanager),那么等于是要获得servicemanager,这个最基础的服务,这时候走了一个特殊的过程,IPCThreadState::self()->transact(0, IBinder::PING_TRANSACTION, data, NULL, 0);从字面上看,这里是ping了一下这个binder的内核设备,了解网络的都知道这个的含义。如果状态是dead,直接返回null。这些都在查询到的binder为null的情况下,是null的时候继续走,会创建一个BpBinder对象,并将其设置到handle_entry里,实际上就是维护在了之前的vector里面保存了下来,下次用直接取。最后返回的就是这个BpBinder,结合之前上文所述,这个BpBinder就是mRemote;
好吧,新的问题来了,BpBinder是什么?
继续看吧:/frameworks/native/include/binder/BpBinder.h
27class BpBinder : public IBinder
这一句可看出,是从IBinder对象继承下来的,再看IBinder对象:
/frameworks/native/include/binder/IBinder.h
就是个虚拟类,规范接口。我们在其中看到2句话:
139 virtual BBinder* localBinder();
140 virtual BpBinder* remoteBinder();
回来看BpBinder里:
59 virtual BpBinder* remoteBinder();
看到这里,猜测下,IBinder用来规范所有Binder的接口,但是Binder分为两类:Server和Client,用localBinder和remoteBinder来区分,那么具体实现IBinder的子类里,你实现哪个接口那么实际上你就是那个类型。
暂时先放下这部分,我们往回倒,回到java层。还记得ServiceManager的getService吧,一切其实是从这里开始的,他返回的是一个IBinder对象,其实我们现在知道就是BpBinder。然后在缓存没有的情况下进入到ServiceManagerNative.asInterface中,这里会new一个ServiceManagerProxy对象,让我们再次看看这个对象其中的getService方法,实际上调用的是这个方法:
118 public IBinder getService(String name) throws RemoteException {
119 Parcel data = Parcel.obtain();
120 Parcel reply = Parcel.obtain();
121 data.writeInterfaceToken(IServiceManager.descriptor);
122 data.writeString(name);
123 mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
124 IBinder binder = reply.readStrongBinder();
125 reply.recycle();
126 data.recycle();
127 return binder;
128 }
mRemote.transact是关键,既然我们已经知道就是BpBinder了,那么往下看。
/frameworks/native/libs/binder/BpBinder.cpp
159status_t BpBinder::transact(
160 uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
161{
162 // Once a binder has died, it will never come back to life.
163 if (mAlive) {
164 status_t status = IPCThreadState::self()->transact(
165 mHandle, code, data, reply, flags);
166 if (status == DEAD_OBJECT) mAlive = 0;
167 return status;
168 }
169
170 return DEAD_OBJECT;
171}
关键用到了IPCThreadState::self()->transact。那么这个IPCThreadState看起来是个线程的对象。在self中new了自己,然后在构造中:
686IPCThreadState::IPCThreadState()
687 : mProcess(ProcessState::self()),
688 mMyThreadId(gettid()),
689 mStrictModePolicy(0),
690 mLastTransactionBinderFlags(0)
691{
692 pthread_setspecific(gTLS, this);
693 clearCaller();
694 mIn.setDataCapacity(256);
695 mOut.setDataCapacity(256);
696}
将进程对象保留下来,并且保留自身当前所在的线程id。那么猜测下,这个线程对象其实是和当前的线程相关联的,为了每个线程都可访问binder。并且在上面的self方法中也有处理tls的事情,这里就不贴代码了。那么BpBinder.transact里面走的是IPCThreadState的transact:
/frameworks/native/libs/binder/IPCThreadState.cpp
548status_t IPCThreadState::transact(int32_t handle,
549 uint32_t code, const Parcel& data,
550 Parcel* reply, uint32_t flags)
551{
552 status_t err = data.errorCheck();
553
554 flags |= TF_ACCEPT_FDS;
555
556 IF_LOG_TRANSACTIONS() {
557 TextOutput::Bundle _b(alog);
558 alog << "BC_TRANSACTION thr " << (void*)pthread_self() << " / hand "
559 << handle << " / code " << TypeCode(code) << ": "
560 << indent << data << dedent << endl;
561 }
562
563 if (err == NO_ERROR) {
564 LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(),
565 (flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY");
566 err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
567 }
568
569 if (err != NO_ERROR) {
570 if (reply) reply->setError(err);
571 return (mLastError = err);
572 }
573
574 if ((flags & TF_ONE_WAY) == 0) {
575 #if 0
576 if (code == 4) { // relayout
577 ALOGI(">>>>>> CALLING transaction 4");
578 } else {
579 ALOGI(">>>>>> CALLING transaction %d", code);
580 }
581 #endif
582 if (reply) {
583 err = waitForResponse(reply);
584 } else {
585 Parcel fakeReply;
586 err = waitForResponse(&fakeReply);
587 }
588 #if 0
589 if (code == 4) { // relayout
590 ALOGI("<<<<<< RETURNING transaction 4");
591 } else {
592 ALOGI("<<<<<< RETURNING transaction %d", code);
593 }
594 #endif
595
596 IF_LOG_TRANSACTIONS() {
597 TextOutput::Bundle _b(alog);
598 alog << "BR_REPLY thr " << (void*)pthread_self() << " / hand "
599 << handle << ": ";
600 if (reply) alog << indent << *reply << dedent << endl;
601 else alog << "(none requested)" << endl;
602 }
603 } else {
604 err = waitForResponse(NULL, NULL);
605 }
606
607 return err;
608}
关键就一句:writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);在写入数据。
904status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
905 int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
906{
907 binder_transaction_data tr;
908
909 tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */
910 tr.target.handle = handle;
911 tr.code = code;
912 tr.flags = binderFlags;
913 tr.cookie = 0;
914 tr.sender_pid = 0;
915 tr.sender_euid = 0;
916
917 const status_t err = data.errorCheck();
918 if (err == NO_ERROR) {
919 tr.data_size = data.ipcDataSize();
920 tr.data.ptr.buffer = data.ipcData();
921 tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
922 tr.data.ptr.offsets = data.ipcObjects();
923 } else if (statusBuffer) {
924 tr.flags |= TF_STATUS_CODE;
925 *statusBuffer = err;
926 tr.data_size = sizeof(status_t);
927 tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer);
928 tr.offsets_size = 0;
929 tr.data.ptr.offsets = 0;
930 } else {
931 return (mLastError = err);
932 }
933
934 mOut.writeInt32(cmd);
935 mOut.write(&tr, sizeof(tr));
936
937 return NO_ERROR;
938}
关键是最后2句 mOut.writeInt32(cmd);mOut.write(&tr, sizeof(tr));。干嘛呢?就是先写指令,后写binder的传输数据。然后呢?居然没有其它处理,好吧,往下看。transcat方法中往后走到waitForResponse,我们来看看:
712status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
713{
714 uint32_t cmd;
715 int32_t err;
716
717 while (1) {
718 if ((err=talkWithDriver()) < NO_ERROR) break;
719 err = mIn.errorCheck();
720 if (err < NO_ERROR) break;
721 if (mIn.dataAvail() == 0) continue;
722
723 cmd = (uint32_t)mIn.readInt32();
724
725 IF_LOG_COMMANDS() {
726 alog << "Processing waitForResponse Command: "
727 << getReturnString(cmd) << endl;
728 }
729
730 switch (cmd) {
731 case BR_TRANSACTION_COMPLETE:
732 if (!reply && !acquireResult) goto finish;
733 break;
734
735 case BR_DEAD_REPLY:
736 err = DEAD_OBJECT;
737 goto finish;
738
739 case BR_FAILED_REPLY:
740 err = FAILED_TRANSACTION;
741 goto finish;
742
743 case BR_ACQUIRE_RESULT:
744 {
745 ALOG_ASSERT(acquireResult != NULL, "Unexpected brACQUIRE_RESULT");
746 const int32_t result = mIn.readInt32();
747 if (!acquireResult) continue;
748 *acquireResult = result ? NO_ERROR : INVALID_OPERATION;
749 }
750 goto finish;
751
752 case BR_REPLY:
753 {
754 binder_transaction_data tr;
755 err = mIn.read(&tr, sizeof(tr));
756 ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY");
757 if (err != NO_ERROR) goto finish;
758
759 if (reply) {
760 if ((tr.flags & TF_STATUS_CODE) == 0) {
761 reply->ipcSetDataReference(
762 reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
763 tr.data_size,
764 reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
765 tr.offsets_size/sizeof(binder_size_t),
766 freeBuffer, this);
767 } else {
768 err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer);
769 freeBuffer(NULL,
770 reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
771 tr.data_size,
772 reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
773 tr.offsets_size/sizeof(binder_size_t), this);
774 }
775 } else {
776 freeBuffer(NULL,
777 reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
778 tr.data_size,
779 reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
780 tr.offsets_size/sizeof(binder_size_t), this);
781 continue;
782 }
783 }
784 goto finish;
785
786 default:
787 err = executeCommand(cmd);
788 if (err != NO_ERROR) goto finish;
789 break;
790 }
791 }
792
793finish:
794 if (err != NO_ERROR) {
795 if (acquireResult) *acquireResult = err;
796 if (reply) reply->setError(err);
797 mLastError = err;
798 }
799
800 return err;
801}
上来就是一个死循环,然后里面有一句talkWithDriver,后面就直接去读取mIn的内容了。那么我认为这句是关键,在将刚才写入的数据告知内核驱动,并等待完成数据处理。到底是否正确呢?看代码:
/frameworks/native/libs/binder/IPCThreadState.cpp
803status_t IPCThreadState::talkWithDriver(bool doReceive)
804{
805 if (mProcess->mDriverFD <= 0) {
806 return -EBADF;
807 }
808
809 binder_write_read bwr;
810
811 // Is the read buffer empty?
812 const bool needRead = mIn.dataPosition() >= mIn.dataSize();
813
814 // We don't want to write anything if we are still reading
815 // from data left in the input buffer and the caller
816 // has requested to read the next data.
817 const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
818
819 bwr.write_size = outAvail;
820 bwr.write_buffer = (uintptr_t)mOut.data();
821
822 // This is what we'll read.
823 if (doReceive && needRead) {
824 bwr.read_size = mIn.dataCapacity();
825 bwr.read_buffer = (uintptr_t)mIn.data();
826 } else {
827 bwr.read_size = 0;
828 bwr.read_buffer = 0;
829 }
830
831 IF_LOG_COMMANDS() {
832 TextOutput::Bundle _b(alog);
833 if (outAvail != 0) {
834 alog << "Sending commands to driver: " << indent;
835 const void* cmds = (const void*)bwr.write_buffer;
836 const void* end = ((const uint8_t*)cmds)+bwr.write_size;
837 alog << HexDump(cmds, bwr.write_size) << endl;
838 while (cmds < end) cmds = printCommand(alog, cmds);
839 alog << dedent;
840 }
841 alog << "Size of receive buffer: " << bwr.read_size
842 << ", needRead: " << needRead << ", doReceive: " << doReceive << endl;
843 }
844
845 // Return immediately if there is nothing to do.
846 if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
847
848 bwr.write_consumed = 0;
849 bwr.read_consumed = 0;
850 status_t err;
851 do {
852 IF_LOG_COMMANDS() {
853 alog << "About to read/write, write size = " << mOut.dataSize() << endl;
854 }
855#if defined(HAVE_ANDROID_OS)
856 if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
857 err = NO_ERROR;
858 else
859 err = -errno;
860#else
861 err = INVALID_OPERATION;
862#endif
863 if (mProcess->mDriverFD <= 0) {
864 err = -EBADF;
865 }
866 IF_LOG_COMMANDS() {
867 alog << "Finished read/write, write size = " << mOut.dataSize() << endl;
868 }
869 } while (err == -EINTR);
870
871 IF_LOG_COMMANDS() {
872 alog << "Our err: " << (void*)(intptr_t)err << ", write consumed: "
873 << bwr.write_consumed << " (of " << mOut.dataSize()
874 << "), read consumed: " << bwr.read_consumed << endl;
875 }
876
877 if (err >= NO_ERROR) {
878 if (bwr.write_consumed > 0) {
879 if (bwr.write_consumed < mOut.dataSize())
880 mOut.remove(0, bwr.write_consumed);
881 else
882 mOut.setDataSize(0);
883 }
884 if (bwr.read_consumed > 0) {
885 mIn.setDataSize(bwr.read_consumed);
886 mIn.setDataPosition(0);
887 }
888 IF_LOG_COMMANDS() {
889 TextOutput::Bundle _b(alog);
890 alog << "Remaining data size: " << mOut.dataSize() << endl;
891 alog << "Received commands from driver: " << indent;
892 const void* cmds = mIn.data();
893 const void* end = mIn.data() + mIn.dataSize();
894 alog << HexDump(cmds, mIn.dataSize()) << endl;
895 while (cmds < end) cmds = printReturnCommand(alog, cmds);
896 alog << dedent;
897 }
898 return NO_ERROR;
899 }
900
901 return err;
902}
先创建一个binder_write_read对象bwr,这个对象是个存储读写内容的对象。然后呢一堆的判断和日志操作,最重要的一句在这里:if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)。看到这里我想说:他妈的,终于到了。真心虐啊,这里终于看到了曙光,这么n层的调用和各种逻辑中,我们看到了和驱动交互的部分!下面真的该进入到内核驱动部分了,不过先停一下,我们总结下。
我们这篇解释了remote是什么,与binder的关系,引入了BpBinder的概念(server的binder),不过没有仔细分析,后面在适当的时候会解释他与BnBinder的关系。然后说明了线程的IPCThreadState与binder的关系,还有为了支持多线程环境下与其他进程的binder,有必要在这个对象中封装了与binder内核驱动通讯的内容,需要注意的是transact真正的传输数据。然后终于进入了内核驱动的部分。
其实总感觉还是有很多内容没有提及,我觉得目前先抓主线,我们要分析的是servicemanager以及它怎么利用binder与其他进程交互数据,其实线有很多,先沿着getService走下去,等到这条线明朗一些了,后面我们再看其他的会轻松不少。
下一篇我们再继续吧。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。