Diese Seite wurde von der Cloud Translation API übersetzt.

Clientseitige Verwendung

Sie können bedingt kompilierten Code refaktorieren, um Werte dynamisch aus der HAL-Schnittstelle. Beispiel:

#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
// some code fragment
#endif

Der Framework-Code kann dann eine entsprechende Dienstfunktion aufrufen, die in den <configstore/Utils.h> je nach Typ.

ConfigStore-Beispiel

In diesem Beispiel sehen Sie, TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS, in ConfigStore HAL definiert als forceHwcForVirtualDisplays() mit Rückgabetyp OptionalBool:

#include <configstore/Utils.h>
using namespace android::hardware::configstore;
using namespace android::hardware::configstore::V1_0;

static bool vsyncPhaseOffsetNs = getBool<ISurfaceFlingerConfigs,
        ISurfaceFlingerConfigs::forceHwcForVirtualDisplays>(false);

Die Dienstprogrammfunktion (im obigen Beispiel getBool) kontaktiert die configstore, um das Handle für den Proxy des Interface-Funktion und ruft dann den Wert ab, indem der Handle über HIDL/hwbinder.

Dienstprogrammfunktionen

Typ	Funktion (Vorlagenparameter ausgelassen)
`OptionalBool`	`bool getBool(const bool defValue)`
`OptionalInt32`	`int32_t getInt32(const int32_t defValue)`
`OptionalUInt32`	`uint32_t getUInt32(const uint32_t defValue)`
`OptionalInt64`	`int64_t getInt64(const int64_t defValue)`
`OptionalUInt64`	`uint64_t getUInt64(const uint64_t defValue)`
`OptionalString`	`std::string getString(const std::string &defValue)`

defValue ist ein Standardwert, der zurückgegeben wird, wenn die HAL-Implementierung gibt keinen Wert für das Konfigurationselement an. Jede Funktion benötigt zwei Vorlagenparameter:

I ist der Name der Schnittstellenklasse.
Func ist der Member-Funktionszeiger für das Konfigurationselement abzurufen.

Da der Konfigurationswert schreibgeschützt ist und sich nicht ändert, kann das Dienstprogramm wird der Konfigurationswert intern im Cache gespeichert. Nachfolgende Aufrufe werden mithilfe des im Cache gespeicherten Werts innerhalb einer Verknüpfungseinheit effizienter verwaltet werden.

configstore-utils verwenden

Der ConfigStore HAL ist so konzipiert, dass er für Nebenversionen aufwärtskompatibel ist Upgrades, was bedeutet, dass bei der Überarbeitung des HAL und verwendet die neu eingeführten Elemente, den ConfigStore-Dienst mit einer älteren Version in /vendor kann weiterhin verwendet werden.

Um Aufwärtskompatibilität zu gewährleisten, muss Ihre Implementierung die folgenden Richtlinien:

Neue Elemente verwenden den Standardwert, wenn nur der Dienst der alten Version verfügbar ist. Beispiel:

service = V1_1::IConfig::getService(); // null if V1_0 is installed
value = DEFAULT_VALUE;
  if(service) {
    value = service->v1_1API(DEFAULT_VALUE);
  }

Der Client verwendet die erste Schnittstelle, die das ConfigStore-Element enthielt. Beispiel:

V1_1::IConfig::getService()->v1_0API(); // NOT ALLOWED

V1_0::IConfig::getService()->v1_0API(); // OK

Der Dienst der neuen Version kann für die Schnittstelle der alten Version abgerufen werden. In Beispiel: Wenn die installierte Version v1_1 lautet, muss der v1_1-Dienst für getService() zurückgegeben werden:
```
V1_0::IConfig::getService()->v1_0API();
```
Hinweis:Das aktuell Die AOSP-Implementierung erfüllt diese Anforderung.

Wenn die Zugriffsfunktionen in der configstore-utils-Bibliothek für den Zugriff auf das ConfigStore-Element verwendet wird, wird Nummer 1 durch die Implementierung und #2 durch Compilerfehler garantiert wird. Aus diesen Gründen empfehlen, nach Möglichkeit configstore-utils zu verwenden.