ConfigStore HAL

Android 8.0 spaltet die monolithischen Android OS in generic ( system.img ) und hardwarespezifische ( vendor.img und odm.img ) Partitionen. Infolge 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).

Die 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 von ConfigStore HAL beschrieben (und warum zu diesem Zweck keine Systemeigenschaften verwendet wurden); andere Seiten in diesem Abschnitt detailliert die HAL - surfaceflinger Schnittstelle , Service - Implementierung und clientseitige Nutzung , die alle mit surfaceflinger als Beispiel. Für Hilfe bei ConfigStore Interface - Klassen finden Sie Hinzufügen von Interface - Klassen und Objekte .

Warum nicht Systemeigenschaften verwenden?

Wir haben überlegt, Systemeigenschaften zu verwenden, fanden jedoch mehrere grundlegende Probleme, darunter:

  • Längenbeschränkungen für Werte. Systemeigenschaften haben 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 Abwärtskompatibilitätsproblemen führen.
  • Keine Typunterstützung. Alle Werte sind im Wesentlichen Strings und APIs einfach den String in ein parsen int oder bool . Andere zusammengesetzte Datentypen (beispielsweise, array und struct) kodiert werden soll / von den Clients decodiert (beispielsweise "aaa,bbb,ccc" kann als eine Anordnung von drei Strings 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 herstellerdefinierte wiederbeschreibbare Werte von AOSP-definierten Werten überschrieben werden.
  • Anforderungen an den Adressraum. Systemeigenschaften nehmen in jedem Prozess relativ viel Adressraum ein. Systemeigenschaften sind in gruppieren prop_area Einheiten mit einer festen Größe von 128 KB, die alle auf eine Prozessadressraum zugeordnet ist , selbst wenn nur eine einzige Systemeigenschaft darin zugegriffen wird. Dies kann bei 32-Bit-Geräten, bei denen der Adressraum kostbar ist, zu Problemen führen.

Wir haben versucht, diese Einschränkungen zu überwinden, ohne die Kompatibilität zu beeinträchtigen, waren jedoch weiterhin besorgt, dass die Systemeigenschaften nicht dafür ausgelegt sind, den Zugriff auf schreibgeschützte Konfigurationselemente zu unterstützen. Schließlich haben wir entschieden, dass Systemeigenschaften besser geeignet sind, um einige dynamisch aktualisierte Elemente in Echtzeit in ganz Android zu teilen, und dass ein neues System für den Zugriff auf schreibgeschützte Konfigurationselemente benötigt wird.

ConfigStore HAL-Design

Das Grunddesign ist einfach:

Configstore HAL-Design

Abbildung 1. ConfigStore HAL - Design

  • Beschreiben von Build-Flags (derzeit zum bedingten Kompilieren 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 zur Zeit durch den Rahmen referenziert werden in einem versioniert HIDL Paket (inklusive android.hardware.configstore@1.0 ). 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 eine oder mehr Build - Flaggen verschiedene SELinux - Richtlinien haben sollen, müssen sie an einem anderen Schnittstelle getrennt werden. Dies kann große Überarbeitung von erfordern android.hardware.configstore package als die getrennten Schnittstellen sind nicht mehr abwärtskompatibel.