AIDL: How Android Apps Talk Across Process Boundaries

Recently got to implement AIDL on production, so thought of sharing the same in this article. Here’s a concise breakdown of why AIDL, what it actually is and how it works.

The Problem It Solves

Every Android app runs in its own sandboxed process. Two processes cannot share memory directly — you cannot just pass an object reference from your Activity to a Service running in a separate process. They live in completely different memory spaces. AIDL (Android Interface Definition Language) is Android’s solution: it lets you define a typed interface that both processes agree on, and the framework handles all the serialization and cross-process wiring for you.

How It Works in Three Parts

You write one .aidl file. At build time, the aidl compiler generates a Java class containing two things — a Stub (which the server implements) and a Proxy (which the client gets automatically). The Proxy looks like a normal local object to your client code, but under the hood it serializes your method arguments into a Parcel, ships them over the Binder kernel driver, and the Stub on the other side unpacks and dispatches them. The whole round-trip is invisible to both sides.

Step 1 — Define the contract in ISampleAidl.aidl

interface ISampleAidl {
    int sum(int a, int b);
}

Step 2 — Implement the Stub in your Service (server side)

class SampleService : Service() {

    private val binder = object : ISampleAidl.Stub() {
        // This runs in the SERVICE's process, not the caller's
        override fun sum(a: Int, b: Int): Int = a + b
    }

    override fun onBind(intent: Intent): IBinder = binder
}

Step 3 — Connect and call from the client

private var sampleService: ISampleAidl? = null

private val connection = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName, binder: IBinder) {
        // Returns the real Stub if same process, Proxy if cross-process
        sampleService = ISampleAidl.Stub.asInterface(binder)
    }
    override fun onServiceDisconnected(name: ComponentName) {
        sampleService = null
    }
}

// Bind to the service
bindService(Intent(this, SampleService::class.java), connection, BIND_AUTO_CREATE)

// Call it like a local method — it silently goes cross-process
val result = sampleService?.sum(3, 5)  // returns 8

That’s it. Three files, one interface, and Android handles everything in between.

Three Things to Never Forget

1. AIDL calls are synchronous and blocking. If you call one from the main thread and the remote process is slow, you will get an ANR. Always call from a background thread or a coroutine with a non-main dispatcher.

2. All data passed across must be Parcelable, not Serializable. The data gets flattened into a Parcel (Android’s binary transport format), and Serializable’s reflection-based approach won’t work here — it’s too slow and doesn’t integrate with the Parcel system.

3. Your Stub runs in a Binder thread pool, not the main thread. Multiple clients can call your service concurrently, which means your Stub implementation must be thread-safe. This is the most common gotcha in production AIDL code.

When Should You Actually Use It?

Reach for AIDL when you need a typed, multi-method interface between two processes — think a media playback service, a persistent background engine, or exposing functionality to third-party apps. For simpler one-way messaging, Messenger is lighter. For structured data sharing, ContentProvider is the right tool. AIDL is the right choice when you need the full power of a defined API contract across process boundaries.

Practical usecases

Every Android API we have ever used that touches system resources — LocationManager, NotificationManager, CameraManager — is just an AIDL Proxy under the hood. When we call getSystemService(), we get back a thin wrapper that sends the calls over Binder to a system service living in a completely separate process. AIDL is not an edge-case tool. It is the architecture of Android itself.