One-Way Calls

Introduction

By default, Binder transactions are synchronous. When a client makes an IPC call, the client's thread is put to sleep by the kernel and only wakes up when the server sends the reply. For certain architectures, especially asynchronous event dispatching, this blocking behavior is undesirable. The oneway keyword in AIDL fundamentally alters this behavior.

oneway Keyword in AIDL

Applying the oneway keyword to a method (or an entire interface) informs the Binder driver that the client does not expect a reply.

interface ILogger {
    // Synchronous call
    int getLogSize();

    // Asynchronous call
    oneway void writeLog(String message);
}

Because there is no reply, oneway methods must return void and cannot have out or inout parameters.

Non-Blocking Caller Semantics

When a client calls a oneway method, the Binder driver copies the transaction data into the target process's Binder buffer and immediately wakes the client thread. The client continues execution instantly, without waiting for the server to process the request.

This drastically improves client performance and prevents the client from hanging if the server process is busy, deadlocked, or unresponsive.

Thread Pool Usage with oneway

While oneway calls do not block the client, they still consume threads on the server side. However, the Binder driver handles oneway calls slightly differently to prevent a single spamming client from exhausting the server's thread pool.

For oneway calls targeting the same binder object, the kernel serialize the transactions. The second oneway call will not be dispatched to the server until the server finishes processing the first one. This guarantees ordering for asynchronous messages directed at a specific binder instance but means that long-running operations in a oneway method can delay subsequent oneway calls.

Limitations of oneway

1. No return values or exceptions: Since the client does not wait, it cannot receive return values. If the server throws a RemoteException during execution, the client will never know.
2. Buffer exhaustion: oneway transactions copy data into the server's binder buffer (which is limited, typically 1MB per process). If a client fires off massive amounts of data asynchronously faster than the server can process it, the server's binder buffer will fill up, resulting in a TransactionTooLargeException.
3. Ordering guarantees: Ordering is only guaranteed for calls made from the same client thread to the same remote IBinder object. Calls across different binder objects or from different client threads may arrive out of order.