Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. 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 über 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, die zum Konfigurieren des Android-Frameworks verwendet werden. 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 implementierung und die clientseitige Verwendung anhand von surfaceflinger als Beispiel beschrieben. Hilfe zu ConfigStore Schnittstellenklassen finden Sie unter Schnittstellenklassen 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 Wesentlichen Strings und APIs parsen den String einfach in einen int oder bool. Andere zusammengesetzte Datentypen (z. B. Array und Struct) sollten von den Clients codiert/decodiert werden (z. B. kann "aaa,bbb,ccc" als Array von drei Strings codiert werden).
Überschreibungen Da schreibgeschützte Systemeigenschaften als einmal beschreibbare Eigenschaften implementiert werden, 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. Dies führt wiederum dazu, dass anbieterdefinierte überschreibbare Werte durch von 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 Adressraum wird einem Prozess zugewiesen, auch wenn nur auf eine einzelne Systemeigenschaft zugegriffen wird. Dies 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 entwickelt wurden. 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.

ConfigStore HAL-Design

Das grundlegende Design ist einfach:

Configstore-HAL-Design

Abbildung 1 : ConfigStore HAL-Design

Beschreiben Sie Build-Flags (die derzeit 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 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 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 einer anderen Schnittstelle getrennt werden. Dies kann eine größere Überarbeitung von android.hardware.configstore package erforderlich machen, da die getrennten Schnittstellen nicht mehr abwärtskompatibel sind.