A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Binder è un sistema di comunicazione tra processi
che consente a due processi su un dispositivo Android
di comunicare. Binder fornisce un mezzo per eseguire chiamate di funzioni in un altro processo completamente trasparente al chiamante.
Nei termini del binder, la procedura di chiamata è considerata il client e il relativo
endpoint è chiamato proxy del binder o proxy. Al contrario, il processo chiamato è il server e il suo endpoint è chiamato nodo binder o nodo.
Ogni nodo può esporre e implementare la propria interfaccia. Utilizzando un proxy, il
client può eseguire metodi su un'interfaccia del nodo come se l'invocazione fosse una
chiamata di funzione locale. L'esempio seguente mostra l'invocazione di un metodo:
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
Supponi che il client che chiama foo() sia in esecuzione nel processo A e che il server
che implementa foo() sia in esecuzione nel processo B. La Figura 1 mostra come viene eseguita questa chiamata:
Figura 1. Esecuzione della chiamata a Binder.
Per eseguire un metodo in un altro processo, come mostrato nella Figura 1,
si verifica quanto segue:
Il codice client nel processo A richiama il codice proxy nel processo A. Il codice
proxy nel processo A crea una transazione contenente i seguenti elementi:
Un identificatore per il nodo
Un identificatore per il metodo foo() sul nodo
Un buffer contenente una copia degli argomenti a e b
La transazione viene inviata al driver del kernel binder.
Il driver del kernel Binder determina che il processo B ospita il nodo.
Il kernel copia l'intera transazione nello spazio degli indirizzi del processo B.
Il kernel trova un thread nel processo B per gestire la transazione e gliela passa.
Il thread decomprime la transazione, trova il nodo e invia la transazione all'oggetto nodo.
L'oggetto nodo ottiene l'identificatore della funzione dalla transazione,
decomprime a e b dal buffer della transazione e memorizza a e b in
variabili locali.
L'oggetto nodo chiama foo(a, b) sul codice del server nel processo B.
Il risultato della chiamata viene restituito in una transazione di risposta, che viene passata
al driver del kernel e poi di nuovo al proxy chiamante nel processo A.
Il proxy restituisce il risultato al chiamante nel processo A.
Casi d'uso di Binder
Binder può essere utilizzato in una serie di scenari in cui deve avvenire la comunicazione tra
software in processi diversi. Ad esempio:
Un'app fotocamera utilizza Binder per comunicare con il server della fotocamera in
un altro processo. Il server della videocamera utilizza quindi Binder per comunicare con l'HAL della videocamera in un altro processo.
Un'app utilizza Binder per comunicare con un server di sistema in un altro processo. Il
server di sistema utilizza Binder per comunicare con gli HAL in altri processi.
Un'app in un processo utilizza Binder per comunicare con un'altra app in
un altro processo.
Il daemon di sistema responsabile dell'installazione, dell'aggiornamento e della rimozione
delle app (installd) utilizza Binder per comunicare con il daemon
di runtime Android ("artd") per compilare le app.
AIDL e binder
Utilizza Android Interface Design Language (AIDL) per definire interfacce di programmazione che utilizzano Binder per IPC. Per ulteriori informazioni, consulta la
panoramica di AIDL.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-08-05 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]