Architektur

Die Android Open System Platform (AOSP) ist ein öffentlich verfügbarer und modifizierbarer Android-Quellcode. 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, die AOSP implementieren: AOSP-Kompatibilität und Android-Kompatibilität. Ein AOSP-kompatibles Gerät muss der Liste der Anforderungen im Compatibility Definition Document (CDD) entsprechen. Ein Android-kompatibles Gerät muss der Liste der Anforderungen im CDD und den Vendor Software Requirements (VSR) sowie Tests wie denen der Vendor Test Suite (VTS) und der Compatibility Test Suite (CTS) entsprechen. Weitere Informationen zur Android-Kompatibilität finden Sie im Android-Kompatibilitätsprogramm .

AOSP-Architektur

Der Software-Stack für AOSP enthält die folgenden Schichten:

AOSP-Software-Stack-Architektur.

Abbildung 1. AOSP-Software-Stack-Architektur.

Im Folgenden finden Sie eine Liste mit Definitionen für die 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 zum Suchen und Herunterladen von Android-Apps verwendet, es gibt jedoch viele andere Alternativen. In manchen Fällen möchte ein Gerätehersteller möglicherweise eine Android-App vorinstallieren, um die Kernfunktionen des Geräts zu unterstützen. Wenn Sie an der Entwicklung von Android-Apps interessiert sind, besuchen Sie Developers.android.com
Privilegierte App
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.
Gerätehersteller-App
Eine App, die mit einer Kombination aus Android-API, System-API und direktem Zugriff auf die Android-Framework-Implementierung erstellt wurde. Da ein Gerätehersteller möglicherweise direkt auf instabile APIs innerhalb des Android-Frameworks 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 stellt Android-APIs dar, die nur Partnern und OEMs zur Einbindung in gebündelte Anwendungen zur Verfügung stehen. Diese APIs sind im Quellcode als @SystemApi gekennzeichnet.
Android-API
Die Android-API ist die öffentlich verfügbare API für Android-App-Entwickler von Drittanbietern. Informationen zur Android-API finden Sie in der Android-API-Referenz .
Android-Framework
Eine Gruppe von Java-Klassen, Schnittstellen und anderen vorkompilierten Codes, auf denen Apps erstellt werden. Teile des Frameworks sind über die Android-API öffentlich zugänglich. Andere Teile des Frameworks stehen nur OEMs über die System-APIs zur Verfügung. Der Code des Android-Frameworks 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 führt die Übersetzung des Bytecodes der App in prozessorspezifische Anweisungen durch, die von der Laufzeitumgebung des Geräts ausgeführt werden.
Hardware-Abstraktionsschicht (HAL)
Ein HAL ist eine Abstraktionsschicht mit einer Standardschnittstelle, die von Hardwareanbietern implementiert werden kann. HALs ermöglichen es Android, unabhängig von Treiberimplementierungen auf niedrigerer Ebene zu sein. Mithilfe einer HAL können Sie Funktionen implementieren, ohne das übergeordnete System 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 auf eine Userspace-basierte HAL-Implementierung angewiesen.

Zu den nativen Bibliotheken in dieser Ebene gehören libc , liblog , libutils , libbinder und libselinux . Diese nativen Bibliotheken interagieren direkt mit dem Kernel oder anderen Schnittstellen und sind nicht auf eine Userspace-basierte HAL-Implementierung angewiesen.

Kernel

Der Kernel ist der zentrale Teil jedes Betriebssystems und kommuniziert mit der zugrunde liegenden Hardware auf einem Gerät. Wo möglich, ist der AOSP-Kernel in hardwareunabhängige Module und herstellerspezifische Module aufgeteilt. Eine Beschreibung, einschließlich Definitionen, der AOSP-Kernelkomponenten finden Sie in der Kernel-Übersicht .

Was kommt als nächstes?

  • 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 Navigation auf den Namen des Abschnitts und beginnen Sie mit der Übersicht für diesen Abschnitt.