Architektur

Das Android Open Source Project (AOSP) ist ö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.

Für Geräte mit AOSP gibt es zwei Kompatibilitätsstufen: 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 Anforderungen an die Software des Anbieters (Vendor Software Requirements, VSR) sowie 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 Softwarestack für AOSP enthält die folgenden Schichten:

Abbildung 1. AOSP-Softwarestack-Architektur

Im Folgenden finden Sie 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 ist weit verbreitet, um Android-Apps zu finden und herunterzuladen. Es gibt aber auch viele andere Alternativen. In einigen Fällen kann ein Gerätehersteller eine Android-App vorinstallieren, um die Hauptfunktionen des Geräts zu unterstützen. Wenn Sie Android-Apps entwickeln möchten, rufen Sie developers.android.com auf.

Privilegierte App

Eine App, die mit einer Kombination aus Android- und System-APIs erstellt wurde. Diese Apps müssen als privilegierte Apps auf dem Gerät vorinstalliert sein.

App des Geräteherstellers

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 direkt auf instabile APIs im Android-Framework zugreifen kann, 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 für Partner und OEMs zur Aufnahme in gebündelte Anwendungen verfügbar sind. 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 vorkompilierten Code, auf dem Apps basieren. 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. Android-Framework-Code wird im Prozess einer App ausgeführt.

Systemdienste

Systemdienste sind modulare, spezifische Komponenten wie system_server, SurfaceFlinger und MediaService. Die von der Android-Framework-API bereitgestellten Funktionen kommunizieren mit Systemdiensten, um auf die zugrunde liegende Hardware zuzugreifen.

Android Runtime (ART)

Eine Java-Laufzeitumgebung, die von AOSP bereitgestellt wird. ART übersetzt den Bytecode der App in prozessorspezifische Anweisungen, die von der Laufzeitumgebung des Geräts ausgeführt werden.

Hardware-Abstraktionsebene (HAL)

Eine HAL ist eine Abstraktionsschicht mit einer Standardschnittstelle, die von Hardwareanbietern implementiert werden muss. HALs ermöglichen es Android, unabhängig von Treiberimplementierungen auf niedriger Ebene zu sein. Mit einer HAL können Sie Funktionen implementieren, ohne das System der höheren Ebene zu beeinflussen oder zu ändern. Weitere Informationen finden Sie in der HAL-Übersicht.

Native Daemons und Bibliotheken

Zu den nativen Daemonen 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 jedes Betriebssystems und kommuniziert mit der zugrunde liegenden Hardware eines Geräts. Wenn möglich, wird der AOSP-Kernel in hardwareunabhängige Module und in anbieterspezifische Module unterteilt. Eine Beschreibung der AOSP-Kernelkomponenten, einschließlich Definitionen, finden Sie unter Kernel – Übersicht.

Wie geht es weiter?

• Wenn Sie mit AOSP noch nicht vertraut sind und mit der Entwicklung beginnen möchten, lesen Sie den Abschnitt „Einstieg“.
• Wenn Sie mehr über eine bestimmte Schicht von AOSP erfahren möchten, klicken Sie im linken Navigationsbereich auf den Namen des Abschnitts und beginnen Sie mit der Übersicht für diesen Abschnitt.