Binder IPC & AIDL

Binder is Android's inter-process communication mechanism: a kernel driver (/dev/binder) plus user-space libraries (libbinder, libbinder_ndk, the Java Binder classes) that let one process call methods on an object in another process as if it were local. It provides object handles, one-copy data transfer, a thread pool, caller identity and death notifications. Almost every app-to-framework and framework-to-HAL call uses it.

• Performance: one data copy instead of two.
• Security: the kernel stamps each transaction with the caller's UID/PID, which cannot be forged.
• Object model: handles to remote objects act as capabilities and can be passed between processes.
• Lifetime: cross-process reference counting and death notifications.
• Built-in RPC semantics (method codes, replies, exceptions) and thread pool management.

AIDL (Android Interface Definition Language) describes an interface that can be called across processes. From an .aidl file the build generates a Java/C++/Rust interface, a server-side Stub and a client-side Proxy that handle all marshalling. It is used for app-to-app bound services, framework services and, as stable AIDL, for vendor HALs.

The Stub is the server half: an abstract class extending Binder that you subclass to implement the methods; its onTransact() unpacks incoming Parcels and calls your implementation. The Proxy is the client half: it wraps a remote IBinder and implements the same interface by packing arguments into a Parcel and calling transact(). Both are generated from the same .aidl file so their layouts match.

A Parcel is the container for one transaction's data: arguments on the way in, return value and exception status on the way out. Values are written and read sequentially in the same order. It can also carry Binder objects and file descriptors, which the driver translates for the receiving process. It is designed for IPC only and is not a stable storage format.

A oneway method (or interface) is asynchronous: the caller's transact() returns as soon as the driver queues the transaction, without waiting for the server to run it. There is no return value and server exceptions do not reach the caller. Calls to the same Binder object are delivered in order. It is used for callbacks, notifications and async HAL request/response patterns.

servicemanager is the Binder context manager on /dev/binder, reachable by every process at handle 0. Services register with addService(name, binder); clients get handles with getService(name) or waitForService(name), then call the service directly. It enforces SELinux rules for registration and lookup, validates VINTF declarations for HALs, and can start lazy services through init.

One. The receiving process has mmap'd a buffer from the driver. The driver copies the sender's Parcel data with copy_from_user() directly into physical pages that are mapped both in the kernel and (read-only) in the receiver, so the receiver reads it in place. Sockets and pipes need two copies. Large data can be shared with zero copies by passing a shared-memory file descriptor.

On one of the server process's Binder threads, not the main thread (unless the caller is in the same process, in which case it runs on the caller's thread). Multiple calls can therefore run concurrently, so the implementation must be thread-safe. If it needs to touch UI or main-thread state, it must post to a Handler.

It converts an IBinder into the typed interface. It calls queryLocalInterface(DESCRIPTOR): if the Binder is a local object in the same process, it returns that object directly so calls are plain method calls; otherwise it wraps the Binder in a new Stub.Proxy that performs IPC. It returns null for a null Binder.

IBinder.linkToDeath(recipient, flags) registers a DeathRecipient whose binderDied() is called when the process hosting that Binder dies. Clients use it to drop stale references and reconnect; servers use it to clean up state held for clients. It works because the driver knows when a process closes its Binder file descriptor.

A subclass of RemoteException thrown when you call a method on a Binder whose hosting process has died. The Binder handle is now useless; the client must obtain a new one after the service restarts. Robust clients catch it, and preferably register a death recipient to react before the next call.

They specify the direction of non-primitive parameters. in: data goes from client to server only (the default, and the only option for primitives). out: the server fills the object and it is copied back to the client. inout: copied both ways, costing twice as much. Use in unless you need the server to return data through the parameter.

Primitives, String, CharSequence, arrays, List and Map of supported types, Parcelable classes, other AIDL interfaces (passed as Binders), IBinder, ParcelFileDescriptor, and in structured AIDL, parcelables, enums and unions defined in .aidl. Stable AIDL disallows unstructured (hand-written) parcelables.

