ConfigStore HAL

Android 8.0 spaltet das monolithische Android-Betriebssystem in generische ( system.img ) und hardwarespezifische ( vendor.img und odm.img ) Partitionen auf. Als Ergebnis dieser Änderung muss die bedingte Kompilierung von Modulen entfernt werden, die auf der Systempartition installiert sind, und solche Module müssen die Konfiguration des Systems zur Laufzeit bestimmen (und sich abhängig von dieser Konfiguration anders verhalten).

Die ConfigStore-HAL bietet eine Reihe von APIs für den Zugriff auf schreibgeschützte Konfigurationselemente, die zum Konfigurieren des Android-Frameworks verwendet werden. Diese Seite beschreibt das Design von ConfigStore HAL (und warum Systemeigenschaften nicht für diesen Zweck verwendet wurden); Auf anderen Seiten in diesem Abschnitt werden die HAL-Schnittstelle , die Dienstimplementierung und die Verwendung auf Client-Seite detailliert beschrieben, wobei alle surfaceflinger als Beispiel verwendet werden. Hilfe zu ConfigStore-Schnittstellenklassen finden Sie unter Hinzufügen von Schnittstellenklassen und -elementen .

Warum nicht Systemeigenschaften verwenden?

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

  • Längenbeschränkungen für Werte. Systemeigenschaften haben enge Grenzen für die Länge ihrer Werte (92 Byte). Da diese Beschränkungen außerdem Android-Apps direkt als C-Makros ausgesetzt wurden, kann eine Erhöhung der Länge zu Abwärtskompatibilitätsproblemen führen.
  • Keine Typenunterstützung. Alle Werte sind im Wesentlichen Zeichenfolgen, und APIs parsen die Zeichenfolge einfach in ein int oder bool . Andere zusammengesetzte Datentypen (z. B. Array und Struktur) sollten von den Clients codiert/decodiert werden (z. B. "aaa,bbb,ccc" kann als Array aus drei Zeichenfolgen codiert werden).
  • Überschreibt. Da schreibgeschützte Systemeigenschaften als einmal beschreibbare Eigenschaften implementiert sind, müssen Anbieter/ODMs, die AOSP-definierte schreibgeschützte Werte überschreiben möchten, ihre eigenen schreibgeschützten Werte vor AOSP-definierten schreibgeschützten Werten importieren. Dies wiederum führt dazu, dass vom Hersteller definierte überschreibbare Werte durch AOSP-definierte Werte überschrieben werden.
  • Platzanforderungen ansprechen. Systemeigenschaften beanspruchen in jedem Prozess relativ viel Adressraum. Systemeigenschaften werden in prop_area Einheiten mit einer festen Größe von 128 KB gruppiert, die alle einem Prozessadressraum zugewiesen werden, selbst wenn nur auf eine einzelne Systemeigenschaft darin zugegriffen wird. Dies kann auf 32-Bit-Geräten, auf denen Adressraum kostbar ist, zu Problemen führen.

Wir haben versucht, diese Einschränkungen zu überwinden, ohne die Kompatibilität zu opfern, hatten aber weiterhin Bedenken, dass die Systemeigenschaften nicht darauf ausgelegt sind, den Zugriff auf schreibgeschützte Konfigurationselemente zu unterstützen. Schließlich entschieden wir, dass Systemeigenschaften besser geeignet sind, um einige wenige dynamisch aktualisierte Elemente in Echtzeit auf ganz Android zu teilen, und dass ein Bedarf für ein neues System besteht, das für den Zugriff auf schreibgeschützte Konfigurationselemente bestimmt ist.

ConfigStore-HAL-Design

Das Grunddesign 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 es den HAL-Dienst verwendet, um den Wert eines Konfigurationselements zur Laufzeit zu finden.

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

Sicherheitsüberlegungen

Build-Flags, die in derselben Schnittstelle definiert sind, sind von derselben SELinux-Richtlinie betroffen. Wenn ein oder mehrere Build-Flags unterschiedliche SELinux-Richtlinien haben sollen, müssen sie auf eine andere Schnittstelle getrennt werden . Dies kann eine umfassende Überarbeitung des android.hardware.configstore package erfordern, da die getrennten Schnittstellen nicht mehr abwärtskompatibel sind.