Android-Architektur

Die Android-Systemarchitektur enthält die folgenden Komponenten:

Überblick über die Android-Systemarchitektur
Abbildung 1. Android-Systemarchitektur
  • Anwendungsrahmen . Das Anwendungsframework wird am häufigsten von Anwendungsentwicklern verwendet. Als Hardwareentwickler sollten Sie sich der Entwickler-APIs bewusst sein, da viele direkt den zugrunde liegenden HAL-Schnittstellen zugeordnet sind und hilfreiche Informationen zur Implementierung von Treibern bereitstellen können.
  • Binder IPC . Der Inter-Process Communication (IPC)-Mechanismus von Binder ermöglicht es dem Anwendungsframework, Prozessgrenzen zu überschreiten und den Android-Systemdienstcode aufzurufen. Dadurch können High-Level-Framework-APIs mit Android-Systemdiensten interagieren. Auf der Ebene des Anwendungsframeworks ist diese Kommunikation vor dem Entwickler verborgen und die Dinge scheinen „einfach zu funktionieren“.
  • Systemdienste . Systemdienste sind modulare, fokussierte Komponenten wie Window Manager, Search Service oder Notification Manager. Die von Anwendungsframework-APIs bereitgestellte Funktionalität kommuniziert mit Systemdiensten, um auf die zugrunde liegende Hardware zuzugreifen. Android umfasst zwei Gruppen von Diensten: System (z. B. Fenstermanager und Benachrichtigungsmanager) und Medien (Dienste zum Abspielen und Aufzeichnen von Medien).
  • Hardware-Abstraktionsschicht (HAL) . Eine HAL definiert eine Standardschnittstelle, die Hardwareanbieter implementieren müssen, wodurch Android unabhängig von Treiberimplementierungen auf niedrigerer Ebene sein kann. Durch die Verwendung einer HAL können Sie Funktionen implementieren, ohne das übergeordnete System zu beeinflussen oder zu modifizieren. HAL-Implementierungen werden in Module gepackt und zum geeigneten Zeitpunkt vom Android-System geladen. Einzelheiten finden Sie unter Hardware Abstraction Layer (HAL) .
  • Linux-Kernel . Die Entwicklung Ihrer Gerätetreiber ähnelt der Entwicklung eines typischen Linux-Gerätetreibers. Android verwendet eine Version des Linux-Kernels mit einigen speziellen Ergänzungen wie Low Memory Killer (ein Speicherverwaltungssystem, das aggressiver bei der Erhaltung des Speichers ist), Wake Locks (ein PowerManager -Systemdienst), dem Binder IPC-Treiber und anderen wichtigen Funktionen für eine mobile eingebettete Plattform. Diese Ergänzungen dienen hauptsächlich der Systemfunktionalität und wirken sich nicht auf die Treiberentwicklung aus. Sie können jede Version des Kernels verwenden, solange sie die erforderlichen Funktionen unterstützt (z. B. den Binder-Treiber). Wir empfehlen jedoch, die neueste Version des Android-Kernels zu verwenden. Einzelheiten finden Sie unter Erstellen von Kerneln .

HAL-Schnittstellendefinitionssprache (AIDL/HIDL)

Android 8.0 hat das Android-Betriebssystem-Framework (in einem Projekt namens Treble ) neu gestaltet, um es für Hersteller einfacher, schneller und kostengünstiger zu machen, Geräte auf eine neue Version von Android zu aktualisieren. In dieser neuen Architektur spezifiziert die HAL-Schnittstellendefinitionssprache (HIDL, ausgesprochen „hide-l“) die Schnittstelle zwischen einer HAL und ihren Benutzern, wodurch das Android-Framework ersetzt werden kann, ohne die HALs neu zu erstellen. In Android 10 wurden HIDL-Funktionen in AIDL integriert. Seitdem ist HIDL veraltet und wird nur noch von Subsystemen verwendet, die noch nicht auf AIDL umgestellt wurden.

