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 über HIDL auf diese Werte zu (dies gilt auch für Android 9). Aufgrund des hohen Arbeitsspeicherverbrauchs und der schwierigen Verwendung wurde der ConfigStore HAL jedoch eingestellt.

Der ConfigStore HAL bleibt in AOSP, um ältere 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.

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

Das ConfigStore HAL bietet eine Reihe von APIs für den Zugriff auf schreibgeschützte Konfigurationselemente, die zum Konfigurieren des Android-Frameworks verwendet werden. Auf dieser Seite wird das Design des ConfigStore HAL beschrieben und erläutert, warum Systemproperties nicht für diesen Zweck verwendet wurden. Auf anderen Seiten in diesem Abschnitt werden die HAL-Schnittstelle, die Dienstimplementierung und die clientseitige Verwendung beschrieben. Dabei wird surfaceflinger als Beispiel verwendet. Hilfe zu ConfigStore-Schnittstellenklassen finden Sie unter Schnittstellenklassen und ‑elemente hinzufügen.

Warum nicht Systemeigenschaften verwenden?

Wir haben die Verwendung von Systemeigenschaften in Betracht gezogen, sind aber auf mehrere grundlegende Probleme gestoßen, darunter:

  • Längenbeschränkungen für Werte: Für Systemeigenschaften gelten strenge Beschränkungen für die Länge ihrer Werte (92 Byte). Da diese Grenzwerte außerdem direkt für Android-Apps als C-Makros verfügbar gemacht wurden, kann eine Erhöhung der Länge zu Problemen mit der Abwärtskompatibilität führen.
  • Keine Unterstützung für Typen. Alle Werte sind im Grunde Strings und APIs parsen den String einfach in ein int oder bool. Andere zusammengesetzte Datentypen (z. B. Array und Struct) sollten von den Clients codiert/decodiert werden. "aaa,bbb,ccc" kann beispielsweise als Array mit drei Strings codiert werden.
  • Überschreibungen: Da schreibgeschützte Systemeigenschaften als „Write-Once“-Eigenschaften implementiert werden, müssen Anbieter/ODMs, die schreibgeschützte Werte überschreiben möchten, die in AOSP definiert sind, ihre eigenen schreibgeschützten Werte vor den in AOSP definierten schreibgeschützten Werten importieren. Dies führt wiederum dazu, dass vom Anbieter definierte überschreibbare Werte durch AOSP-definierte Werte überschrieben werden.
  • Anforderungen an den Adressraum: Systemeigenschaften nehmen in jedem Prozess relativ viel Adressraum ein. Systemeigenschaften werden in prop_area-Einheiten mit einer festen Größe von 128 KB gruppiert. Der gesamte Speicherplatz wird einem Prozessadressraum zugewiesen, auch wenn nur auf eine einzelne Systemeigenschaft darin zugegriffen wird. Dies kann auf 32-Bit-Geräten, auf denen der Adressraum begrenzt ist, zu Problemen führen.

Wir haben versucht, diese Einschränkungen zu umgehen, ohne die Kompatibilität zu beeinträchtigen. Wir waren jedoch weiterhin besorgt, dass Systemeigenschaften nicht für den Zugriff auf schreibgeschützte Konfigurationselemente konzipiert sind. Schließlich haben wir entschieden, dass sich Systemeigenschaften besser eignen, um einige dynamisch aktualisierte Elemente in Echtzeit für alle Android-Versionen freizugeben. Außerdem haben wir festgestellt, dass ein neues System für den Zugriff auf schreibgeschützte Konfigurationselemente erforderlich ist.

ConfigStore HAL-Design

Das grundlegende Design ist einfach:

Configstore HAL-Design

Abbildung 1: ConfigStore HAL-Design

  • Beschreiben Sie Build-Flags (die derzeit zum bedingten Kompilieren des Frameworks verwendet werden) 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 Schnittstellen in diesem Paket implementieren. Das Framework verwendet die Schnittstellen, wenn es einen Wert für ein Konfigurationselement abrufen muss.

Sicherheitsaspekte

Build-Flags, die in derselben Schnittstelle definiert sind, unterliegen derselben SELinux-Richtlinie. Wenn für ein oder mehrere Build-Flags unterschiedliche SELinux-Richtlinien gelten sollen, müssen sie in eine andere Schnittstelle ausgelagert werden. Dafür ist möglicherweise eine grundlegende Überarbeitung von android.hardware.configstore package erforderlich, da die getrennten Schnittstellen nicht mehr abwärtskompatibel sind.