Architekturübersicht

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 modifizieren. 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) und Tests wie denen in 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 verwendet, um Android-Apps zu finden und herunterzuladen, obwohl es viele andere Alternativen gibt. In einigen Fällen möchte ein Gerätehersteller möglicherweise eine Android-App vorinstallieren, um die Kernfunktionalität des Geräts zu unterstützen. Wenn Sie an der Entwicklung von Android-Apps interessiert sind, besuchen Sie developer.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 Aufnahme 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 anderem vorkompiliertem Code, auf dem Apps aufgebaut sind. Teile des Frameworks sind über die Android-API öffentlich zugänglich. Andere Teile des Frameworks sind nur für OEMs durch die Verwendung der System-APIs verfügbar. Android-Framework-Code wird innerhalb des Prozesses 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)
Eine HAL ist eine Abstraktionsschicht mit einer Standardschnittstelle, die Hardwareanbieter implementieren können. HALs ermöglichen es Android, unabhängig von Treiberimplementierungen auf niedrigerer Ebene zu sein. Durch die Verwendung einer HAL können Sie Funktionen implementieren, ohne das übergeordnete System zu beeinflussen oder zu modifizieren. Weitere Informationen finden Sie in der HAL-Übersicht .
Native Daemons und Bibliotheken

Zu den nativen Daemons in dieser Schicht gehören init , healthd , logd und storaged . Diese Daemons interagieren direkt mit dem Kernel oder anderen Schnittstellen und sind nicht von einer Userspace-basierten HAL-Implementierung abhängig.

Zu den nativen Bibliotheken in dieser Schicht gehören libc , liblog , libutils , libbinder und libselinux . Diese nativen Bibliotheken interagieren direkt mit dem Kernel oder anderen Schnittstellen und sind nicht von einer Userspace-basierten HAL-Implementierung abhängig.

Kernel

Der Kernel ist der zentrale Teil eines jeden Betriebssystems und kommuniziert mit der zugrunde liegenden Hardware auf einem Gerät. Wo möglich, wird 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 Ebene von AOSP erfahren möchten, klicken Sie in der linken Navigation auf den Namen des Abschnitts und beginnen Sie mit der Übersicht für diesen Abschnitt.