À 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.
Présentation d'AIDL
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le langage de définition d'interface Android (AIDL) est un outil qui permet aux utilisateurs d'abstraire l'IPC. Étant donné une interface (spécifiée dans un fichier .aidl), différents systèmes de compilation utilisent le binaire aidl pour construire des liaisons C++ ou Java afin que cette interface puisse être utilisée dans tous les processus, quels que soient l'environnement d'exécution ou la taille en bits.
AIDL peut être utilisé entre n'importe quel processus dans Android : entre les composants de la plate-forme ou entre les applications. Toutefois, il n'est jamais utilisé comme API pour les applications. AIDL peut être utilisé pour implémenter une API SDK dans la plate-forme, par exemple, mais la surface de l'API SDK ne contient jamais d'API AIDL directement. Pour obtenir de la documentation sur l'utilisation d'AIDL directement entre les applications, consultez la documentation pour les développeurs Android correspondante.
Lorsque AIDL est utilisé entre des composants de plate-forme mis à jour séparément, tels que les APEX (à partir d'Android 10) ou les HAL (à partir d'Android 11), le système de gestion des versions appelé Stable AIDL doit être utilisé.
Exemple
Voici un exemple d'interface AIDL :
package my.package;
import my.package.Baz; // defined elsewhere
interface IFoo {
void doFoo(Baz baz);
}
Un processus serveur enregistre une interface et traite les appels qui lui sont adressés, tandis qu'un processus client effectue des appels à ces interfaces. Dans de nombreux cas, un processus agit à la fois en tant que client et serveur, car il peut faire référence à plusieurs interfaces. Pour en savoir plus sur le langage AIDL, consultez Langage AIDL. Pour en savoir plus sur les différents runtimes disponibles pour utiliser ces interfaces, consultez Backends AIDL. Ces déclarations de type sont exactement comme une déclaration de classe dans une langue donnée, mais elles fonctionnent dans tous les processus.
Fonctionnement
AIDL utilise le pilote de noyau Binder pour effectuer des appels. Lorsque vous effectuez un appel, un identifiant de méthode et tous les objets sont compressés dans un tampon et copiés dans un processus distant où un thread Binder attend de lire les données. Une fois qu'un thread de binder reçoit des données pour une transaction, il recherche un objet stub natif dans le processus local. Cette classe décompresse les données et effectue un appel sur un objet d'interface local. Cet objet d'interface locale est celui qu'un processus serveur crée et enregistre. Lorsque les appels sont effectués dans le même processus et le même backend, aucun objet proxy n'existe. Les appels sont donc directs, sans emballage ni déballage. Pour en savoir plus, consultez la présentation de Binder.
Interagir avec les services sur l'appareil
Android est fourni avec quelques commandes permettant d'interagir avec les services sur l'appareil. Conseil :
adb shell dumpsys --help # listing and dumping services
adb shell service --help # sending commands to services for testing
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/07/30 (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/07/30 (UTC)."],[],[],null,["# AIDL overview\n\nThe Android Interface Definition Language (AIDL) is a tool that lets users\nabstract away IPC. Given an interface (specified in a `.aidl`\nfile), various build systems use the `aidl` binary to construct C++ or Java\nbindings so that this interface can be used across processes, regardless of the\nruntime or bitness there.\n\nAIDL can be used between any process in Android: between platform components\nor between apps. However, it is never used as an API for apps. AIDL may be used\nto implement an SDK API in the platform, for example, but the SDK API surface\nnever contains AIDL APIs directly. For documentation about how to use AIDL\nbetween apps directly, see corresponding\n[Android developers\ndocumentation](https://developer.android.com/guide/components/aidl).\nWhen AIDL is used between platform components that are updated separately, such\nas APEXes (starting in Android 10) or HALs (starting in\nAndroid 11), the versioning system known as\n[Stable AIDL](/docs/core/architecture/aidl/stable-aidl) must be used.\n\nExample\n-------\n\nHere is an example AIDL interface: \n\n package my.package;\n\n import my.package.Baz; // defined elsewhere\n\n interface IFoo {\n void doFoo(Baz baz);\n }\n\nA *server* process registers an interface and serves calls to it, and a *client*\nprocess makes calls to those interfaces. In many cases, a process acts as both a\nclient and a server since it may be referencing multiple interfaces. For more\ndetails about the AIDL language, see\n[AIDL language](/docs/core/architecture/aidl/aidl-language). For more details\nabout the various runtimes available to use these interfaces, see\n[AIDL backends](/docs/core/architecture/aidl/aidl-backends). These type\ndeclarations are exactly like a class declaration in a given language, but they\nwork across processes.\n\nHow it works\n------------\n\nAIDL uses the binder kernel driver to make calls. When you make a call, a\nmethod identifier and all of the objects are packed onto a buffer and copied to\na remote process where a binder thread waits to read the data. Once a binder\nthread receives data for a transaction, the thread looks up a native stub object\nin the local process, and this class unpacks the data and makes a call on a\nlocal interface object. This local interface object is the one a server process\ncreates and registers. When calls are made in the same process and the same\nbackend, no proxy objects exist, and so calls are direct without any\npacking or unpacking. For further information, see the\n[Binder overview](/docs/core/architecture/ipc/binder-overview).\n\nInteract with services on the device\n------------------------------------\n\nAndroid comes with a few commands to allow interacting with services on the\ndevice. Try: \n\n adb shell dumpsys --help # listing and dumping services\n adb shell service --help # sending commands to services for testing"]]