Treble trennt die Anbieterimplementierung (gerätespezifische, untergeordnete Software, die von Siliziumherstellern geschrieben wurde) vom Android-Betriebssystem-Framework über eine neue Anbieterschnittstelle. Anbieter oder SOC-Hersteller erstellen HALs einmal und platzieren sie in einer /vendor -Partition auf dem Gerät; Das Framework in seiner eigenen Partition kann dann durch ein Over-the-Air-Update (OTA) ersetzt werden, ohne die HALs neu zu kompilieren.

Der Unterschied zwischen der alten Android-Architektur und der aktuellen, IDL-basierten Architektur liegt in der Verwendung der Herstellerschnittstelle:

  • In Android 7.x und früher gibt es keine formale Herstellerschnittstelle, daher müssen Gerätehersteller große Teile des Android-Codes aktualisieren, um ein Gerät auf eine neuere Version von Android zu verschieben:

    Abbildung 2. Legacy-Android-Update-Umgebung
  • In Android 8.0 und höher bietet eine neue stabile Anbieterschnittstelle Zugriff auf die hardwarespezifischen Teile von Android, sodass Gerätehersteller neue Android-Releases einfach durch Aktualisieren des Android-Betriebssystem-Frameworks bereitstellen können – ohne dass zusätzliche Arbeit von den Siliziumherstellern erforderlich ist:

    Abbildung 3. Aktuelle Android-Update-Umgebung

Alle neuen Geräte, die mit Android 8.0 und höher auf den Markt kommen, können die Vorteile der neuen Architektur nutzen. Um die Aufwärtskompatibilität von Anbieterimplementierungen sicherzustellen, wird die Anbieterschnittstelle durch die Vendor Test Suite (VTS) validiert, die analog zur Compatibility Test Suite (CTS) ist. Sie können VTS verwenden, um HAL- und OS-Kernel-Tests sowohl in älteren als auch in aktuellen Android-Architekturen zu automatisieren.

Architekturressourcen

Einzelheiten zur Android-Architektur finden Sie in den folgenden Abschnitten:

  • HAL-Typen . Beschreibt Binderized, Passthrough, Same-Process (SP) und Legacy-HALs.
  • AIDL . Dokumentation über AIDL, ob es allgemein oder als HAL-Schnittstelle verwendet wird.
  • HIDL (allgemein) . Enthält allgemeine Informationen über die Schnittstelle zwischen einer HAL und ihren Benutzern.
  • HIDL (C++) . Enthält Details zum Erstellen von C++-Implementierungen von HIDL-Schnittstellen.
  • HIDL (Java) . Enthält Details zum Java-Frontend für HIDL-Schnittstellen.
  • ConfigStore HAL . Beschreibt APIs für den Zugriff auf schreibgeschützte Konfigurationselemente, die zum Konfigurieren des Android-Frameworks verwendet werden.
  • Gerätebaum-Overlays . Enthält Details zur Verwendung von Gerätestruktur-Overlays (DTOs) in Android.
  • Herstellernatives Entwicklungskit (VNDK) . Beschreibt den Satz von anbieterexklusiven Bibliotheken zum Implementieren von Anbieter-HALs.
  • Lieferantenschnittstellenobjekt (VINTF) . Beschreibt die Objekte, die relevante Informationen über ein Gerät aggregieren und diese Informationen über eine abfragbare API verfügbar machen.
  • SELinux für Android 8.0 . Details zu SELinux-Änderungen und -Anpassungen.

Zusätzlich zu den Ressourcen auf dieser Website haben Mitglieder des Treble-Teams Treble: Fast Software Updates by Creating an Equilibrium in an Active Software Ecosystem of Globally Distributed Stakeholders veröffentlicht. Das Papier ist für ACM-Mitglieder kostenlos und Nichtmitglieder können die Zusammenfassung kaufen oder lesen.