AOSP-Architektur

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 in der CDD und den Anbieter-Softwareanforderungen (VSR) und Tests wie denen in der Anbieter- Test-Suite (VTS) und der Kompatibilitäts-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.
  • Android App. Eine App, die ausschließlich mit der Android-API im Android SDK 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 daran interessiert sind, Android-Apps zu entwickeln, gehen Sie zu 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.
  • App zur Geräteherstellung. 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.
  • Android-Framework. Eine Gruppe von Java-Klassen, -Schnittstellen und anderem vorkompiliertem Code, auf dem Apps aufgebaut sind. Teile des Frameworks sind durch die Verwendung der Android-APIs des Android SDK öffentlich zugänglich. Andere Teile des Frameworks sind nur für OEMs über die System-APIs des Android SDK verfügbar. Android-Framework-Code wird innerhalb des Prozesses einer App ausgeführt.
  • Android SDK. Ein Softwareentwicklungskit zum Erstellen von Apps, die mit dem Android-Framework interagieren. Das Android SDK besteht aus der Android-API, die für alle Apps verfügbar ist, und der System-API, die nur für privilegierte Apps verfügbar ist. Weitere Informationen zur Android-API des Android SDK finden Sie unter developer.android.com . Beachten Sie, dass es auch ein Android Native Development Kit (NDK) gibt, mit dem Sie einen Teil Ihrer Android-App mit nativem Code schreiben können.
  • 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 Laufzeitumgebung für Java-Anwendungen, die von AOSP bereitgestellt wird. ART führt die Übersetzung des Bytecodes der Anwendung in prozessorspezifische Anweisungen durch, 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 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. Als zentraler Bestandteil eines jeden Betriebssystems kommuniziert der Kernel 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, fahren Sie mit dem Abschnitt „Erste Schritte“ fort.
  • Wenn Sie mehr über eine bestimmte Ebene von AOSP erfahren möchten, klicken Sie in der linken Navigation auf den Namen der Ebene und beginnen Sie mit der Übersicht für diese Ebene.