A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Binder es un sistema de comunicación entre procesos que permite que dos procesos en un dispositivo Android se comuniquen. Binder proporciona un medio para ejecutar llamadas a funciones en otro proceso que es completamente transparente para el llamador.
En términos de vinculación, el proceso de llamada se considera el cliente y su extremo se denomina proxy de vinculación o proxy. Por el contrario, el proceso al que se llama es el servidor y su extremo se denomina nodo de vinculación o nodo.
Cada nodo puede exponer e implementar su propia interfaz. Además, con un proxy, el cliente puede ejecutar métodos en una interfaz de nodo como si la invocación fuera una llamada a función local. En el siguiente ejemplo, se muestra un método que se invoca:
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
Supón que el cliente que llama a foo() se ejecuta en el proceso A y el servidor que implementa foo() se ejecuta en el proceso B. En la figura 1, se muestra cómo se ejecuta esta llamada:
Figura 1: Es la ejecución de la llamada de Binder.
Para ejecutar un método en otro proceso, como se muestra en la figura 1, ocurre lo siguiente:
El código del cliente en el proceso A invoca el código del proxy en el proceso A. El código de proxy en el proceso A crea una transacción que contiene los siguientes elementos:
Es un identificador del nodo.
Es un identificador para el método foo() en el nodo.
Un búfer que contiene una copia de los argumentos a y b
La transacción se envía al controlador del kernel del vinculador.
El controlador del kernel de Binder determina que el proceso B aloja el nodo.
El kernel copia toda la transacción en el espacio de direcciones del proceso B.
El kernel encuentra un subproceso en el proceso B para controlar la transacción y se la pasa.
El subproceso desempaqueta la transacción, encuentra el nodo y envía la transacción al objeto del nodo.
El objeto de nodo obtiene el identificador de la función de la transacción, desempaqueta a y b del búfer de la transacción, y almacena a y b en variables locales.
El objeto de nodo llama a foo(a, b) en el código del servidor en el proceso B.
El resultado de la llamada se devuelve en una transacción de respuesta, que se pasa al controlador del kernel y, luego, de vuelta al proxy de llamada en el proceso A.
El proxy devuelve ese resultado a la persona que llamó en el proceso A.
Casos de uso de Binder
Binder se puede usar en una variedad de situaciones en las que debe ocurrir la comunicación entre software en diferentes procesos. Por ejemplo:
Una app de cámara usa Binder para comunicarse con el servidor de cámara en otro proceso. Luego, el servidor de la cámara usa Binder para comunicarse con el HAL de la cámara en otro proceso.
Una app usa el binder para comunicarse con un servidor del sistema en otro proceso. El servidor del sistema usa Binder para comunicarse con las HAL en otros procesos.
Una app en un proceso usa Binder para comunicarse con otra app en otro proceso.
El daemon del sistema responsable de instalar, actualizar y quitar apps (installd) usa Binder para comunicarse con el daemon del tiempo de ejecución de Android ("artd") para compilar apps.
AIDL y Binder
Usa el lenguaje de definición de la interfaz de Android (AIDL) para definir interfaces de programación que usen binder para la IPC. Para obtener más información, consulta la descripción general de AIDL.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-08-05 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-05 (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."]]