Ab 2026 werden wir, um unser stabiles Entwicklungsmodell für den Trunk zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten, den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen. Verwenden Sie android-latest-release, um AOSP zu entwickeln und dazu beizutragen. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ConfigStore HAL

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

Die 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 in SurfaceFlingerProperties.sysprop keine Systemeigenschaft für ein Konfigurationselement definiert ist, greift surfaceflinger auf die ConfigStore HAL zurück.

In Android 8.0 wird das monolithische Android-Betriebssystem in generische (system.img) und hardwarespezifische Partitionen (vendor.img und odm.img) aufgeteilt. Infolge dieser Änderung muss die bedingte Kompilierung aus 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 erläutert, warum keine Systemeigenschaften für diesen Zweck verwendet wurden. Auf anderen Seiten in diesem Abschnitt werden die HAL-Schnittstelle, Dienst implementierungund die clientseitige Verwendunganhand von surfaceflinger beschrieben. Informationen zu ConfigStore Schnittstellenklassen finden Sie unter Schnittstellen klassen und ‑elemente hinzufügen.

Warum keine Systemeigenschaften?

Wir haben die Verwendung von Systemeigenschaften in Betracht gezogen, aber mehrere grundlegende Probleme festgestellt, 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 Beschränkungen Android-Apps außerdem direkt als C-Makros zur Verfügung gestellt wurden, kann eine Erhöhung der 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 einen int oder bool. Andere zusammengesetzte Datentypen (z. B. Array und Struktur) sollten von den Clients codiert/decodiert werden. So kann "aaa,bbb,ccc" beispielsweise als Array mit 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. Das führt wiederum dazu, dass anbieterdefinierte überschreibbare Werte durch von AOSP definierte Werte überschrieben werden.
Anforderungen an den Adressraum Systemeigenschaften belegen in jedem Prozess relativ viel Adressraum. Systemeigenschaften werden in prop_area-Einheiten mit einer festen Größe von 128 KB gruppiert. Der gesamte Adressraum wird einem Prozess zugewiesen, auch wenn nur auf eine einzelne Systemeigenschaft zugegriffen wird. Das kann auf 32-Bit-Geräten zu Problemen führen, bei denen der Adressraum begrenzt ist.

Wir haben versucht, diese Einschränkungen zu überwinden, 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 Systemeigenschaften besser geeignet sind, um einige dynamisch aktualisierte Elemente in Echtzeit für alle Android-Versionen freizugeben. Außerdem war ein neues System erforderlich, das speziell für den Zugriff auf schreibgeschützte Konfigurationselemente entwickelt wurde.

Design der ConfigStore HAL

Das grundlegende Design ist einfach:

Configstore-HAL-Design

Abbildung 1 : Design der ConfigStore HAL

Beschreiben Sie Build-Flags (die für die bedingte Kompilierung 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 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 ein Wert für ein Konfigurationselement abgerufen werden 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 verschoben werden. Das kann eine größere Überarbeitung von android.hardware.configstore package erforderlich machen, da die getrennten Schnittstellen nicht mehr abwärtskompatibel sind.