HAL ConfigStore

In Android 10, l'HAL ConfigStore utilizza i flag di compilazione per memorizzare 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 del fornitore precedenti. 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" passa all'HAL ConfigStore.

Android 8.0 suddivide il sistema operativo Android monolitico in parti generiche (system.img) e specifiche per l'hardware (vendor.img e odm.img). A seguito di questa variazione, 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 esecuzione (e comportarsi in modo diverso a seconda di questa 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 il design dell'HAL ConfigStore (e il motivo per cui le proprietà di sistema non sono state utilizzate a questo scopo). Le 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, consulta 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 per i valori. Le proprietà di sistema hanno limiti stringenti per la 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 tipo supportato. 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).
  • Sovrazioni. Poiché le proprietà di sistema di sola lettura sono implementate come proprietà di sola scrittura, 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. Ciò comporta che i valori riscrivibili definiti dal fornitore vengano sostituiti da quelli definiti da AOSP.
  • Soddisfa i requisiti di spazio per gli indirizzi. Le proprietà di sistema occupano una quantità relativamente elevata di spazio di indirizzi in ogni processo. Le proprietà di sistema sono agrupate in unità prop_area con una dimensione fissa di 128 KB, tutte allocate a uno spazio indirizzi del processo anche se viene eseguito l'accesso a una sola proprietà di sistema. Ciò può causare problemi sui dispositivi a 32 bit dove lo spazio degli indirizzi è prezioso.

Abbiamo tentato di superare queste limitazioni senza sacrificare la compatibilità, ma la preoccupazione che le proprietà di sistema non fossero progettate per supportare l'accesso agli elementi di configurazione di sola lettura è rimasta. Alla fine abbiamo deciso che le proprietà di sistema sono più adatte alla condivisione di alcuni elementi aggiornati dinamicamente su Android in tempo reale e che era necessario 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 compilazione (attualmente utilizzati per compilare il framework in modo condizionale) in HIDL.
  • I fornitori e gli OEM forniscono valori SoC e specifici per il dispositivo per i flag di compilazione implementando il servizio HAL.
  • Modifica il framework in modo da 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. Il framework utilizza le interfacce quando deve ottenere un valore per un elemento di configurazione.

Considerazioni sulla sicurezza

I flag di compilazione definiti nella stessa interfaccia sono interessati dallo stesso criterio SELinux. Se uno o più flag di compilazione devono avere criteri SELinux diversi, devono essere separati in un'altra interfaccia. Ciò può richiedere una revisione sostanziale di android.hardware.configstore package, in quanto le interfacce separate non sono più compatibili con le versioni precedenti.