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.
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Das Open-Source-Projekt für Android (AOSP) ist öffentlich verfügbar und der Android-Quellcode kann geändert werden. Jeder kann AOSP für sein Gerät herunterladen und ändern. AOSP bietet eine vollständige und voll funktionsfähige Implementierung der mobilen Android-Plattform.
Es gibt zwei Kompatibilitätsstufen für Geräte, auf denen AOSP implementiert ist: AOSP-Kompatibilität und Android-Kompatibilität. Ein AOSP-kompatibles Gerät muss den Anforderungen im Compatibility Definition Document (CDD) entsprechen. Ein Android-kompatibles Gerät muss den Anforderungen im CDD und den Vendor Software Requirements (VSR) entsprechen und Tests wie die in der Vendor Test Suite (VTS) und der Compatibility Test Suite (CTS) bestehen. Weitere Informationen zur Android-Kompatibilität finden Sie im Android-Kompatibilitätsprogramm.
AOSP-Architektur
Der Software-Stack für AOSP enthält die folgenden Ebenen:
Abbildung 1: AOSP-Softwarestack-Architektur
Im Folgenden finden Sie eine Liste mit Definitionen der in Abbildung 1 verwendeten Begriffe:
Android-App
Eine App, die ausschließlich mit der Android API erstellt wurde. Der Google Play Store wird häufig verwendet, um Android-Apps zu finden und herunterzuladen. Es gibt jedoch viele andere Alternativen. In einigen Fällen möchte ein Gerätehersteller möglicherweise eine Android-App vorinstallieren, um die Kernfunktionen des Geräts zu unterstützen. Wenn Sie Android-Apps entwickeln möchten, finden Sie weitere Informationen unter developers.android.com.
App mit Berechtigungen
Eine App, die mit einer Kombination aus Android- und System-APIs erstellt wurde. Diese Apps müssen als privilegierte Apps auf einem Gerät vorinstalliert sein.
App des Geräteherstellers
Eine App, die mit einer Kombination aus der Android API, der System-API und dem direkten Zugriff auf die Android-Framework-Implementierung erstellt wurde. Da ein Gerätehersteller möglicherweise direkt auf instabile APIs im Android-Framework zugreift, müssen diese Apps auf dem Gerät vorinstalliert sein und können nur aktualisiert werden, wenn die Systemsoftware des Geräts aktualisiert wird.
System-API
Die System-API umfasst Android-APIs, die nur Partnern und OEMs zur Einbindung in gebündelte Anwendungen zur Verfügung stehen. Diese APIs sind im Quellcode mit @SystemApi gekennzeichnet.
Android API
Die Android API ist die öffentlich verfügbare API für Drittanbieter-Entwickler von Android-Apps. Informationen zur Android API finden Sie in der Android API-Referenz.
Android-Framework
Eine Gruppe von Java-Klassen, ‑Schnittstellen und anderem vorkompilierten Code, auf dem Apps basieren. Teile des Frameworks sind über die Android API öffentlich zugänglich. Andere Teile des Frameworks sind nur für OEMs über die System-APIs verfügbar. Android-Framework-Code wird im Prozess einer App ausgeführt.
Systemdienste
Systemdienste sind modulare, fokussierte Komponenten wie system_server, SurfaceFlinger und MediaService. Die von der Android-Framework-API bereitgestellte Funktionalität kommuniziert mit Systemdiensten, um auf die zugrunde liegende Hardware zuzugreifen.
Android-Laufzeit (ART)
Eine von AOSP bereitgestellte Java-Laufzeitumgebung. ART übersetzt den Bytecode der App in prozessorspezifische Anweisungen, die von der Laufzeitumgebung des Geräts ausgeführt werden.
Hardwareabstraktionsschicht (HAL)
Eine HAL ist eine Abstraktionsschicht mit einer Standardschnittstelle, die Hardwareanbieter implementieren können. HALs ermöglichen es Android, unabhängig von den Treiberimplementierungen unterer Ebenen zu agieren. Mit einer HAL können Sie Funktionen implementieren, ohne das System auf höherer Ebene zu beeinträchtigen oder zu ändern. Weitere Informationen finden Sie in der HAL-Übersicht.
Native Daemons und Bibliotheken
Zu den nativen Daemons in dieser Ebene gehören init, healthd, logd und storaged. Diese Daemons interagieren direkt mit dem Kernel oder anderen Schnittstellen und sind nicht von einer HAL-Implementierung im Userspace abhängig.
Native Bibliotheken in dieser Ebene sind libc, liblog, libutils, libbinder und libselinux. Diese nativen Bibliotheken interagieren direkt mit dem Kernel oder anderen Schnittstellen und sind nicht von einer HAL-Implementierung im Userspace abhängig.
Kernel
Der Kernel ist der zentrale Teil jedes Betriebssystems und kommuniziert mit der zugrunde liegenden Hardware eines Geräts. Der AOSP-Kernel wird nach Möglichkeit in hardwareunabhängige und anbieterspezifische Module aufgeteilt. Eine Beschreibung der AOSP-Kernelkomponenten, einschließlich Definitionen, finden Sie in der Kernelübersicht.
Und jetzt?
Wenn Sie neu bei AOSP sind und mit der Entwicklung beginnen möchten, lesen Sie den Abschnitt „Erste Schritte“.
Wenn Sie mehr über eine bestimmte AOSP-Ebene erfahren möchten, klicken Sie in der linken Navigationsleiste auf den Namen des Abschnitts und beginnen Sie mit der Übersicht für diesen Abschnitt.
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-24 (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-24 (UTC)."],[],[],null,["# Architecture overview\n\nThe *Android Open Source Project (AOSP)* is publicly available and modifiable\nAndroid source code. Anyone can download and modify AOSP for their device. AOSP\nprovides a complete and fully functional implementation of the Android mobile\nplatform.\n| **Note:** AOSP can't provide support for apps that require backend services, such as a cloud messaging or advanced location services app. AOSP also doesn't include a full set of end-user apps that might be needed for particular types of devices.\n\nThere are two levels of compatibility for devices implementing AOSP: AOSP\ncompatibility and Android compatibility. An *AOSP-compatible device* must\nconform to the list of requirements in the\n[Compatibility Definition Document (CDD)](/docs/compatibility/cdd). An\n*Android-compatible device* must conform to the list of requirements in the CDD\nand Vendor Software Requirements (VSR) and tests such as those in the\n[Vendor Test Suite (VTS)](/docs/core/tests/vts) and\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts). For further\ninformation on Android compatibility, refer to the\n[Android compatibility program](/docs/compatibility).\n\nAOSP architecture\n-----------------\n\nThe software stack for AOSP contains the following layers:\n\n**Figure 1.** AOSP software stack architecture.\n\nFollowing is a list of definitions for terms used in Figure 1:\n\n*Android app*\n: An app created solely using the Android API. Google\n Play Store is widely used to find and download Android apps, though there are\n many other alternatives. In some cases, a device manufacturer might want to\n preinstall an Android app to support the core functionality of the device. If\n you're interested in developing Android apps, refer to\n [developers.android.com](https://developer.android.com/).\n\n*Privileged app*\n: An app created using a combination of the Android and system APIs. These apps\n must be preinstalled as privileged apps on a device.\n\n*Device manufacturer app*\n: An app created using a combination of the Android API, system API, and direct\n access to the Android framework implementation. Because a device manufacturer\n might directly access unstable APIs within the Android framework, these apps\n must be preinstalled on the device and can be updated only when the device's\n system software is updated.\n\n*System API*\n: The System API represents Android APIs available only to partners and\n OEMs for inclusion in bundled applications. These APIs are marked as @SystemApi\n in the source code.\n\n*Android API*\n: The Android API is the publicly available API for third-party Android app\n developers. For information on the Android API, refer to\n [Android API reference](https://developer.android.com/reference).\n\n*Android framework*\n: A group of Java classes, interfaces, and other precompiled code upon which\n apps are built. Portions of the framework are publicly accessible through the\n use of the Android API. Other portions of the framework are\n available only to OEMs through the use of the system APIs. Android\n framework code runs inside an app's process.\n\n*System services*\n: System services are modular, focused components such as `system_server`,\n SurfaceFlinger, and MediaService. Functionality exposed by Android framework API\n communicates with system services to access the underlying hardware.\n\n*Android runtime (ART)*\n: A Java runtime environment provided by AOSP. ART performs the\n translation of the app's bytecode into processor-specific instructions\n that are executed by the device's runtime environment.\n\n*Hardware abstraction layer (HAL)*\n: A HAL is an abstraction layer with a standard interface for hardware vendors\n to implement. HALs allow Android to be agnostic about lower-level driver\n implementations. Using a HAL lets you implement functionality without\n affecting or modifying the higher level system. For further information,\n see the [HAL overview](/docs/core/architecture/hal).\n\n*Native daemons and libraries*\n\n: Native daemons in this layer include `init`, `healthd`, `logd`, and\n `storaged`. These daemons interact directly with the kernel or other interfaces\n and don't depend on a userspace-based HAL implementation.\n\n Native libraries in this layer include `libc`, `liblog`, `libutils`,\n `libbinder`, and `libselinux`. These Native libraries interact directly with\n the kernel or other interfaces and don't depend on a userspace-based HAL\n implementation.\n\n*Kernel*\n\n: The kernel is the central part of any operating system and talks to the\n underlying hardware on a device. Where possible, the AOSP kernel is split\n into hardware-agnostic modules and vendor-specific modules. For a description,\n including definitions, of AOSP kernel components, refer to the\n [Kernel overview](/docs/core/architecture/kernel).\n\nWhat's next?\n------------\n\n- If you're new to AOSP, and want to get started with development, refer to the [Get started section](/docs/setup).\n- If you want to learn more about a specific layer of AOSP, click the section's name in the left navigation and begin with the overview for that section."]]
