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
Dieses Beispiel zeigt Folgendes:
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 das Handle über
HIDL/hwbinder.
Dienstprogrammfunktionen
<configstore/Utils.h>
(configstore/1.0/include/configstore/Utils.h
) bietet Nutzen
für jeden primitiven Rückgabetyp, einschließlich
Optional[Bool|String|Int32|UInt32|Int64|UInt64]
, wie angegeben
unten:
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();
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.