Binder IPC in AOSP

Android is a multi-process operating system. Each app runs in its own sandboxed process, and system services run in separate processes too. But apps constantly need to talk to system services - to open the camera, send a notification, or check location. Binder is the IPC mechanism that makes all of this possible.

Why Not Use Standard Linux IPC?

Linux provides sockets, pipes, shared memory, and signals for IPC. Android avoided these for app-to-service communication because they lack identity verification (you can't confirm who is on the other end), they're hard to manage at scale, and they don't integrate well with object-oriented APIs. Binder solves all three problems.

How Binder Works

  Process A (Client)         Process B (Server)
  ┌─────────────────┐        ┌─────────────────┐
  │   App / caller  │        │  System Service │
  │                 │        │ (e.g. Camera    │
  │  [Proxy object] │        │  Service)       │
  └────────┬────────┘        └────────▲────────┘
           │  write to /dev/binder    │
           ▼                          │
  ┌───────────────────────────────────┴─────────┐
  │              Binder Driver                  │
  │           (/dev/binder in kernel)           │
  │  copies data, identifies caller UID/PID     │
  │  dispatches to correct server thread        │
  └─────────────────────────────────────────────┘

• ▸1. Client calls a method on a Proxy object (local stub that looks like the real service)
• ▸2. Proxy serializes the call into a Parcel (data packet) and writes it to /dev/binder
• ▸3. Binder driver copies the Parcel to the server process (one efficient copy vs shared memory risks)
• ▸4. Binder driver also attaches the caller's UID and PID - the server can verify identity
• ▸5. Server deserializes the Parcel, executes the method, and writes the response back
• ▸6. Client's thread unblocks and reads the response

Key Binder Concepts

• ▸IBinder - the base interface every Binder object implements
• ▸Parcel - the serialization container for passing data across processes (supports ints, strings, file descriptors, nested Parcelables)
• ▸ServiceManager - the DNS of Binder; services register by name, clients look up by name to get a reference
• ▸Death recipient - client can register a callback to know if the server process crashes
• ▸Binder thread pool - each process has a pool of threads waiting for incoming Binder calls (default: 15 threads)

Binder Domains

• ▸/dev/binder - standard Binder used by apps and framework services
• ▸/dev/hwbinder - used exclusively by HIDL HAL processes (being phased out with AIDL migration)
• ▸/dev/vndbinder - used for vendor-to-vendor IPC, keeping vendor services separate from system services