Call Binder.getCallingUid() and Binder.getCallingPid() inside the method (native: IPCThreadState::self()->getCallingUid()). The driver sets these from the sending process, so they cannot be forged. Use the UID for permission checks (enforceCallingPermission) because PIDs can be reused and are 0 for oneway calls.

Three separate Binder domains introduced with Treble. /dev/binder (servicemanager) is for framework and apps, and now also stable-AIDL HALs. /dev/hwbinder (hwservicemanager) carried HIDL HAL traffic between framework and vendor. /dev/vndbinder (vndservicemanager) is for vendor processes talking to each other. Separate domains keep system and vendor namespaces and policies apart.

HIDL was the HAL interface language introduced in Android 8.0 with Treble, using .hal files and hwbinder. Stable AIDL, supported for HALs from Android 11 and the standard from 13, replaced it: same Binder concepts, but one language and one transport for both framework and HAL interfaces. HIDL is deprecated and no new HIDL HALs are accepted.

It is thrown when a Binder transaction cannot be delivered because the receiving process's Binder buffer (about 1 MB, shared by all in-flight transactions) has no room for it. Typical causes are large Bundles in Intents, big saved instance state, or returning large lists or bitmaps. Fix by sending less (IDs instead of objects), chunking, or using shared memory or files passed by file descriptor.

It implements a bound Service whose onBind() returns an instance of the generated Stub, and declares the service in its manifest (usually exported and protected by a permission). Clients call bindService() with an intent and receive the Binder in ServiceConnection.onServiceConnected(), then call IFoo.Stub.asInterface(binder). Both apps need the same .aidl file.

The set of threads in a process that wait in the driver for incoming transactions and execute them. libbinder starts a main pool thread and the driver asks for more (BR_SPAWN_LOOPER) when all are busy, up to the configured maximum (15 extra by default, 31 for system_server). If all are busy, new calls wait.

Both are Binder. AIDL generates a typed Stub/Proxy with method codes, oneway, parcelables and versioning; incoming calls run on the Binder thread pool, so the implementation must be thread-safe. Messenger wraps a Handler: clients send Message objects (what, args, optional replyTo) and they are handled one at a time on that Handler's thread, so you get sequencing for free and a weaker schema. Use AIDL for a real service or HAL; use Messenger for a small message-oriented API. Neither replaces shared memory for large payloads.

The framework calls request methods on IRadioX (for example IRadioVoice.dial(serial, info)), which return immediately. The vendor later calls IRadioXResponse methods with the same serial to deliver the result, and calls IRadioXIndication methods for unsolicited events like call state changes. The framework registers its Response and Indication objects with setResponseFunctions().

Parcelable requires explicit (hand-written or generated) writeToParcel and CREATOR code, uses no reflection and is designed for fast IPC. Serializable is a Java marker interface that relies on reflection, creates many temporary objects and is much slower. Use Parcelable for anything passed through Binder or Intents.

1. Client calls proxy.add(2, 3); the Proxy writes the interface token and arguments into a Parcel.
2. BinderProxy.transact() → IPCThreadState::transact() queues BC_TRANSACTION and calls ioctl(BINDER_WRITE_READ); the client thread blocks.
3. The driver resolves the handle to the target node, checks SELinux, allocates a buffer in the target's mmap area, copies the data once, records the caller's UID/PID, and queues the work on an idle Binder thread (asking for a new thread if needed).
4. The server thread returns with BR_TRANSACTION; Stub.onTransact() checks the token, reads the arguments and calls the implementation.
5. The reply is written and sent with BC_REPLY; the driver copies it to the client and wakes it with BR_REPLY.
6. The Proxy reads the exception status and result and returns.

