Android Native Binder

Android binder(S)

A key part of Android is the Binder mechanism.

A bit of history/background

The Android binder mechanism was originally based on the OpenBinder project. As you can read

here Dianne Hackborn open sourced a project called

OpenBinder when she left PalmSource. If you read the OpenBinder documentation that can be found

here you will find

similarities with how binder works in Android. The current binder in Android is incompatible

with the original binder implementation still key information can be found at

Binder
IPC mechanism .

The documentation on this page is an atempt at documenting how binder really works on Android

Warning

This page has not been reviewed and probably does contains many errors.

The kernel view

Binder is a linux-kernel module that can send messages between userland processes(using IOCTL’s)
A program using binder can send serialized messages. This serialized message can contain basic types but also include

local pointers. Pointers are accompanied with meta-data about it being a pointers.
A program using binder can read serialized messages.
It is possible to request a more permanent “handle” object by acquiring this from binder (ref counting).
The binder kernel module is able to translate local object pointers with handles and can keep track of those handles
There is no real client or server at this stage the process calling is waiting in a
IOCLT for results and the process

being called will wake-up from the IOCTL it was calling and it can also happen that a process will call itself.

(

TODO is this really true? How about threading are message queued?) (

TODO the kernel module does contain threading information like
MAX THREAD) how does this work?

Most programs do not directly use this operational mode but one of them talking at this level is the service manager.

frameworks/base/cmds/servicemanager/binder.c and frameworks/base/cmds/servicemanager/service_manager.c show the real

guts of the binder framework (including requesting a reference to a binder object)

The kernel drivers

The kernel module accepts module options allowing it to be more verbose

the module parameter is called debug_mask and in an unsigned int. It’s value can be determined

by looking the binder source code: drivers/staging/android/binder.c

enum {
BINDER_DEBUG_USER_ERROR             = 1U << 0,
BINDER_DEBUG_FAILED_TRANSACTION     = 1U << 1,
BINDER_DEBUG_DEAD_TRANSACTION       = 1U << 2,
BINDER_DEBUG_OPEN_CLOSE             = 1U << 3,
BINDER_DEBUG_DEAD_BINDER            = 1U << 4,
BINDER_DEBUG_DEATH_NOTIFICATION     = 1U << 5,
BINDER_DEBUG_READ_WRITE             = 1U << 6,
BINDER_DEBUG_USER_REFS              = 1U << 7,
BINDER_DEBUG_THREADS                = 1U << 8,
BINDER_DEBUG_TRANSACTION            = 1U << 9,
BINDER_DEBUG_TRANSACTION_COMPLETE   = 1U << 10,
BINDER_DEBUG_FREE_BUFFER            = 1U << 11,
BINDER_DEBUG_INTERNAL_REFS          = 1U << 12,
BINDER_DEBUG_BUFFER_ALLOC           = 1U << 13,
BINDER_DEBUG_PRIORITY_CAP           = 1U << 14,
BINDER_DEBUG_BUFFER_ALLOC_ASYNC     = 1U << 15,
};

contains proc debugging entries :

state

stats

transactions

transaction_log

failed_transaction_log

Sample “low level” scenario

The Service opens the binder kernel module ( file open “/dev/binder” )
It registers a thread pool for callbacks (ioctl bcSET_THREAD_ENTRY , *createNewThread, void * data)) (This is no

longer true for binder in android is it?)
The service performs a transaction using a special “known” remote reference “0” (handle) to the IServiceManager to map

itself with a name

The client opens the binder kernel module ( file open “/dev/binder” )
It is requests a handle to the service by calling a method from the the IServiceManager
It is creates a transaction to the Service to call the service (ioctl BINDER_WRITE_READ)
It response to the transaction

The
CPP view

The cpp layer of binder eases development of binder code. It makes use of smart pointers and threading and in general

abstracts many of the details of obtaining handles to object.

Overview of the critical classes

There are a few critical classes the IInterface,IBinder,BBinder,BnInterface and BpInterface. The first letter(s) of

the class tell something about them. I as in Interface , B as in Base class, Bn as in Base native and Bp as in Base

proxy.

I = Interface defines an object that will be accessible over binderB = Base implementationBn = Base native (local object implementation)Bp = Base proxy
The IInterface class defines an object that can represent itself as a binder object. in a pure native implementation

there will be two implementation of this interface. One Proxy implementation that will represent the client end and one

native implementation that will convert binder calls to method calls on the “server”.

class IInterface extends RefBase

+ asBinder()

+ onAsBinder();

The IBinder class (frameworks/base/include/binder/IBinder.h) defines a class that is intended to be use to implement

binder services it declares the transac method to perform the binder transactions

and the attach/detach object to implement reference counting (of bound objects?) in userland.

class IBinder extends RefBase

+ transac(core , parcel in , parcel out, flags)

+ attachObject (id,object)

+ detachObject (id )

The BBinder class is the standard implementation of IBinder for a IInterface object using binder as communication

mechanism (IBinder and IInterface objects don’t actually need to use binder)

class BBinder implements IBinder

+ getInterfaceDescriptor() // string representing the name of the service interface

The remaining binder related classes in the framework are BnInterface and and BpInterface

