Gotcha!
I’ve debugged why I was unable to display the memory relating to Android binder transactions coming from the kernel to user-side. It turns out that Binder is marking the pages as VM_IO, and the kernel code behind strace’s umoven function was unwilling to dump pages marked as such.
To fix this, just alter drivers/binder/binder.c line 585 (on my copy)…
vma->vm_flags |= VM_RESERVED | VM_READ | VM_RAND_READ | VM_IO | VM_DONTCOPY | VM_DONTEXPAND;
Remove the “VM_IO” from that list.
This appears to me to be a valid change, because the pages aren’t really I/O… they’re used for communicating within the Linux device, not outside of it.
Thanks to Motz for the time-saving instructions on how to build the Android kernel.
Anyway, I now have a complete record of the OpenBinder transactions sent and received by the ’service’ command. I want to do some cleanups, especially around the area of offsets into the transaction data, so I can nicely show the object references involved. I will eventually get around to posting the output (and of course the changes) here.
Then I’ll apply the same tools (again) to the normal Android startup, and after that, I’ll try to feed the output into my existing Macrobug tools and come up with a flowchart of the startup process of Android. At least that’s the plan.
April 7th, 2009 at 10:17 am
It’s been a couple of years since you posted this, and I’m wondering if you’ve made any progress in deciphering this stuff? I’d like to create a perl module to interface with the services on a live phone, and have been bouncing between (unmodified) strace, service, dumpsys, and the source code in an attempt to create usable functions…however, I’ve not had much progress in using /dev/binder.
My knowledge in java and C is limited (though growing as I do this), however if you still have those notes that would help alot. I’d rather not write a module that calls /system/bin/service and parses the output with regexp :P I suppose I could rewrite the utility as a dynaloader module, but that’s not as interesting as raw ioctls and syscalls :P
April 7th, 2009 at 10:36 am
Hi there, I haven’t looked at it for ages, sorry! Except to see what Android does on top of it.
If you haven’t already, I’d recommend you have a look at some of the ways Binder is used in the Android code. Have a look at http://source.android.com/download. Good example C++ code using Binder can be found in the Surface Flinger (and of course many other places). The Surface Flinger is the compositing process which uses OpenGL surfaces to display what applications present. The applications therefore have to make various requests to the Surface Flinger to ensure their stuff is displayed – that happens across Binder. The class names are pretty weird, but as a guide…
IThingy = the abstract interface = a concrete object implementing IThingy = a facade to the BnBinder existing in another process. This is a concrete class which marshalls the data to send over /dev/binder to the BnBinder, which then acts upon it.
BnBinder
BpBinder
(Those might be slightly wrong, but the ‘n’ and ‘p’ are the important bits).
Specifically with the Surface Flinger there are several different B?Binder classes. For example SurfaceFlingerClient is actually, I think, a Bn object (i.e. on the server-side.) The name just means it handles everything related to a given surface flinger client, rather than actually being that client.
You should be aware that the ’services’ available using the ’service’ tool are a separate, higher-level thing built on top of Binder. Most things (e.g. surface flinger, intents/activities/etc.) still use Binder, but don’t use that nice high-level ’services’ interface.
My modifications to strace can be found here: http://www.macrobug.com/opensource/ They’re definitely worth a look, if you can get them to compile… and I’d be fascinated to see what traces you come up with!
Good luck!
Ade