Puoi eseguire il refactoring del codice compilato in modo condizionale per leggere i valori in modo dinamico l'interfaccia dell'HAL. Ad esempio:
#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS // some code fragment #endif
Il codice framework può quindi chiamare una funzione di utilità appropriata definita
<configstore/Utils.h>
, a seconda del tipo.
Esempio di ConfigStore
Questo esempio mostra come si
TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
, definito in ConfigStore HAL
come forceHwcForVirtualDisplays()
con tipo restituito
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);
La funzione di utilità (getBool
nell'esempio precedente) contatta la
configstore
per ottenere l'handle per il proxy del
funzione di interfaccia, quindi recupera il valore richiamando l'handle tramite
HIDL/hwbinder.
Funzioni di utilità
<configstore/Utils.h>
(configstore/1.0/include/configstore/Utils.h
) fornisce utilità
per ogni tipo restituito primitivo, tra cui
Optional[Bool|String|Int32|UInt32|Int64|UInt64]
, come elencato
sotto:
Tipo | Funzione (parametri del modello omessi) |
---|---|
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
è un valore predefinito restituito quando l'implementazione dell'HAL
non specifica un valore per l'elemento di configurazione. Ogni funzione prende due
parametri del modello:
I
è il nome della classe dell'interfaccia.Func
è il puntatore della funzione membro per recuperando l'elemento di configurazione.
Poiché il valore di configurazione è di sola lettura e non cambia, l'utilità memorizza internamente il valore di configurazione. Le chiamate successive vengono il servizio viene gestito in modo più efficiente utilizzando il valore memorizzato nella cache nella stessa unità di collegamento.
Utilizzare configstore-utils
Il ConfigStore HAL è progettato per essere compatibile con il forwarding per la versione secondaria
upgrade, il che significa che quando l'HAL viene rivisto e del codice del framework
utilizza gli elementi appena introdotti, il servizio ConfigStore con un elemento secondario meno recente
in /vendor
.
Per la compatibilità in avanti, assicurati che l'implementazione sia conforme alle linee guida seguenti:
- I nuovi elementi utilizzano il valore predefinito quando solo il servizio della versione precedente
è disponibile. Esempio:
service = V1_1::IConfig::getService(); // null if V1_0 is installed value = DEFAULT_VALUE; if(service) { value = service->v1_1API(DEFAULT_VALUE); }
- Il cliente utilizza la prima interfaccia che includeva l'elemento ConfigStore.
Esempio:
V1_1::IConfig::getService()->v1_0API(); // NOT ALLOWED V1_0::IConfig::getService()->v1_0API(); // OK
- È possibile recuperare il servizio della nuova versione utilizzando l'interfaccia della versione precedente. Nella
nell'esempio seguente, se la versione installata è v1_1, il servizio v1_1 deve
da restituire per
getService()
:V1_0::IConfig::getService()->v1_0API();
Quando le funzioni di accesso nella libreria configstore-utils
vengono
utilizzato per accedere all'elemento ConfigStore, il primo è garantito dall'implementazione
mentre il secondo è garantito da errori del compilatore. Per questi motivi,
consigliamo di utilizzare configstore-utils
quando possibile.