ConfigStore HAL

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In Android 10, ConfigStore HAL utilizza i flag di build per archiviare i valori di configurazione nella partizione del vendor e un servizio nella partizione di system accede a tali valori utilizzando HIDL (questo vale anche in Android 9). Tuttavia, a causa dell'elevato consumo di memoria e dell'utilizzo difficile, l'HAL di ConfigStore è stato deprecato.

L'HAL di ConfigStore rimane in AOSP per supportare le partizioni del fornitore legacy. Sui dispositivi con Android 10 o versioni successive, surfaceflinger legge prima le proprietà del sistema; se non è definita alcuna proprietà di sistema per un elemento di configurazione in `SurfaceFlingerProperties.sysprop`, `surfaceflinger` ritorna all'HAL di ConfigStore.

Android 8.0 suddivide il sistema operativo Android monolitico in partizioni generiche ( system.img ) e specifiche dell'hardware ( vendor.img e odm.img ). Come risultato di questa modifica, la compilazione condizionale deve essere rimossa dai moduli installati nella partizione di sistema e tali moduli devono determinare la configurazione del sistema in fase di esecuzione (e comportarsi in modo diverso a seconda di tale configurazione).

ConfigStore HAL fornisce un set di API per l'accesso agli elementi di configurazione di sola lettura utilizzati per configurare il framework Android. Questa pagina descrive la progettazione di ConfigStore HAL (e perché le proprietà di sistema non sono state utilizzate per questo scopo); altre pagine in questa sezione descrivono in dettaglio l' interfaccia HAL , l' implementazione del servizio e l'utilizzo lato client , il tutto utilizzando surfaceflinger come esempio. Per assistenza con le classi di interfaccia di ConfigStore, vedere Aggiunta di classi ed elementi di interfaccia .

Perché non utilizzare le proprietà di sistema?

Abbiamo considerato l'utilizzo delle proprietà di sistema, ma abbiamo riscontrato diversi problemi fondamentali, tra cui:

  • Limiti di lunghezza sui valori. Le proprietà di sistema hanno limiti rigorosi sulla lunghezza dei loro valori (92 byte). Inoltre, poiché questi limiti sono stati esposti direttamente alle app Android come macro C, l'aumento della lunghezza può causare problemi di compatibilità con le versioni precedenti.
  • Nessun tipo di supporto. Tutti i valori sono essenzialmente stringhe e le API analizzano semplicemente la stringa in un int o bool . Altri tipi di dati composti (ad esempio, array e struct) devono essere codificati/decodificati dai client (ad esempio, "aaa,bbb,ccc" può essere codificato come una matrice di tre stringhe).
  • Sovrascrive. Poiché le proprietà di sistema di sola lettura sono implementate come proprietà di sola lettura, i fornitori/ODM che desiderano sovrascrivere i valori di sola lettura definiti da AOSP devono importare i propri valori di sola lettura prima dei valori di sola lettura definiti da AOSP. Ciò, a sua volta, fa sì che i valori riscrivibili definiti dal fornitore vengano sovrascritti dai valori definiti da AOSP.
  • Requisiti di spazio degli indirizzi. Le proprietà di sistema occupano una quantità relativamente grande di spazio di indirizzi in ogni processo. Le proprietà di sistema sono raggruppate in unità prop_area con una dimensione fissa di 128 KB, tutte allocate a uno spazio di indirizzi di processo anche se si accede solo a una singola proprietà di sistema in esso. Ciò può causare problemi sui dispositivi a 32 bit in cui lo spazio degli indirizzi è prezioso.

Abbiamo tentato di superare queste limitazioni senza sacrificare la compatibilità, ma abbiamo continuato a preoccuparci del fatto che le proprietà del sistema non fossero progettate per supportare l'accesso agli elementi di configurazione di sola lettura. Alla fine abbiamo deciso che le proprietà di sistema sono più adatte per condividere alcuni elementi aggiornati dinamicamente su tutto Android in tempo reale e che esisteva la necessità di un nuovo sistema dedicato all'accesso agli elementi di configurazione di sola lettura.

Progettazione HAL di ConfigStore

Il design di base è semplice:

Progettazione HAL di Configstore

Figura 1. Progettazione HAL di ConfigStore

  • Descrivi i flag di build (attualmente utilizzati per la compilazione condizionale del framework) in HIDL.
  • I fornitori e gli OEM forniscono valori SoC e specifici del dispositivo per i flag di build implementando il servizio HAL.
  • Modificare il framework per utilizzare il servizio HAL per trovare il valore di un elemento di configurazione in fase di esecuzione.

Gli elementi di configurazione attualmente a cui fa riferimento il framework sono inclusi in un pacchetto HIDL con versione ( android.hardware.configstore@1.0 ). I fornitori/OEM forniscono valori agli elementi di configurazione implementando le interfacce in questo pacchetto e il framework usa le interfacce quando è necessario ottenere un valore per un elemento di configurazione.

Considerazioni sulla sicurezza

I flag di build definiti nella stessa interfaccia sono influenzati dalla stessa politica di SELinux. Se uno o più flag di build devono avere policy SELinux differenti, devono essere separati su un'altra interfaccia . Ciò può richiedere una revisione importante del android.hardware.configstore package poiché le interfacce separate non sono più compatibili con le versioni precedenti.