Why Android Uses Binder: Deep Dive into Its IPC Architecture

Binder is Android's inter‑process communication (IPC) framework that connects components across processes. It sits between the application layer, the IPC layer, and the Linux kernel, with three main entities: binder client, binder server, and the service manager.

Android needed a dedicated IPC framework because traditional kernel mechanisms (pipes, sockets, shared memory, etc.) could not satisfy the object‑oriented, component‑based nature of Android apps. Binder provides a C/S model that abstracts process boundaries, allowing developers to invoke services as if they were local calls.

Key motivations for Binder include:

Rich IPC framework: Supports thread‑pool management, automatic reference‑count tracking, and complex object lifecycles across processes.

Performance: Performs a single memory copy per transaction, avoiding the double‑copy overhead of many traditional IPC mechanisms, while still balancing the benefits of shared memory.

Stability: Limits each process to 1 MiB of Binder memory, preventing unbounded memory consumption and providing death‑notification to clean up crashed services.

Security: Enforces sandbox isolation using UID/PID checks in the binder driver, ensuring only trusted services can register and that client requests are validated.

To manage object lifetimes, the kernel driver introduces binder ref and binder node structures, which track references and enable safe cross‑process object handling.

Security checks are performed in the binder driver, which validates the UID of the caller against the service manager before allowing a transaction. This prevents malicious apps from accessing system services or user data.

The software stack for Binder consists of several layers. Java applications go through the Java layer, JNI, and the native IPC layer, while C++ native apps interact directly with BpBinder and BBinder objects. The overall software structure is illustrated below.

Binder communication uses a set of command and response codes. Common command codes include BC_TRANSACTION (request), BC_REPLY (response), and reference‑count commands BC_INCREFS / BC_DECREFS. Corresponding response codes are BR_TRANSACTION, BR_REPLY, and BR_TRANSACTION_COMPLETE. BC_TRANSACTION: Binder proxy requests a service. BC_REPLY: Binder entity replies to a request. BC_INCREFS / BC_DECREFS: Manage reference counts of binder objects. BR_TRANSACTION: Driver forwards a transaction to the target object. BR_REPLY: Driver notifies that a reply has been sent. BR_TRANSACTION_COMPLETE: Driver confirms receipt of a transaction or reply.

During a transaction, the driver allocates a shared buffer that maps both kernel and user space, allowing the client to copy data directly into kernel memory, thus eliminating an extra copy.

Application‑level data is encapsulated in flat_binder_object structures, which contain a header indicating the object type (local, remote, or file descriptor), a pointer or handle, and a cookie for local objects.

When an app registers a service, it sends a transaction containing both the service name (e.g., "xxx service") and the associated binder object. If a client later requests the service, the transaction carries the remote binder handle instead of a local object.

Binder frames consist of a protocol code (e.g., BC_TRANSACTION) followed by protocol‑specific data. The transaction data includes destination, sender PID, UID, and a buffer that holds the application payload.

Understanding this overall framework prepares readers for the next article, which will explore concrete Binder communication scenarios and driver data structures.