When a process opens Binder, libbinder mmaps about 1 MB of the device. The driver backs this area with physical pages allocated on demand and maps them both in kernel space and read-only in the process's user space. For a transaction to that process, the driver allocates a region of this area and does one copy_from_user() from the sender's buffer into it. Since the receiver already has those pages mapped, it reads the data directly with no second copy. The receiver later frees the region with BC_FREE_BUFFER.

A handle is an integer in the client process that refers to a binder_ref, which points to a binder_node owned by another process. When a Parcel contains a Binder object, it is written as a flat_binder_object. The driver rewrites it: a local object (BINDER_TYPE_BINDER) sent out becomes a handle (BINDER_TYPE_HANDLE) in the receiver, creating a node and reference as needed; a handle sent to the node's own process becomes the local object pointer again; a handle sent to a third process becomes that process's own handle. That is how a capability is passed safely.

The process sets a maximum with BINDER_SET_MAX_THREADS. When the driver has work for a process and no thread is waiting, and the number of spawned threads is below the maximum, it adds BR_SPAWN_LOOPER to a thread's return buffer. libbinder then creates a new thread that registers with BC_REGISTER_LOOPER and enters the loop. Threads started by the app itself use BC_ENTER_LOOPER. Pool threads are not destroyed when idle.

It happens when every Binder thread in a server process is busy, typically all stuck in the same slow path (a lock, disk I/O, a nested synchronous call to a HAL). New transactions queue in the driver, so callers block. Symptoms: many apps hang or ANR in BinderProxy.transactNative calls to the same service; server stack dumps show all Binder:pid_N threads in similar frames. Fix the slow path, make handlers fast, use async callbacks or oneway, and avoid nested blocking calls.

The generated Stub catches exceptions from the implementation. For a set of parcelable exception types (SecurityException, IllegalArgumentException, IllegalStateException, NullPointerException, UnsupportedOperationException, ServiceSpecificException, ...) it writes an exception code and message into the reply with writeException(); the Proxy's readException() rethrows it in the client. Other runtime exceptions are logged in the server and the client receives a generic failure. With oneway calls, nothing reaches the caller.

Pros: the caller never blocks on the server, which protects system_server when calling apps; ordering is preserved per Binder object. Cons: no return value or exception, so you need a callback to learn results or errors; async transactions can use only half of the target's buffer and a flood can fill it; calling PID is 0; the server executes oneway calls for one object serially, so a slow one delays the rest; and if the object is local, oneway runs synchronously.

For oneway transactions the driver does not keep a link to the sending thread (there is no reply to route back), and it deliberately reports sender PID as 0 because by the time the server processes the call the sender may have exited and its PID been reused. The UID is still delivered. Services must therefore use UID-based checks for oneway methods.

It resets the thread's calling UID/PID to the current process and returns a token holding the original identity. It is needed when a service, while handling a client call, performs work that should be checked against the service's own identity: calling another service, accessing its own content provider, sending a broadcast. Always pair it with restoreCallingIdentity(token) in a finally block; leaving the identity cleared is a privilege escalation bug.

A lazy service's interface is declared in an init.rc service entry with interface aidl <name> (and for HALs in the VINTF manifest) but it is not started at boot. When a client looks it up, servicemanager sets ctl.interface_start, init starts the matching service, and the service registers with registerLazyService. servicemanager tracks clients; when none remain, it notifies the service, which may unregister and exit. Mismatched names mean the start fails and clients never get the service.

checkService returns immediately with the Binder or null. getService historically retried for a few seconds before returning null (and may start lazy services). waitForService blocks until the service is registered, starting it if it is lazy and declared, and is the recommended call for HALs and services known to exist. isDeclared checks whether a VINTF service is declared without starting it.

SELinux checks happen in the driver and in servicemanager before any service code runs. binder_call controls which domains may send transactions to which; binder_transfer controls passing Binder objects; binder_set_context_mgr restricts who can become servicemanager. servicemanager checks add, find and list permissions against labels in service_contexts / hwservice_contexts. Denials appear as avc: denied and must be fixed with policy, not by disabling enforcement.

