À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Binder est un système de communication interprocessus qui permet à deux processus sur un appareil Android de communiquer. Binder permet d'exécuter des appels de fonction dans un autre processus de manière totalement transparente pour l'appelant.
En termes de binder, le processus appelant est considéré comme le client et son point de terminaison est appelé proxy de binder ou proxy. À l'inverse, le processus appelé est le serveur et son point de terminaison est appelé nœud de binder ou nœud.
Chaque nœud peut exposer et implémenter sa propre interface. À l'aide d'un proxy, le client peut exécuter des méthodes sur une interface de nœud comme si l'invocation était un appel de fonction local. L'exemple suivant montre comment une méthode est appelée :
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
Supposons que le client appelant foo() s'exécute dans le processus A et que le serveur implémentant foo() s'exécute dans le processus B. La figure 1 montre comment cet appel est exécuté :
Figure 1 : Exécution de l'appel Binder.
Pour exécuter une méthode dans un autre processus, comme illustré dans la figure 1, les opérations suivantes se produisent :
Le code client du processus A appelle le code proxy du processus A. Le code de proxy du processus A crée une transaction contenant les éléments suivants :
Identifiant du nœud
Identifiant de la méthode foo() sur le nœud
Un tampon contenant une copie des arguments a et b
La transaction est envoyée au pilote du noyau Binder.
Le pilote du noyau Binder détermine que le processus B héberge le nœud.
Le noyau copie l'intégralité de la transaction dans l'espace d'adressage du processus B.
Le noyau trouve un thread dans le processus B pour gérer la transaction et la lui transmet.
Le thread décompresse la transaction, trouve le nœud et envoie la transaction à l'objet de nœud.
L'objet de nœud obtient l'identifiant de fonction à partir de la transaction, décompresse a et b à partir du tampon de transaction, puis stocke a et b dans des variables locales.
L'objet de nœud appelle foo(a, b) sur le code du serveur dans le processus B.
Le résultat de l'appel est renvoyé dans une transaction de réponse, qui est transmise au pilote du noyau, puis renvoyée au proxy appelant dans le processus A.
Le proxy renvoie ce résultat à l'appelant dans le processus A.
Cas d'utilisation de Binder
Binder peut être utilisé dans différents scénarios où la communication entre logiciels dans différents processus doit avoir lieu. Exemple :
Une application d'appareil photo utilise Binder pour communiquer avec le serveur de l'appareil photo dans un autre processus. Le serveur de caméras utilise ensuite Binder pour communiquer avec la HAL de caméras dans un autre processus.
Une application utilise Binder pour communiquer avec un serveur système dans un autre processus. Le serveur système utilise Binder pour communiquer avec les HAL dans d'autres processus.
Une application dans un processus utilise Binder pour communiquer avec une autre application dans un autre processus.
Le daemon système responsable de l'installation, de la mise à jour et de la suppression des applications (installd) utilise Binder pour communiquer avec le daemon d'exécution Android ("artd") afin de compiler les applications.
AIDL et Binder
Utilisez le langage de définition d'interface Android (AIDL) pour définir les interfaces de programmation qui utilisent le binder pour l'IPC. Pour en savoir plus, consultez la présentation d'AIDL.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]