There are several techniques to achieve IPC (Inter-process communication) like files, sockets, signals, pipes, message queues, semaphores, shared memory, etc. Binder is an Android-specific IPC mechanism, which enables an RPC (remote procedure call) mechanism between the client and server processes. Client process can execute remote methods in the server process as if they were executed locally.

Binder Characteristics

  • It has a distributed architecture.
  • The goal is process and IPC, not cross-network communication.
  • Supports multithreaded programming.
  • It can support multiple operating system platforms. Binders can be implemented and used on these different platforms.
  • Good hardware scalability. The requirement for hardware is very low, which is in line with the actual situation of Android.

Binder Implementation

A process cannot access another process’s memory, however kernel has control over all processes and therefore can expose an interface that enables IPC. Binder interface /dev/binder device, is implemented by the Binder kernel driver. All the IPC calls go through Binder kernel driver.

Binder Architecture in Android

Android 8 onwards supports following three IPC domains:

IPC DomainDescription
/dev/binderIPC between framework/app processes with AIDL interfaces.
/dev/hwbinderIPC between framework/vendor processes with HIDL interfaces.
IPC between vendor processes with HIDL interfaces
/dev/vndbinderIPC between vendor/vendor processes with AIDL Interfaces

Binder driver manages part of the address space of each process. The Binder driver-managed chunk of memory is read-only to the process, and all writing is performed by the kernel module. When a process sends a message to another process, the kernel allocates some space in the destination process’s memory and copies the message data directly from the sending process. It then queues a short message to the receiving process telling it where the received message is. The recipient can then access that message directly (because it is in its own memory space).

Higher-level IPC abstractions in Android such as Intents (commands with associated data that are delivered to components across processes), Messengers (objects that enable message-based communication across processes), and ContentProviders (components that expose a cross-process data management interface) are built on top of Binder.

Service Manager

Service Manager is a daemon process to manage Server and provide Client with the ability to query the Server interface.

The ServiceManager is the main process, which manages all the services of the system. It provides the functionality to register and find the corresponding services. It works directly with the binder driver for required IPC. Following is the init.rc script.

service servicemanager /system/bin/servicemanager
    class core animation
    user system
    group system readproc
    critical
    onrestart restart apexd
    onrestart restart audioserver
    onrestart restart gatekeeperd
    onrestart class_restart --only-enabled main
    onrestart class_restart --only-enabled hal
    onrestart class_restart --only-enabled early_hal
    task_profiles ServiceCapacityLow
    shutdown critical

Binder IPC

Using binder IPC framework, two processes can communicate each other and send or receive data between the processes. Framework enables a remote invocation of the methods in other processes. A client process communicate to another server process and can run the methods in other process as it is done locally and can get the required data from the server process. Binder mechanism achieves inter process communication using IOCTL (input/output control) messages with Linux kernel binder driver.

Binder IPC

Interfaces of new services are describe in a high level language. In the case of framework application, descriptions are written with the AIDL language. While hardware services developed by vendors, have interface descriptions written in HIDL language. Theses descriptions are compiled into Java/C++ files where parameters are de/serialized using Parcel component. Generated code contains two classes, a Binder Proxy and a Binder Stub. The proxy class is used to request a distant service and the stub to receive incoming call as described on the following diagram.

Binder IPC Workflow
Binder IPC Workflow