In-depth Analysis of Android Binder IPC Mechanism (Android 14 & Kernel 6.1)

This article provides a comprehensive walkthrough of the Android Binder inter‑process communication (IPC) mechanism, focusing on the Android 14 source tree and Linux kernel 6.1. It explains how Binder spans the entire Android stack—from the application layer through the native frameworks down to the kernel driver—making the communication flow complex.

The analysis concentrates on the native and kernel layers, assuming readers are already familiar with Binder architecture and its core data structures. It begins with an overview of the Binder client/server model, where the ServiceManager acts as a name server, and highlights the two main operations: service registration (addService) and service lookup (getService).

For service registration, the article details the client‑side steps: constructing a Parcel , writing the service name and object, invoking writeStrongBinder (which calls flattenBinder ), and sending the data to the kernel via ioctl . It then follows the kernel path, describing how binder_ioctl_write_read parses the command buffer, creates a binder_node , and generates a binder_ref with a handle that is returned to the ServiceManager.

The server‑side flow is traced from the ServiceManager’s driver notification, through binder_thread_read , to the handling of BR_TRANSACTION commands. The article shows how the ServiceManager extracts the IBinder object, registers it in the mNameToService map, and prepares the response.

When a client requests a service via getService , the process mirrors registration but without sending a service object. The ServiceManager looks up the service name, retrieves the stored IBinder (a BpBinder proxy), and returns a flat_binder_object with type BINDER_TYPE_HANDLE . The kernel then creates a corresponding binder_ref for the client, updates reference counts, and sends a BR_REPLY back to the client.

On the client side, the reply is processed by IPCThreadState::executeCommand , which reconstructs the Parcel , creates a new BpBinder using the received handle, and finally provides the caller with a usable proxy to invoke remote methods.

The article concludes with a summary diagram that visualizes the entire Binder transaction flow across native and kernel layers, emphasizing the conversion of integer handles to remote BBinder objects and the role of the driver in mediating these exchanges.