A partire dal 2026, per allinearci al nostro modello di sviluppo trunk stabile e garantire la stabilità della piattaforma per l'ecosistema, pubblicheremo il codice sorgente su AOSP nel secondo e nel quarto trimestre. Per compilare e contribuire ad AOSP, utilizza android-latest-release. Il branch del manifest android-latest-release farà sempre riferimento alla release più recente pubblicata su AOSP. Per saperne di più, consulta la sezione Modifiche ad AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 esegue il fallback 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). 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).

ConfigStore HAL 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, 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 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. Ciò, a sua volta, comporta la sostituzione dei valori riscrivibili definiti dal fornitore con i 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 con una dimensione fissa di 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 dove 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à 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 alla 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 compilazione (utilizzati per compilare in modo condizionale il 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 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 compilazione definiti nella stessa interfaccia sono interessati dalla stessa norma SELinux. Se uno o più flag di build devono avere policy SELinux diverse, devono essere separati in un'altra interfaccia. Ciò potrebbe richiedere una revisione importante di android.hardware.configstore package poiché le interfacce separate non sono più compatibili con le versioni precedenti.