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.
Panoramica di AIDL
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Android Interface Definition Language (AIDL) è uno strumento che consente agli utenti di
astrarre l'IPC. Data un'interfaccia (specificata in un file .aidl), vari sistemi di compilazione utilizzano il binario aidl per costruire binding C++ o Java in modo che questa interfaccia possa essere utilizzata in tutti i processi, indipendentemente dal runtime o dalla bitness.
AIDL può essere utilizzato tra qualsiasi processo in Android: tra i componenti della piattaforma
o tra le app. Tuttavia, non viene mai utilizzata come API per le app. AIDL può essere utilizzato
per implementare un'API SDK nella piattaforma, ad esempio, ma la superficie dell'API SDK
non contiene mai direttamente API AIDL. Per la documentazione su come utilizzare AIDL
direttamente tra le app, consulta la
documentazione per gli sviluppatori
Android.
Quando AIDL viene utilizzato tra componenti della piattaforma aggiornati separatamente, ad esempio APEX (a partire da Android 10) o HAL (a partire da Android 11), deve essere utilizzato il sistema di controllo delle versioni noto come AIDL stabile.
Esempio
Ecco un esempio di interfaccia AIDL:
package my.package;
import my.package.Baz; // defined elsewhere
interface IFoo {
void doFoo(Baz baz);
}
Un processo server registra un'interfaccia e gestisce le chiamate, mentre un processo client
effettua chiamate a queste interfacce. In molti casi, un processo funge sia da
client che da server, in quanto può fare riferimento a più interfacce. Per ulteriori
dettagli sul linguaggio AIDL, consulta
Linguaggio AIDL. Per ulteriori dettagli
sui vari runtime disponibili per utilizzare queste interfacce, consulta
Backend AIDL. Queste dichiarazioni
di tipo sono esattamente come una dichiarazione di classe in una determinata lingua, ma
funzionano tra i processi.
Come funziona
AIDL utilizza il driver del kernel binder per effettuare chiamate. Quando effettui una chiamata, un
identificatore del metodo e tutti gli oggetti vengono inseriti in un buffer e copiati in
un processo remoto in cui un thread binder attende di leggere i dati. Quando un thread
binder riceve i dati per una transazione, il thread cerca un oggetto stub nativo
nel processo locale e questa classe decomprime i dati ed effettua una chiamata a un
oggetto interfaccia locale. Questo oggetto di interfaccia locale è quello che un processo server
crea e registra. Quando le chiamate vengono effettuate nello stesso processo e nello stesso backend, non esistono oggetti proxy, quindi le chiamate sono dirette senza alcun packing o unpacking. Per ulteriori informazioni, consulta la
panoramica del raccoglitore.
Interagire con i servizi sul dispositivo
Android include alcuni comandi che consentono di interagire con i servizi sul
dispositivo. Prova:
adb shell dumpsys --help # listing and dumping services
adb shell service --help # sending commands to services for testing
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-07-30 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-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"]]
