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, consigliamo di utilizzare android-latest-release anziché aosp-main. 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, ConfigStore HAL è stato ritirato.

ConfigStore HAL rimane in AOSP per supportare le partizioni vendor 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 a ConfigStore HAL.

Android 8.0 suddivide il sistema operativo Android monolitico in partizioni generiche (system.img) e specifiche dell'hardware (vendor.img e odm.img). Di conseguenza, 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 non sono state utilizzate le proprietà di sistema per questo scopo); altre pagine di questa sezione descrivono in dettaglio l' interfaccia HAL, l'implementazione del servizioe l' utilizzo lato client, 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 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 Android come macro C, l'aumento della lunghezza può causare problemi di compatibilità con le versioni precedenti.
Nessun supporto per i tipi. 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 un array di tre stringhe).
Sovrascritture. Poiché le proprietà di sistema di sola lettura sono implementate come proprietà di scrittura una sola volta, i fornitori/ODM che vogliono sostituire 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. Di conseguenza, i valori riscrivibili definiti dal fornitore vengono sostituiti dai valori definiti da AOSP.
Requisiti dello spazio degli indirizzi. Le proprietà di sistema occupano una quantità relativamente elevata di spazio degli 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 degli indirizzi di 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 questi limiti 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 in tutto Android e che era necessario un nuovo sistema dedicato all'accesso agli elementi di configurazione di sola lettura.

Progettazione di ConfigStore HAL

La progettazione di base è semplice:

Progettazione HAL Configstore

Figura 1. Progettazione di ConfigStore HAL

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 in modo che utilizzi 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 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 interessati dalla stessa policy 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 del android.hardware.configstore package, poiché le interfacce separate non sono più compatibili con le versioni precedenti.