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,logdundstoraged. 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,libbinderundlibselinux. 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.