Architektur

Das Android Open Source Project (AOSP) ist öffentlich verfügbar und kann geändert werden. Android-Quellcode. Jeder kann AOSP für sein Gerät herunterladen und ändern. AOSP bietet eine vollständige und voll funktionsfähige Implementierung von Android Mobile Plattform.

Es gibt zwei Kompatibilitätsebenen für Geräte, die AOSP implementieren: AOSP. und Android-Kompatibilität. Ein AOSP-kompatibles Gerät muss der Liste der Anforderungen im Dokument zur Kompatibilitätsdefinition (Compatibility Definition Document, CDD). Eine Android-kompatible Geräte müssen der Liste der Anforderungen im CDD entsprechen. und die Anforderungen an die Software von Anbietern sowie Tests wie die in der Vendor Test Suite (VTS) und Kompatibilitätstest-Suite (Compatibility Test Suite, CTS). Weitere Informationen zur Android-Kompatibilität finden Sie in der Android-Kompatibilitätsprogramm.

AOSP-Architektur

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

Architektur des AOSP-Softwarestacks

Abbildung 1: Architektur des AOSP-Softwarestacks

Es folgt eine Liste mit Definitionen der in Abbildung 1 verwendeten Begriffe:

Android-App
Eine App, die ausschließlich mit der Android API erstellt wurde. Google Der Play Store ist weit verbreitet, um Android-Apps zu finden und herunterzuladen. Es gibt jedoch viele andere Alternativen. In einigen Fällen möchte ein Gerätehersteller eine Android-App vorinstallieren, die die Hauptfunktion des Geräts unterstützt. Wenn an der Entwicklung von Android-Apps interessiert sind, developers.android.com aufrufen.
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 direkten auf die Implementierung des Android-Frameworks zugreifen. Da ein Gerätehersteller direkt auf instabile APIs innerhalb des Android-Frameworks zugreifen können, muss auf dem Gerät vorinstalliert sein und kann nur aktualisiert werden, wenn Systemsoftware aktualisiert wird.
System-API
Die System-API repräsentiert Android-APIs, die nur für Partner und OEMs können in gebündelte Anwendungen aufgenommen werden. Diese APIs sind als @SystemApi gekennzeichnet im Quellcode enthalten.
Android-API
Die Android API ist die öffentlich verfügbare API für Android-Apps von Drittanbietern. zu entwickeln. Informationen zur Android API finden Sie unter Android API-Referenz
Android-Framework
Eine Gruppe von Java-Klassen, -Schnittstellen und anderem vorkompiliertem Code, für den entwickelt. Teile des Frameworks sind über das die Nutzung der Android API. Andere Bestandteile des Frameworks sind nur für OEMs über die System-APIs verfügbar. Android-Geräte Framework-Code wird im Prozess einer App ausgeführt.
Systemdienste
Systemdienste sind modulare, fokussierte Komponenten wie system_server, SurfaceFlinger und MediaService. Funktionalität der Android Framework API kommuniziert mit Systemdiensten, um auf die zugrunde liegende Hardware zuzugreifen.
Android-Laufzeit (ART)
Eine von AOSP bereitgestellte Java-Laufzeitumgebung. ART führt die Umwandlung des Bytecodes der App in prozessorspezifische Anweisungen die von der Laufzeitumgebung des Geräts ausgeführt werden.
Hardware-Abstraktionsebene (HAL)
Ein HAL ist eine Abstraktionsschicht mit einer Standardschnittstelle für Hardwareanbieter zu implementieren. HALs ermöglichen es Android, unabhängig von untergeordneten Treibern zu agieren. Implementierungen. Mit einem HAL können Sie Funktionen implementieren, die das übergeordnete System beeinflussen oder modifizieren. Weitere Informationen Weitere Informationen finden Sie in der HAL-Übersicht.
Native Daemons und Bibliotheken

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

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 von einem Userspace-basierten HAL abhängig. Implementierung.

Kernel

Der Kernel ist das Herzstück jedes Betriebssystems und kommuniziert mit dem zugrunde liegende Hardware auf einem Gerät. Wo möglich, wird der AOSP-Kernel aufgeteilt. in hardwareunabhängige Module und in anbieterspezifische Module. Eine Beschreibung einschließlich Definitionen, der AOSP-Kernel-Komponenten, siehe Kernel-Übersicht

Wie geht es weiter?

  • Wenn Sie neu bei AOSP sind und mit der Entwicklung beginnen möchten, lesen Sie im Abschnitt Erste Schritte.
  • Wenn Sie mehr über eine bestimmte AOSP-Ebene erfahren möchten, klicken Sie auf den in der linken Navigationsleiste und beginnen Sie mit der Übersicht für diesen Abschnitt.