HAL ConfigStore

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

L'HAL ConfigStore rimane in AOSP per supportare le partizioni fornitore legacy. Sui dispositivi con Android 10 o versioni successive, surfaceflinger legge prima le proprietà di sistema; se non è definita alcuna proprietà di sistema per un elemento di configurazione in `SurfaceFlingerProperties.sysprop`, `surfaceflinger` torna alla 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). A seguito di questa modifica, la compilazione condizionale deve essere rimossa dai moduli installati nella partizione di sistema e questi moduli devono determinare la configurazione del sistema in fase di runtime (e comportarsi in modo diverso a seconda della configurazione).

L'HAL ConfigStore fornisce un insieme 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 il motivo per cui le proprietà di sistema non sono state utilizzate per questo scopo); altre pagine di 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 ConfigStore, vedi Aggiunta di classi e 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 dei valori. Le proprietà di sistema hanno limiti rigidi sulla lunghezza dei valori (92 byte). Inoltre, poiché questi limiti sono stati esposti direttamente alle app per 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 struct) devono essere codificati/decodificati dai client (ad esempio, "aaa,bbb,ccc" può essere codificato come array di tre stringhe).
  • Sovrascritture. Poiché le proprietà di sistema di sola lettura sono implementate come proprietà di scrittura singola, i fornitori/ODM che vogliono eseguire l'override dei valori di sola lettura definiti da AOSP devono importare i propri valori di sola lettura prima di quelli definiti da AOSP. Di conseguenza, i valori riscrivibili definiti dal fornitore vengono sostituiti dai valori definiti da AOSP.
  • Requisiti dello spazio di indirizzi. Le proprietà di sistema occupano una quantità relativamente elevata di spazio di indirizzi in ogni processo. Le proprietà di sistema sono raggruppate in unità prop_area di dimensioni fisse pari a 128 KB, tutte allocate a uno spazio di indirizzi di processo anche se viene eseguito l'accesso a una sola proprietà di sistema. 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 che le proprietà di 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 la condivisione in tempo reale di alcuni elementi aggiornati dinamicamente su tutto Android e che era necessario un nuovo sistema dedicato all'accesso agli elementi di configurazione di sola lettura.

Progettazione HAL ConfigStore

Il design di base è semplice:

Progettazione HAL Configstore

Figura 1. Progettazione HAL ConfigStore

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

Gli elementi di configurazione attualmente a cui fa riferimento il framework sono inclusi in un pacchetto HIDL con controllo delle versioni (android.hardware.configstore@1.0). I fornitori/OEM forniscono valori agli elementi di configurazione implementando 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 interessati dalla stessa norma SELinux. Se uno o più flag di build devono avere criteri SELinux diversi, devono essere separati in un'altra interfaccia. Ciò potrebbe richiedere una revisione importante di android.hardware.configstore package, in quanto le interfacce separate non sono più compatibili con le versioni precedenti.