You write an fd into the Parcel (writeFileDescriptor or a ParcelFileDescriptor). It is encoded as a BINDER_TYPE_FD object. The driver installs a new file descriptor in the receiving process referring to the same open file description and rewrites the value in the Parcel. The receiver can then read the file or mmap the shared memory. This is how CursorWindow, SharedMemory, graphics buffers and pipes for large data are shared.

The first data written by a Proxy via writeInterfaceToken(DESCRIPTOR). It contains the StrictMode policy of the calling thread (so the server can apply it), a work-source UID for power attribution, a header identifying the system/vendor stability context, and the interface descriptor string. The Stub calls enforceInterface() to verify the descriptor matches, rejecting transactions meant for a different interface.

A framework class for servers that keep a list of client callback interfaces. It links to death on each registered callback and removes it automatically when the client dies, identifies callbacks by their underlying Binder (so the same client registering through different proxies is recognized), and provides safe iteration with beginBroadcast()/finishBroadcast() while calling out. Using a plain list leaks callbacks from dead clients and causes DeadObjectExceptions.

Register a DeathRecipient with linkToDeath(). In binderDied(), drop the stale proxy and any state tied to it, then (usually on a Handler, not the Binder thread) call waitForService() or rebind, re-register callbacks, and replay required state. For bound app services, ServiceConnection.onServiceDisconnected() and then onServiceConnected() fire automatically when the service restarts. RIL's handling of serviceDied is a real example.

Because the HAL is asynchronous: a request returns immediately and the answer arrives later on a separate Response interface. Many requests can be outstanding, and responses can arrive in any order. Each request gets a unique serial stored in RIL's request list; the response's RadioResponseInfo.serial identifies which RILRequest to complete, which caller Message to send, and which wakelock count to release.

Both are both. For requests (IRadioVoice), the vendor radio daemon is the server and RIL.java is the client. For IRadioVoiceResponse and IRadioVoiceIndication, the framework (phone process) is the server and the vendor daemon is the client. The framework passes its Response and Indication Binder objects to the vendor with setResponseFunctions(), which is possible because Binder objects can be sent inside Parcels.

Solicited: framework-initiated requests (dial, get signal strength) with a serial; the vendor answers on the matching Response callback, completing the RILRequest; RIL holds a wakelock while they are pending. Unsolicited: modem-initiated events (call state change, network state change, incoming SMS, NITZ) delivered on the Indication interface; RIL converts them to Messages and notifies subscribers via RegistrantList. Some indications require an acknowledgement so the vendor can release its wakelock.

Dialer app → Telecom in system_server (ITelecomService); Telecom → TelephonyConnectionService in com.android.phone (IConnectionService, with IConnectionServiceAdapter callbacks); phone process → vendor radio daemon (IRadioVoice plus Response/Indication), or for VoLTE, vendor ImsService (IImsCallSession); Telecom → in-call UI (IInCallService). Other apps reach the phone process through ITelephony via TelephonyManager.

Running m <name>-freeze-api copies the current interface into aidl_api/<name>/<N>/ with a hash, making version N immutable. The build then checks that the snapshot never changes and that the next version is a compatible extension. Devices implementing version N can be relied on by any future framework that supports N.

Allowed: adding methods at the end of an interface, adding fields at the end of parcelables (with sensible defaults), adding enum values, adding new types and interfaces. Not allowed: removing, renaming the wire meaning of, or reordering methods and fields; changing parameter or return types; changing the oneway status. Method codes and field positions are part of the wire format.

Java is for framework and app code. CPP uses the platform-internal libbinder, whose ABI is not stable, so it is only for code built with the platform. NDK uses libbinder_ndk, a stable C API with C++ wrappers, required for vendor code and APEX modules that must keep working when the system updates. Rust uses the binder crate on top of libbinder_ndk. Stable HALs are typically NDK or Rust on the vendor side and Java or NDK on the framework side.

