HAL ConfigStore

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 questi valori utilizzando HIDL (questo è vero anche in Android 9). Tuttavia, a causa dell'elevato consumo di memoria e della difficoltà di utilizzo, l'HAL ConfigStore è stato ritirato.

Il ConfigStore HAL rimane in AOSP per supportare le partizioni dei fornitori 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 partizioni generiche (system.img) e specifiche per l'hardware (vendor.img e odm.img). A seguito di questa modifica, è necessario rimuovere la compilazione condizionale dai moduli installati nella partizione di sistema e tali moduli devono determinare la configurazione del sistema in fase di runtime (e comportarsi in modo diverso a seconda di tale 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 Aggiungere 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 stretti per la lunghezza dei loro 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. Questo 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 temere 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 erano più adatte per condividere in tempo reale alcuni elementi con aggiornamento dinamico su tutti i dispositivi Android 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 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 build definiti nella stessa interfaccia sono interessati dallo stesso criterio SELinux. Se uno o più flag di build 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.