Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
AIDL – Übersicht
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die Android Interface Definition Language (AIDL) ist ein Tool, mit dem Nutzer die IPC abstrahieren können. Anhand einer Schnittstelle (in einer .aidl-Datei angegeben) verwenden verschiedene Build-Systeme das aidl-Binärprogramm, um C++- oder Java-Bindungen zu erstellen, damit diese Schnittstelle prozessübergreifend verwendet werden kann, unabhängig von der Laufzeit oder der Bitness.
AIDL kann zwischen beliebigen Prozessen in Android verwendet werden: zwischen Plattformkomponenten oder zwischen Apps. Sie wird jedoch nie als API für Apps verwendet. AIDL kann beispielsweise verwendet werden, um eine SDK-API in der Plattform zu implementieren. Die SDK-API-Oberfläche enthält jedoch nie AIDL-APIs direkt. Eine Dokumentation zur direkten Verwendung von AIDL zwischen Apps finden Sie in der entsprechenden Android-Entwicklerdokumentation.
Wenn AIDL zwischen Plattformkomponenten verwendet wird, die separat aktualisiert werden, z. B. APEX-Dateien (ab Android 10) oder HALs (ab Android 11), muss das Versionsverwaltungssystem Stable AIDL verwendet werden.
Beispiel
Hier ist ein Beispiel für eine AIDL-Schnittstelle:
package my.package;
import my.package.Baz; // defined elsewhere
interface IFoo {
void doFoo(Baz baz);
}
Ein Server-Prozess registriert eine Schnittstelle und verarbeitet Aufrufe an diese Schnittstelle. Ein Client-Prozess führt Aufrufe an diese Schnittstellen aus. In vielen Fällen fungiert ein Prozess sowohl als Client als auch als Server, da er möglicherweise auf mehrere Schnittstellen verweist. Weitere Informationen zur AIDL-Sprache finden Sie unter AIDL-Sprache. Weitere Informationen zu den verschiedenen Runtimes, die für die Verwendung dieser Schnittstellen verfügbar sind, finden Sie unter AIDL-Back-Ends. Diese Typdeklarationen entsprechen genau einer Klassendeklaration in einer bestimmten Sprache, funktionieren aber prozessübergreifend.
Funktionsweise
AIDL verwendet den Binder-Kernel-Treiber für Aufrufe. Wenn Sie einen Aufruf tätigen, werden eine Methoden-ID und alle Objekte in einen Puffer gepackt und in einen Remote-Prozess kopiert, in dem ein Binder-Thread darauf wartet, die Daten zu lesen. Sobald ein Binder-Thread Daten für eine Transaktion empfängt, sucht der Thread nach einem nativen Stub-Objekt im lokalen Prozess. Diese Klasse entpackt die Daten und ruft ein lokales Schnittstellenobjekt auf. Dieses lokale Schnittstellenobjekt wird von einem Serverprozess erstellt und registriert. Wenn Anrufe im selben Prozess und im selben Backend erfolgen, sind keine Proxy-Objekte vorhanden. Anrufe erfolgen also direkt, ohne dass Daten gepackt oder entpackt werden müssen. Weitere Informationen finden Sie in der Binder-Übersicht.
Mit Diensten auf dem Gerät interagieren
Android bietet einige Befehle, mit denen Sie mit Diensten auf dem Gerät interagieren können. Hier ein paar Vorschläge:
adb shell dumpsys --help # listing and dumping services
adb shell service --help # sending commands to services for testing
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-30 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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"]]
