The client thread calling transact is blocked by default until onTransact has finished
executing on the remote thread. Transaction data consists of android.os.Parcel ob‐
jects, which are optimized to be sent across processes via the Binder . Arguments and
|return values are transferred as Parcel objects. These can contain literal arguments or
custom objects that implement android.os.Parcelable —an interface that defines
marshalling and unmarshalling of data in a more efficient way than a Serializable .
The onTransact method is executed on a thread from a pool of binder threads, discussed
in “Binder Threads” on page 30. This pool exists only to handle incoming requests from
other processes. It has a maximum of 16 threads, 2 so 16 remote calls can be handled
concurrently in every process. This requires the implementations of the calls to ensure
thread safety.
IPC can be bidirectional. The server process can issue a transaction to the client process
and reverse the flow: the former server process becomes the client and executes a trans‐
action on another binder implemented in the former client process, whose own binder
threads handle the processing. Hence, a two-way communication mechanism between
two processes can be established. As we will see, this mechanism is important to enable
asynchronous RPC.
If the server process starts a transaction, calling transact to send
a request to the client process while executing onTransact , the
client process will not receive the incoming request on a binder
thread, but on the thread waiting for the first transaction to finish.
Binders also support asynchronous transactions, which you can specify by setting IBin
der.FLAG_ONEWAY . With that flag set, the client thread will call transact and return
immediately. A binder will continue calling onTransact on the binder thread in the
server process, but cannot return any data synchronously to the client thread.