ConfigStore HAL

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

L'HAL 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 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 diversamente a seconda di tale configurazione).

L'HAL ConfigStore fornisce un set di API per accedere 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 , utilizzando tutti surfaceflinger come esempio. Per assistenza con le classi di interfaccia ConfigStore, vedere Aggiunta di classi ed elementi di interfaccia .

Perché non utilizzare le proprietà di sistema?

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

  • Limiti di lunghezza sui valori. Le proprietà del sistema hanno limiti stretti 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 supporto per il tipo. 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 struttura) devono essere codificati/decodificati dai client (ad esempio, "aaa,bbb,ccc" può essere codificato come un array 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.
  • Rispondere ai requisiti di spazio. 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 in uno spazio di indirizzi del processo anche se si accede a una sola proprietà di sistema in esso contenuta. 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 continuavamo a temere 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à del sistema erano 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 del negozio di configurazione

Figura 1. Progettazione dell'HAL ConfigStore

  • Descrivi i flag di build (attualmente utilizzati per la compilazione condizionale del framework) in HIDL.
  • Fornitori e 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 a cui fa attualmente 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 utilizza le interfacce quando deve ottenere un valore per un elemento di configurazione.

Considerazioni sulla sicurezza

I flag di build definiti nella stessa interfaccia sono influenzati dalla stessa policy SELinux. Se uno o più flag di build devono avere politiche SELinux diverse, 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.