ConfigStore HAL

In Android 10 verwendet ConfigStore HAL Build-Flags, um Konfigurationswerte in der Partition vendor zu speichern. Ein Dienst in der Partition system greift dann über HIDL auf diese Werte zu. Das gilt auch für Android 9. Aufgrund des hohen Arbeitsspeicherverbrauchs und der schwierigen Nutzung wurde die ConfigStore HAL jedoch eingestellt.

Die ConfigStore HAL bleibt in AOSP, um alte Anbieterpartitionen zu unterstützen. Auf Geräten mit Android 10 oder höher liest surfaceflinger zuerst Systemeigenschaften. Wenn für ein Konfigurationselement in „SurfaceFlingerProperties.sysprop“ keine Systemeigenschaft definiert ist, greift „surfaceflinger“ auf die ConfigStore HAL zurück.

Android 8.0 teilt das monolithische Android-Betriebssystem in generische Partitionen (system.img) und hardwarespezifische Partitionen (vendor.img und odm.img) auf. Aufgrund dieser Änderung muss die bedingte Kompilierung aus den Modulen entfernt werden, die in der Systempartition installiert sind. Diese Module müssen die Konfiguration des Systems zur Laufzeit bestimmen und sich je nach Konfiguration unterschiedlich verhalten.

Die ConfigStore HAL bietet eine Reihe von APIs für den Zugriff auf schreibgeschützte Konfigurationselemente, mit denen das Android-Framework konfiguriert wird. Auf dieser Seite wird das Design der ConfigStore HAL beschrieben (und warum Systemeigenschaften nicht für diesen Zweck verwendet wurden). Auf anderen Seiten in diesem Abschnitt werden die HAL-Schnittstelle, die Dienstimplementierung und die clientseitige Verwendung beschrieben, wobei jeweils surfaceflinger als Beispiel verwendet wird. Informationen zu ConfigStore-Schnittstellenklassen finden Sie unter Schnittstellenklassen und ‑elemente hinzufügen.

Warum sollten Sie keine Systemeigenschaften verwenden?

Wir haben die Verwendung von Systemeigenschaften in Betracht gezogen, aber dabei mehrere grundlegende Probleme festgestellt, darunter:

  • Längenbeschränkungen für Werte: Die Länge der Werte von Systemeigenschaften ist stark eingeschränkt (92 Byte). Da diese Limits Android-Apps direkt als C-Makros angezeigt wurden, kann eine längere Länge zu Problemen mit der Abwärtskompatibilität führen.
  • Keine Typunterstützung. Alle Werte sind im Grunde Strings und APIs parsen den String einfach in eine int oder bool. Andere zusammengesetzte Datentypen (z. B. Array und Struktur) sollten von den Clients codiert/decodiert werden. Beispielsweise kann "aaa,bbb,ccc" als Array aus drei Strings codiert werden.
  • Überschreibungen Da schreibgeschützte Systemeigenschaften als einmal beschreibbare Eigenschaften implementiert sind, müssen Anbieter/ODMs, die von AOSP definierte schreibgeschützte Werte überschreiben möchten, ihre eigenen schreibgeschützten Werte vor den von AOSP definierten schreibgeschützten Werten importieren. Dies führt wiederum dazu, dass vom Hersteller definierte überschreibbare Werte von AOSP-definierten Werten überschrieben werden.
  • Anforderungen an den Adressraum Systemeigenschaften benötigen bei jedem Prozess einen relativ großen Adressbereich. Systemeigenschaften werden in prop_area-Einheiten mit einer festen Größe von 128 KB gruppiert. Diese werden einem Prozessadressraum zugewiesen, auch wenn nur auf eine einzelne Systemeigenschaft darin zugegriffen wird. Dies kann auf 32-Bit-Geräten zu Problemen führen, auf denen der Adressraum knapp ist.

Wir haben versucht, diese Einschränkungen zu beheben, ohne die Kompatibilität zu beeinträchtigen. Wir waren jedoch weiterhin besorgt, dass Systemeigenschaften nicht für den Zugriff auf schreibgeschützte Konfigurationselemente konzipiert wurden. Letztendlich haben wir uns entschieden, dass Systemeigenschaften besser geeignet sind, um einige dynamisch aktualisierte Elemente in Echtzeit für alle Android-Geräte freizugeben. Außerdem bestand Bedarf an einem neuen System, das speziell für den Zugriff auf schreibgeschützte Konfigurationselemente entwickelt wurde.

ConfigStore HAL-Design

Das grundlegende Design ist einfach:

Configstore HAL-Design

Abbildung 1. ConfigStore HAL-Design

  • Beschreiben Sie Build-Flags (aktuell für die bedingte Kompilierung des Frameworks verwendet) in HIDL.
  • Anbieter und OEMs stellen SoC- und gerätespezifische Werte für Build-Flags bereit, indem sie den HAL-Dienst implementieren.
  • Ändern Sie das Framework so, dass der HAL-Dienst verwendet wird, um den Wert eines Konfigurationselements zur Laufzeit zu ermitteln.

Konfigurationselemente, auf die derzeit vom Framework verwiesen wird, sind in einem versionierten HIDL-Paket (android.hardware.configstore@1.0) enthalten. Anbieter/OEMs stellen Werte für die Konfigurationselemente bereit, indem sie in diesem Paket Schnittstellen implementieren. Das Framework verwendet die Schnittstellen, wenn es einen Wert für ein Konfigurationselement abrufen muss.

Sicherheitsaspekte

Build-Flags, die in derselben Benutzeroberfläche definiert sind, unterliegen derselben SELinux-Richtlinie. Wenn eine oder mehrere Build-Flags unterschiedliche SELinux-Richtlinien haben sollen, müssen sie in einer anderen Schnittstelle getrennt werden. Dies kann eine umfassende Überarbeitung von android.hardware.configstore package erfordern, da die getrennten Benutzeroberflächen nicht mehr abwärtskompatibel sind.