The driver could not deliver a transaction. Most often the receiver's Binder buffer is full (a large payload, many concurrent transactions, or a slow receiver not freeing buffers), which surfaces as TransactionTooLargeException. It can also mean the target died (DeadObjectException) or the target is frozen (BR_FROZEN_REPLY for a sync call). The log shows the parcel size, which helps separate "one huge call" from "buffer already full".

The Binder driver's reply to a synchronous caller when the target process is frozen by the cached-apps freezer. The call is not delivered and the target is not unfrozen. The caller sees a failed transaction. Oneway calls are queued instead. AMS unfreezes the process later when it becomes important (activity, broadcast, bind), not because of the sync call. The freezer was opt-in in Android 11 and default-on later.

adb shell am trace-ipc start, exercise the app, then am trace-ipc stop --dump-file /data/local/tmp/ipc.txt; the file lists Binder calls with Java stack traces grouped by interface and count. Perfetto with Binder tracing shows each transaction on a timeline with latency. StrictMode can flag Binder calls on the main thread in debug builds.

Each binder_thread keeps a transaction stack. If thread T1 in process A calls process B, and B's handler thread T2 calls back into A synchronously while handling it, the driver sees that T2's current transaction originated from T1 and delivers the callback to T1 itself (which is blocked waiting for its reply) instead of to a random pool thread in A. T1 processes the nested call and returns, then continues waiting for its original reply. This avoids deadlocks from reentrancy and preserves thread-local state, but callbacks landing on other threads needing the same locks can still deadlock.

When a transaction is delivered, the driver temporarily sets the server thread's scheduling priority to match the caller's (nice value, and real-time policy/priority if the node permits RT inheritance, which HALs like audio use). After the reply, the server thread's priority is restored. This prevents a high-priority caller (for example the UI thread or an audio thread) from being blocked behind a low-priority server thread, a form of priority inversion. oneway calls do not inherit priority from the caller in the same way; they use the node's minimum priority.

The driver tracks strong and weak references per binder_ref (in clients) and aggregates them on the binder_node (in the owner). User space sends BC_INCREFS/BC_ACQUIRE/BC_RELEASE/BC_DECREFS as proxies are created and destroyed; the driver tells the owner with BR_ACQUIRE/BR_RELEASE etc. so it can keep the local object alive while remote references exist. In Java, BinderProxy finalization and GC drive releases; in native code, sp<IBinder> smart pointers do. Leaked proxies keep remote objects alive.

Each node has an async todo list. If a oneway transaction for that node is already being processed, later oneway transactions for the same node wait in that list instead of being given to another thread, so they are executed serially and in order. When the server frees the buffer of the current async transaction, the next is dispatched. This is why one slow oneway method delays all later oneway calls on the same object, while different objects in the same process can proceed in parallel.

oneway transactions consume buffer space in the server until processed. If a client sends them faster than the server handles them, async space (half the buffer) fills, and further async transactions fail; synchronous callers can also be affected if the buffer is exhausted. The driver detects suspicious async senders and logs "pid X spamming oneway?" when one process uses a large share of async space; newer kernels can flag such transactions. Services should rate-limit, coalesce updates, or switch to synchronous calls or shared memory for bulk data.

Java Binder objects have a native peer (JavaBBinder, a BBinder subclass) created lazily when the object is first sent across processes. Incoming transactions arrive on a native Binder thread in BBinder::transact(), which calls into Java via JNI (Binder.execTransact() → onTransact()). On the client side, a BinderProxy Java object wraps a native BpBinder; transact() goes through JNI to BpBinder::transact() → IPCThreadState::transact(). Java Parcels wrap native Parcel objects.

