| Base interface for a remotable object, the core part of a lightweight
remote procedure call mechanism designed for high performance when
performing in-process and cross-process calls. This
interface describes the abstract protocol for interacting with a
remotable object. Do not implement this interface directly, instead
extend from {@link Binder}.
The key IBinder API is {@link #transact transact()} matched by
{@link Binder#onTransact Binder.onTransact()}. These
methods allow you to send a call to an IBinder object and receive a
call coming in to a Binder object, respectively. This transaction API
is synchronous, such that a call to {@link #transact transact()} does not
return until the target has returned from
{@link Binder#onTransact Binder.onTransact()}; this is the
expected behavior when calling an object that exists in the local
process, and the underlying inter-process communication (IPC) mechanism
ensures that these same semantics apply when going across processes.
The data sent through transact() is a {@link Parcel}, a generic buffer
of data that also maintains some meta-data about its contents. The meta
data is used to manage IBinder object references in the buffer, so that those
references can be maintained as the buffer moves across processes. This
mechanism ensures that when an IBinder is written into a Parcel and sent to
another process, if that other process sends a reference to that same IBinder
back to the original process, then the original process will receive the
same IBinder object back. These semantics allow IBinder/Binder objects to
be used as a unique identity (to serve as a token or for other purposes)
that can be managed across processes.
The system maintains a pool of transaction threads in each process that
it runs in. These threads are used to dispatch all
IPCs coming in from other processes. For example, when an IPC is made from
process A to process B, the calling thread in A blocks in transact() as
it sends the transaction to process B. The next available pool thread in
B receives the incoming transaction, calls Binder.onTransact() on the target
object, and replies with the result Parcel. Upon receiving its result, the
thread in process A returns to allow its execution to continue. In effect,
other processes appear to use as additional threads that you did not create
executing in your own process.
The Binder system also supports recursion across processes. For example
if process A performs a transaction to process B, and process B while
handling that transaction calls transact() on an IBinder that is implemented
in A, then the thread in A that is currently waiting for the original
transaction to finish will take care of calling Binder.onTransact() on the
object being called by B. This ensures that the recursion semantics when
calling remote binder object are the same as when calling local objects.
When working with remote objects, you often want to find out when they
are no longer valid. There are three ways this can be determined:
- The {@link #transact transact()} method will throw a
{@link RemoteException} exception if you try to call it on an IBinder
whose process no longer exists.
- The {@link #pingBinder()} method can be called, and will return false
if the remote process no longer exists.
- The {@link #linkToDeath linkToDeath()} method can be used to register
a {@link DeathRecipient} with the IBinder, which will be called when its
containing process goes away.
|
