Sie können bedingt kompilierten Code so umstrukturieren, dass Werte dynamisch aus der HAL-Schnittstelle gelesen werden. Beispiel:
#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS // some code fragment #endif
Framework-Code kann dann je nach Typ eine entsprechende in <configstore/Utils.h>
definierte Dienstprogrammfunktion aufrufen.
ConfigStore-Beispiel
In diesem Beispiel wird TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
gelesen, das in ConfigStore HAL als forceHwcForVirtualDisplays()
mit dem Rückgabetyp OptionalBool
definiert ist:
#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 (getBool
im Beispiel oben) kontaktiert den configstore
-Dienst, um den Handle für den Proxy der Schnittstellenfunktion abzurufen, und ruft dann den Wert ab, indem sie den Handle über HIDL/hwbinder aufruft.
Dienstfunktionen
<configstore/Utils.h>
(configstore/1.0/include/configstore/Utils.h
) bietet Dienstprogrammfunktionen für jeden primitiven Rückgabetyp, einschließlich Optional[Bool|String|Int32|UInt32|Int64|UInt64]
, wie unten aufgeführt:
Eingeben | 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 in der HAL-Implementierung kein Wert für das Konfigurationselement angegeben ist. Jede Funktion nimmt zwei Vorlagenparameter an:
I
ist der Name der Schnittstellenklasse.Func
ist der Memberfunktions-Pointer zum Abrufen des Konfigurationselements.
Da der Konfigurationswert schreibgeschützt ist und sich nicht ändert, wird er von der Dienstprogrammfunktion intern im Cache gespeichert. Nachfolgende Aufrufe werden mithilfe des im Cache derselben Verknüpfungseinheit gespeicherten Werts effizienter ausgeführt.
configstore-utils verwenden
Die ConfigStore HAL ist für vorwärtskompatible Upgrades auf Minor-Versionen ausgelegt. Das bedeutet, dass der ConfigStore-Dienst mit einer älteren Minor-Version in /vendor
auch dann verwendet werden kann, wenn die HAL überarbeitet wird und in einigen Framework-Codes die neu eingeführten Elemente verwendet werden.
Für die Zukunftssicherheit muss Ihre Implementierung die folgenden Richtlinien einhalten:
- Für neue Elemente wird der Standardwert verwendet, 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 enthält.
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 Benutzeroberfläche der alten Version abgerufen werden. Wenn im folgenden Beispiel die installierte Version „v1_1“ ist, muss der Dienst „v1_1“ 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 werden, wird Punkt 1 durch die Implementierung und Punkt 2 durch Compilerfehler garantiert. Aus diesen Gründen empfehlen wir dringend, nach Möglichkeit configstore-utils
zu verwenden.