The BnInterface is used to implement the native end of an IInterface

class BnInterface extends BBinder

+ queryLocalInterface(descriptor)

the BpInterface is used to implement Proxy classes

class BpInterface extends BpRefBase

+ onAsBinder();

+ remote() IBinder (declared in BpRefBase)

If you want more information on how to implement native binder services you are encouraged to read the code of

Android-HelloWorldService

binder threading

The basic programming model followed when developing a binder service is to spawn threads for incoming requests

and perform outgoing request directly.

Specifically, each process has a pool of “binder threads” which sit there waiting for incoming IPCs from other process.

When an IPC is dispatched to your process, one of these threads comes out of the pool to process it.

Backtrace on idling

__ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15
15      ldmfd   sp!, {r4, r7}
(gdb) bt
#0  __ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15
#1  0xafd26a6c in ioctl (fd=<value optimized out>, request=16) at bionic/libc/bionic/ioctl.c:41
#2  0xa8215fa4 in android::IPCThreadState::talkWithDriver (this=0xa470, doReceive=true) at
frameworks/base/libs/binder/IPCThreadState.cpp:791
#3  0xa8216980 in android::IPCThreadState::joinThreadPool (this=0xa470, isMain=true) at
frameworks/base/libs/binder/IPCThreadState.cpp:446
#4  0x0000869e in main (argc=<value optimized out>, argv=<value optimized out>) at
mycomp/Android-HelloWorldService/helloworld/main_helloworldservice.cpp:27

Backtrace on a incomming request

#0  android::HelloWorldService::hellothere (this=0xa760, str=0xac20 "fun") at
mycomp/Android-HelloWorldService/libhelloworldservice/src/helloworldservice.cpp:3
#1  0x80003654 in android::HelloWorldService::onTransact (this=0xa760, code=<value optimized out>,
data=<value optimized out>, reply=0xbe9e5ae8, flags=17) at m
#2  0xa821359e in android::BBinder::transact (this=0xa764, code=1, data=..., reply=0xbe9e5ae8, flags=17) at
frameworks/base/libs/binder/Binder.cpp:107
#3  0xa82167bc in android::IPCThreadState::executeCommand (this=0xa470, cmd=<value optimized out>)
at frameworks/base/libs/binder/IPCThreadState.cpp:1012
#4  0xa821699e in android::IPCThreadState::joinThreadPool (this=0xa470, isMain=true) at
frameworks/base/libs/binder/IPCThreadState.cpp:457
#5  0x0000869e in main (argc=<value optimized out>, argv=<value optimized out>) at
mycomp/Android-HelloWorldService/helloworld/main_helloworldservice.cpp:27

The service manager service.

frameworks/base/cmds/servicemanager/service_manager.c

The Java layer on top

An Overview of the Java binder implementation

Android Service , Activities and Intent

Android Services Activities and Intent follow many of the principles found in the Native binder implementation

and they can make use of the available remoting facilities. It in important however to understand that there are big

differences.

First of all Service and Activities do not register themself to the IServiceManager the Only component that is actually

registered to the IServicemManager is the ActivityManager himelf. This Activity manager enhances the lower binder

implementation by providing process lifecycle.

IActivityManager → publishService usefull as counter part of bindService?

ActivityThread.java → really calles the onBind of a service

more stuff I found

-

Quoting the essential stuff ( from the open binder documentation)

The Binder communicates between processes using a small custom kernel module. This is used instead of

standard Linux IPC facilities so that we can efficiently model our
IPC operations as “thread migration”.

That is, an IPC between processes looks as if the thread instigating the
IPC has hopped over to the destination process

to execute the code there, and then hopped back with the result.

The Binder IPC mechanism itself, however, is not actually implemented using thread migration. Instead, the Binder’s

user-space code maintains a pool of available threads in each process, which are used to process incoming IPCs and

execute local events in that process. The kernel module emulates a thread migration model by propagating thread

priorities across processes as IPCs are dispatched and ensuring that, if an
IPC recurses back into an originating

process, the IPC is handled by its originating thread.

In addition to IPC itself, the Binder’s kernel module is also responsible for tracking object references across

processes. This involves mapping from remote object references in one process to the real object in its host process,

and making sure that objects are not destroyed as long as other processes hold references on them.

Also read

Android services in the android framework group and
threading in the android-developers group.
Hackborn about connecting to a binder c++ service

- An IBinder object represents a unique handle, which will be

maintained across IPCs. That is, if you have an IBinder that you send

from process A to process B, and at any point process B sends that

object back to process A, then process A will receive the exact same

IBinder object it originally sent. This is another part of

maintaining consistency with a local call, and can be very useful for

implementing things like tokens that are sent around, since there is

no way for a process to spoof them (and you can use

IBinder.linkToDeath() to be informed when the process hosting a token

as gone away).

HOWEVER, IInterface objects are not currently a unique identity —basically IMyInterface.asInterface() will always return a new instanceof the interface (proxy) every time you call it. So when comparingobjects, always be sure to call
IInterface.asBinder() and compare theunderlying IBinder objects.

原文地址： https://github.com/keesj/gomo/wiki/AndroidNativeBinder