AOSP Notes Help

IPC

Android runs apps in separate Linux processes.

This is done for security, stability, and sandboxing.

Which means if Process A wants to talk to Process B, it must use Inter-Process Communication (IPC).

Binder

It is core IPC mechanism of Android System.

Main Components

1. Client Process

The process requesting a service.

For example: App → wants to call LocationManager

2. Proxy

Client-side object.

  • It:

    • looks like a normal Java object

    • secretly sends IPC requests.

3. Binder Driver

  • It handles:

    • process communication

    • thread management

    • message passing

4. Stub

Server-side Binder object.

  • It:

    • receives requests

    • unmarshals data

    • calls actual service method

5. Server Process

The process that implements the service.

For example: system_server → runs LocationManagerService

Client App | | call method v Proxy | | Parcel data v Binder Driver (/dev/binder) | v Stub (Server side) | v Actual Service | v Return result (using binder driver)

Binder thread pool

Each Binder service has a thread pool.

Multiple apps may call the same service simultaneously.

App1 → request App2 → request App3 → request

Binder driver dispatches them to threads like:

system_server Thread1 → handle App1 Thread2 → handle App2 Thread3 → handle App3

This prevents blocking.

Zero Copy Optimization

Binder uses shared memory instead of copying data repeatedly.

Typical IPC:

Process A → Kernel → Process B (copy copy copy)

Binder:

Process A | shared memory | Process B

Much faster.

AIDL

AIDL (Android Interface Definition Language) is used when two processes need to talk to each other using Binder IPC.

AIDL defines what methods can be called remotely.

Think of it like a contract between client and service.

Example contract: ICalculator.aidl

interface ICalculator { int add(int a, int b); }

This file is not used directly. During build, AIDL compiler generates Binder code.

Android build system runs:

aidl ICalculator.aidl

This generates a Java interface like:

ICalculator.java

Structure:

ICalculator | |--- Stub (Server side) | |--- Proxy (Client side)

Service process implements the Stub.

public class CalculatorService extends Service { private final ICalculator.Stub binder = new ICalculator.Stub() { @Override public int add(int a, int b) { return a + b; } }; @Override public IBinder onBind(Intent intent) { return binder; } }

Stub receives IPC calls. Stub is the server-side Binder implementation.

Client binds to the service. Proxy is the client-side implementation.

ServiceConnection connection = new ServiceConnection() { public void onServiceConnected(ComponentName name, IBinder service) { ICalculator calculator = ICalculator.Stub.asInterface(service); int result = calculator.add(5, 3); } public void onServiceDisconnected(ComponentName name) {} };

Full flow:

Client Process -------------- calculator.add(5,3) | v Proxy.add() | write to Parcel | Binder.transact() | v Kernel Binder Driver -------------------- copy transaction switch process | v Service Process --------------- Stub.onTransact() | read Parcel | add(5,3) | write reply | v Kernel Binder Driver | v Client Process -------------- reply.readInt() result = 8

in, out, inout

They define data direction between client and service.

in: (Default) Client → Service

void sendData(in User user);

out: Service → Client

void getData(out User user);

inout: Both directions.

void modifyUser(inout User user);

oneway

Normal AIDL calls are synchronous.

Meaning:

client waits for response

Example:

int add(int a, int b);

But if you write:

oneway void sendEvent(int id);

Then:

client → fire request client DOES NOT wait

This becomes asynchronous.

Used for notifications / events.

oneway methods cannot return values, because the client doesn't wait.

What happens if a process dies?

Binder detects process death.

Client can register:

linkToDeath()

Why is AIDL faster than sockets?

  • Because Binder:

    • uses shared memory

    • avoids heavy copying

    • uses kernel driver optimized for IPC

Is AIDL required for Binder?

No.

You can implement Binder manually using:

Binder IBinder Parcel onTransact()

AIDL just generates the boilerplate.

Messenger IPC

Messenger is a simpler wrapper around Binder.

Instead of defining interfaces, it sends Messages using Handlers.

Good for simple request-response communication.

Architecture:

Client | Messenger | Binder | Handler | Service

Service Handler:

Handler handler = new Handler(msg -> { if (msg.what == 1) { Log.d("MSG","Hello"); } });

Messenger:

Messenger messenger = new Messenger(handler);

Client sends:

Message msg = Message.obtain(); msg.what = 1; messenger.send(msg);

Limitations

  • sequential processing

  • slower than AIDL

Content Providers

Used for structured data sharing across apps.

Example:

Contacts Media Settings

Architecture:

App A | ContentResolver | Binder IPC | ContentProvider | Database

Broadcast IPC

Used for system-wide event communication.

Sockets

Used mainly by native services.

Ashmem

Binder has size limits (~1MB).

For large buffers Android uses: Ashmem (Android Shared Memory)

Architecture:

Process A | Shared Memory Region | Process B
Last modified: 19 March 2026
Android Boot ProcessSystem Service