libbinder tags each Binder object with a stability level: local (same partition), vendor, system, or VINTF. A Binder marked with @VintfStability may be passed across the system/vendor boundary; a platform-internal (system-local) Binder must not be sent to vendor processes, and vice versa, because their interfaces are not stable. libbinder checks this when objects are sent or used, and interface tokens include a system or vendor header. This enforces Treble rules at runtime, not just at build time.

1. Add the method at the end of the interface in the "current" version and any new parcelable fields at the end.
2. Freeze a new version (N+1) and update the framework compatibility matrix to accept both N and N+1.
3. In the framework, check getInterfaceVersion() on the HAL proxy; call the new method only when the version is at least N+1, else use a fallback path.
4. Vendors implementing N continue to work; those upgrading implement N+1 and bump their VINTF manifest version.
5. Test both combinations in VTS/CTS.

Stable (structured) parcelables are written with a size prefix. A reader reads the fields it knows, then uses the size to skip any trailing unknown fields written by a newer version. A newer reader receiving an older, shorter parcelable reads the fields that are present and leaves the rest at their declared defaults. This is why fields may only be appended and why defaults matter.

A minimal call involves two system calls (send and receive), two context switches, one copy each way, marshalling and unmarshalling, and waking a server thread: on the order of tens of microseconds on modern hardware. That is fine for occasional calls but expensive in tight loops (for example calling getPackageInfo thousands of times, or per-frame calls). Batch requests, cache results on the client, use callbacks instead of polling, and use shared memory or FMQ for streaming data.

Fast Message Queue is a HAL-level ring buffer in shared memory, set up once over Binder (the descriptor is passed in a call) and then used without Binder for each message. Producers and consumers read and write directly, optionally using an event flag (futex) to wake each other. It is used for high-rate, low-latency data such as audio, sensors, and neural network execution, where a Binder call per message would add too much overhead.

Before freezing a process, AMS asks the driver (BINDER_FREEZE) to freeze its Binder state. While frozen, a synchronous transaction fails immediately with BR_FROZEN_REPLY; the caller gets an error and the target is not unfrozen. Oneway transactions are queued until AMS unfreezes the process because it became important again (activity, broadcast, bind), and can fail if the async buffer fills. If a process is in the middle of a Binder transaction, freezing is deferred. The driver can report sync_recv/async_recv via BINDER_GET_FROZEN_INFO so AMS knows traffic arrived; that is telemetry, not an automatic unfreeze.

Each Binder object an app sends to system_server (such as a listener) creates a BinderProxy in system_server. A buggy app that registers listeners in a loop without unregistering can create tens of thousands of proxies, exhausting memory and driver resources. system_server tracks proxies per UID and, above a high watermark (thousands), logs and kills the offending app. It protects the whole system from one app's leak.

Binder requires a thread pool, and fork() in a multithreaded process copies only the calling thread, leaving locks and driver state inconsistent in the child. Zygote therefore stays single-threaded and receives fork commands over a Unix socket. After fork and specialization, the child opens /dev/binder itself (ProcessState), mmaps its buffer and starts its own Binder thread pool in onZygoteInit(), so it has a fresh, clean Binder state.

A strong reference keeps the remote object alive; a weak reference only keeps the node identity valid and can be promoted to strong if the object still exists. Weak references let clients hold a handle without forcing the service object to stay alive (for example caches, or death-notification bookkeeping). libbinder's sp/wp mirror this. For most Java code only strong references matter.

Generated Java stubs for versioned interfaces include getInterfaceVersion() and getInterfaceHash() methods (reserved transaction codes near LAST_CALL_TRANSACTION). A client can call these to determine what the server implements. The generated Proxy can also have a default implementation set with setDefaultImpl(), which is called when the server returns UNKNOWN_TRANSACTION for a method it does not implement, giving graceful fallback.

