Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
Binder is a system for interprocess
communication that lets two processes on an Android-powered device
communicate. Binder provides a means to execute function calls in another
process that is completely transparent to the caller.
In binder terms, the calling process is considered the client and its
endpoint is called the binder proxy or proxy. Conversely,
the process being called is the server and its endpoint is called the
binder node or node.
Each node can expose and implement its own interface. And, using a proxy, the
client can execute methods on a node interface as though invocation was a
local function call. The following example shows a method being invoked:
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
Assume that the client calling foo() is running in process A and the server
implementing foo() is running in process B. Figure 1 shows how this call is
executed:
Figure 1. Binder call execution.
To execute a method in another process, as shown in figure 1,
the following occurs:
The client code in process A invokes the proxy code in process A. The proxy
code in process A creates a transaction containing the following items:
An identifier for the node
An identifier for the foo() method on the node
A buffer containing a copy of the arguments a and b
The transaction is submitted to the binder kernel driver.
The binder kernel driver determines that process B hosts the node.
The kernel copies the entire transaction into process B's address space.
The kernel finds a thread in process B to handle the transaction and passes
the transaction to it.
The thread unpacks the transaction, finds the node, and sends the transaction to the node object.
The node object obtains the function identifier from the transaction,
unpacks a and b from the transaction buffer, and stores a and b in
local variables.
The node object calls foo(a, b) on the server code in process B.
The result of the call is returned in a reply transaction, which is passed
to the kernel driver and then back to the calling proxy in process A.
The proxy returns that result to the caller in process A.
Binder use cases
Binder can be used in a variety of scenarios where communication between
software in different processes must occur. For example:
A camera app uses binder to communicate with the camera server in
another process. The camera server then uses binder to communicate with the
camera HAL in another process.
An app uses binder to communicate with a system server in another process. The
system server uses binder to talk to HALs in other processes.
An app in one process uses binder to communicate with a different app in
another process.
The system daemon responsible for installing, updating, and removing
apps (installd) uses binder to communicate with the Android
runtime daemon ('artd') to compile apps.
AIDL and binder
Use the Android Interface Design Language (AIDL) to define programming
interfaces that use binder for IPC. For further information, see the
AIDL overview.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-08-29 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# Binder overview\n\n*Binder* is a system for interprocess\ncommunication that lets two processes on an Android-powered device\ncommunicate. Binder provides a means to execute function calls in another\nprocess that is completely transparent to the caller.\n\nIn binder terms, the calling process is considered the *client* and its\nendpoint is called the *binder proxy* or *proxy* . Conversely,\nthe process being called is the *server* and its endpoint is called the\n*binder node* or *node*.\n\nEach node can expose and implement its own interface. And, using a proxy, the\nclient can execute methods on a node interface as though invocation was a\nlocal function call. The following example shows a method being invoked: \n\n int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object\n\nAssume that the client calling `foo()` is running in process A and the server\nimplementing `foo()` is running in process B. Figure 1 shows how this call is\nexecuted:\n\n**Figure 1.** Binder call execution.\n\nTo execute a method in another process, as shown in figure 1,\nthe following occurs:\n\n1. The client code in process A invokes the proxy code in process A. The proxy code in process A creates a transaction containing the following items:\n - An identifier for the node\n - An identifier for the `foo()` method on the node\n - A buffer containing a copy of the arguments `a` and `b`\n2. The transaction is submitted to the binder kernel driver.\n3. The binder kernel driver determines that process B hosts the node.\n4. The kernel copies the entire transaction into process B's address space.\n5. The kernel finds a thread in process B to handle the transaction and passes the transaction to it.\n6. The thread unpacks the transaction, finds the node, and sends the transaction to the node object.\n7. The node object obtains the function identifier from the transaction, unpacks `a` and `b` from the transaction buffer, and stores `a` and `b` in local variables.\n8. The node object calls `foo(a, b)` on the server code in process B.\n9. The result of the call is returned in a reply transaction, which is passed to the kernel driver and then back to the calling proxy in process A.\n10. The proxy returns that result to the caller in process A.\n\nBinder use cases\n----------------\n\nBinder can be used in a variety of scenarios where communication between\nsoftware in different processes must occur. For example:\n\n- A camera app uses binder to communicate with the camera server in\n another process. The camera server then uses binder to communicate with the\n camera HAL in another process.\n\n- An app uses binder to communicate with a system server in another process. The\n system server uses binder to talk to HALs in other processes.\n\n- An app in one process uses binder to communicate with a different app in\n another process.\n\n- The system daemon responsible for installing, updating, and removing\n apps (`installd`) uses binder to communicate with the Android\n runtime daemon ('artd') to compile apps.\n\nAIDL and binder\n---------------\n\nUse the Android Interface Design Language (AIDL) to define programming\ninterfaces that use binder for IPC. For further information, see the\n[AIDL overview](/docs/core/architecture/aidl).\n| **Note:** HIDL is deprecated; only AIDL is recommended for new implementations."]]