bindump utility is a little tool I've put together for my book, after realizing that there's no tool I know of, AOSP or other, which can map out which PIDs communicate over Binder with which. I needed this type of mapping for the chapter dealing with the Framework Services, as well as the long discussion on Binder Internals. The book is still not done (but, honestly, this year!), yet this tool is usable on its own. And is super simple, yes, though darn useful.
You can get the tool right here, as a tar with ARMv7 and ARMv8 (ARM64) binaries. The binaries should work on any Android 9 or higher. I've even worked around for Samsung oddities, and for Android 11 preview. As usual, you might want to check out the RSS feed, or follow my company's Twitter for more updates.
Why should I care?
If you've called
Context.getSystemService(..), you've been using Binder (through proxy objects). The owning PID of most of these services is
system_server, but not always - notable exceptions being the
batterypropregistrar. Vendor installed services sometimes also run in their own processes.
If you want to get a better idea of who's talking to whom in your device - this is a pretty good tool for that. From the
So how do I use it?
Glad you asked. Usage couldn't be simpler. Unlike the original version of this tool, this now requires root privileges for the full power:
It gets better when you have root. for example, you can now inspect the vndbinder namespace:
With the real kicker being "users" -
'users' tells you which processes have handles to the service (real-time of course), AND who owns the node! This is REALLY useful. For example, try
users power to see who holds wakelocks, or
users SurfaceFlinger for whoever has views:
[vnd/hw]servicemanager) are always users - that's because they need to give out the handle on lookup
How does it work?
Ah. An even better question. While a discussion of Binder is outside the scope of this little write-up (and, hey, it's in the book!), this tool's functionality is simple enough to explain in a few lines:
- Bind to the servicemanager, and check for the requested service. This automatically establishes a binder connection to the service
- Next, seek out
/sys/kernel/debug/binder/proc/$mypid. In it is a specific line of interest, in the form:
ref xxxxxxx: desc yy node xxxxxxx s 1 w 1 d (null)That "node" is what we're looking for. There are actually two node - ones for the service manager, which we can skip - it's always the first one. The second one is the one binding to our service. So we can extract the node number easily.
- Finally, enumerate all entries in
/sys/kernel/debug/binder/proc- these are all processes which have binder handles. If they have the node as a ref, that means they're users of this very same service. If they have the Node in a
Node:line, they are the owner.
Example: healthd (owner of batterypropreg):
And that's that.
I'm working on improvements to adapt this to non published services (i.e. any binder nodes), as well as produce SVG output. And I'm always looking for suggestions. So stay tuned.
When will it not work?
- If you don't have the debugfs mounted under
- If Binder wasn't compiled with debug data (which it is, by default)
License notes, etc
Free for non commercial use. Not open source, due to blatant ripoff of its previous version (which is, btw, why it now requires root - Google didn't like it either...). The original source of the previous version is here. The source is nothing fancy - it takes that of
service.cpp as a point of departure, but then embarks on its own journey. The updated source is a full re-write, using a Binder pure C interface I (painstakingly) wrote from scratch.
Shameless plug for the book, and RFC
The forever-delayed Volume II has a TON of detail about the framework services, and volume II covers the nooks and crannies of Binder in places where I betcha Dianne Hackborn herself (Love your work!) might feel uncomfortable ;-). The book is not out yet, but with MOXiI out of the way, and nothing to do locked down at home, it's finally progressing! In the interim, I encourage you to try out the tool (as well as the even more powerful JTrace) and shoot me an email (to j@) if you've any questions. Or comments. Or in general. All are welcome.