A client sends BC_REQUEST_DEATH_NOTIFICATION for a handle with a cookie. When the owning process exits, the kernel releases its binder_proc (on fd close), marks its nodes dead, and for every reference with a registered death notification queues BR_DEAD_BINDER to that client process. A client thread picks it up, libbinder calls the registered recipients (binderDied), and acknowledges with BC_DEAD_BINDER_DONE. Any transaction in flight to the dead process returns BR_DEAD_REPLY to its caller.

Yes. A synchronous callback from the server to the waiting client is routed to the client thread that is blocked in the call (the recursion rule), which executes it and returns. The danger is when the callback needs a lock the client thread already holds while calling, or when it is delivered to a different thread (for example a oneway callback) that then waits on that lock. Design rule: do not hold locks while making outgoing Binder calls, and treat callbacks as reentrant.

Running HALs in separate processes over Binder gives a stable IPC contract instead of a C ABI, so system and vendor can be built and updated separately. It also isolates faults (a crashing HAL does not crash system_server, and death recipients allow recovery), applies least privilege (each HAL has its own SELinux domain), and lets the same interface be used from Java, C++ and Rust. The cost, per-call IPC overhead, is mitigated with FMQ and shared memory for high-rate data.

// IListener.aidl
oneway interface IListener {
    void onEvent(int code);
}
// IService.aidl
interface IService {
    void register(IListener l);
    void unregister(IListener l);
}

The client implements IListener.Stub and passes it to register(); the driver turns it into a proxy in the server. The server stores it in a RemoteCallbackList and calls onEvent() on it later. Making the callback interface oneway ensures a slow client cannot block the server.

Identify which interface they call from the Java frames (for example IActivityManager or IPackageManager). Look at the system_server stacks in the same ANR dump: find Binder threads handling those calls and see what they wait on, typically a global service lock ("waiting to lock ... held by thread N"). Follow thread N: often it holds the lock while doing I/O or an outgoing call to a HAL or app. Check whether all 31 Binder threads are busy (pool exhaustion). Fix the lock holder's slow path; the apps are victims.

1. Reproduce and capture a Perfetto trace with Binder (binder_driver) and scheduling events.
2. Find the slow transaction slice in the client, follow the flow to the server's reply slice.
3. Examine the server thread during that time: running (CPU-heavy work), sleeping on a lock (who holds it?), waiting on I/O, or making its own nested Binder call.
4. Check if the transaction waited before a server thread picked it up (pool exhaustion) or if the server thread was runnable but not scheduled (priority, CPU contention).
5. Fix accordingly and add latency metrics or a regression test.

The Intent extras (a Bundle) are too large, often a bitmap, a large list, or a big serialized object. Measure the Bundle size (for example by parceling it and checking dataSize()). Fix by passing an ID or URI and loading the data in the target from a repository, database, file or content provider, and by not storing large data in saved instance state. If it happens in onSaveInstanceState, move large state to a ViewModel or persistent storage.

The framework client is holding a stale proxy from before the restart and never re-acquired the service. It either did not register a death recipient or its binderDied() handler does not reconnect. Fix: linkToDeath on the HAL binder; in binderDied(), clear the proxy, fail or retry pending requests, call waitForService() to get the new instance, re-register callbacks (for the Radio HAL, call setResponseFunctions() again), and restore required state.

Not necessarily. serviceDied means the vendor radio HAL process died, which RIL detects through its death recipient. The modem (baseband) might be fine, or a modem subsystem restart might have caused the daemon to exit. Check for modem crash or subsystem-restart markers and ramdump logs at the same timestamp, and look for the HAL daemon's tombstone. RIL itself completes all pending requests with RADIO_NOT_AVAILABLE, resets its proxies, and re-acquires the HAL when it comes back.

Run service list | grep <name> and check if the process is running. Look in logcat for servicemanager errors such as "not declared in VINTF manifest" or SELinux avc: denied { add }/{ find }, and init errors about ctl.interface_start. Verify the instance name matches exactly across the VINTF manifest, init.rc interface line and the registration call, that the service has a service_contexts label, and that the framework compatibility matrix includes the HAL version.

