ConfigStore HAL

In Android 10 verwendet ConfigStore HAL Build-Flags, um Konfigurationswerte in der vendor zu speichern, und ein Dienst in der system greift mithilfe von HIDL auf diese Werte zu (dies gilt auch in Android 9). Aufgrund des hohen Speicherverbrauchs und der schwierigen Nutzung ist der ConfigStore HAL jedoch veraltet.

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

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

Der 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 Serviceimplementierung und die clientseitige Nutzung detailliert beschrieben, jeweils am Beispiel von surfaceflinger . Hilfe zu ConfigStore-Schnittstellenklassen finden Sie unter Hinzufügen von Schnittstellenklassen und -elementen .

Warum nicht Systemeigenschaften verwenden?

Wir haben über die Verwendung von Systemeigenschaften nachgedacht, sind jedoch auf mehrere grundlegende Probleme gestoßen, darunter:

  • Längenbeschränkungen für Werte. Für Systemeigenschaften gelten enge Grenzen hinsichtlich der Länge ihrer Werte (92 Byte). Da diese Beschränkungen 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 Typunterstützung. Alle Werte sind im Wesentlichen Zeichenfolgen, und APIs analysieren die Zeichenfolge einfach in ein int oder bool . Andere zusammengesetzte Datentypen (z. B. Array und Struktur) sollten von den Clients kodiert/dekodiert werden (z. B. "aaa,bbb,ccc" kann als Array aus drei Zeichenfolgen kodiert 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 den von AOSP definierten schreibgeschützten Werten importieren. Dies wiederum führt dazu, dass vom Hersteller definierte wiederbeschreibbare Werte durch AOSP-definierte Werte überschrieben werden.
  • Adressieren Sie den Platzbedarf. 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, auch wenn nur auf eine einzelne Systemeigenschaft darin zugegriffen wird. Dies kann auf 32-Bit-Geräten zu Problemen führen, bei denen der Adressraum kostbar ist.

Wir haben versucht, diese Einschränkungen zu überwinden, ohne die Kompatibilität zu beeinträchtigen, hatten aber weiterhin Bedenken, dass die Systemeigenschaften nicht für die Unterstützung des Zugriffs auf schreibgeschützte Konfigurationselemente ausgelegt sind. Schließlich kamen wir zu dem Schluss, dass Systemeigenschaften besser geeignet sind, um ein paar dynamisch aktualisierte Elemente in Android in Echtzeit zu teilen, und dass ein Bedarf für ein neues System besteht, das sich dem Zugriff auf schreibgeschützte Konfigurationselemente widmet.

ConfigStore HAL-Design

Der Grundaufbau 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, um den HAL-Dienst zu verwenden, 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, 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.