Read the denial: avc: denied { call } for scontext=u:r:mydaemon:s0 tcontext=u:r:system_server:s0 tclass=binder. Add the minimal policy: use macros like binder_use(mydaemon), binder_call(mydaemon, target_domain), and allow find on the target service's label (allow mydaemon foo_service:service_manager find;). Respect Treble neverallow rules (vendor domains cannot call arbitrary system services). Never switch to permissive in production; verify with a CTS/VTS run.

A system_server service took its main lock and then made a synchronous Binder call to a vendor HAL that hung (HAL deadlock, hardware timeout, or a HAL waiting on system_server). Other threads needing the lock blocked until the watchdog timeout, so system_server was killed. Get the HAL process stacks (debuggerd) from the bugreport to find why it hung. Fix both sides: the HAL must not block indefinitely (timeouts), and the framework must not hold global locks across HAL calls (call outside the lock, or use async/oneway with callbacks).

Take stack dumps of both processes during the hang: typically thread A1 holds lock LA and is in a synchronous call to B; B's handler thread B1 holds LB and is in a synchronous call to A, where an A pool thread waits for LA. The debugfs transactions file shows the transaction chains between their threads. Prevent by never holding locks during outgoing calls, defining a strict call direction (for example the system calls vendors only asynchronously), and using oneway callbacks posted to a Handler.

The framework is calling a method added in a newer HAL version, but the vendor implements an older version that does not have that transaction code. The framework should check getInterfaceVersion() before calling newer methods and fall back if needed. Confirm the vendor's declared version in the VINTF manifest and dumpsys/lshal-equivalent output, and fix the framework code path or update the vendor implementation.

Check whether handlers do slow work on Binder threads, exhausting the pool. Move long work to a dedicated executor and respond asynchronously through a callback interface (or return a future-like handle), keeping Binder methods short. Make fire-and-forget methods oneway. Reduce lock scope, avoid nested synchronous calls, and consider raising the pool size only if work is genuinely parallel. Add metrics on handler latency and queue depth.

The app repeatedly registers new callback Binder objects (for example on every resume) without unregistering. Each creates a proxy and a death recipient in system_server; when it crosses the per-UID proxy limit, system_server kills the app to protect itself. Confirm with logs about too many Binder proxies and dumpsys meminfo system_server object counts. Fix by registering once, unregistering in the matching lifecycle callback, and using the same callback object.

When client and server are in the same process, asInterface() returns the real object and there is no marshalling: objects are passed by reference, so the server can mutate the client's objects and in semantics are not enforced; oneway methods also run synchronously; and calling identity is the process's own. Remote calls copy data through Parcels. Write implementations that do not rely on either behaviour, and test the remote path.

Find the request's serial in the radio log (RIL logs request and response with serials). Check whether the vendor daemon received it (vendor logs), whether it sent a modem command and got an answer (modem logs), and whether it called the Response method. Confirm the Response object is still registered (a HAL restart without setResponseFunctions would lose callbacks). RIL's wakelock timeout will fire if the response never arrives; look for that log too. Fix the layer where the chain breaks.

Enable StrictMode or use Perfetto to find binder transaction slices on the main thread during frames; am trace-ipc lists calls with stack traces. Common offenders: PackageManager queries, getSystemService calls that do IPC, content provider queries, and account or settings reads. Fix by moving calls to background threads, caching results (for example package info that does not change), batching queries, and registering for change callbacks instead of polling.

oneway calls to the same client Binder object execute serially, so if the client's callback implementation is slow, all later callbacks queue behind it. The client's async buffer can fill, causing failed transactions. Also, a frozen (cached) client does not run oneway work until AMS unfreezes it; a sync call to that client fails with BR_FROZEN_REPLY instead of thawing it. Fixes: keep client callbacks tiny and post work to a Handler, coalesce updates on the server (send only the latest state), and avoid sending high-rate events per callback.