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 utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Panoramica configurazione

AOSP offre le seguenti opzioni per archiviare le informazioni di configurazione su un dispositivo:

Proprietà di sistema
Configurazione del dispositivo nella fase iniziale di avvio
Proprietà dell'Hardware Abstraction Layer (HAL)
File XML di configurazione del sistema
Overlay delle risorse (statici e di runtime)

Proprietà di sistema

Le proprietà di sistema sono coppie chiave/valore di stringhe archiviate nel dizionario globale build.prop. Le proprietà di sistema sono risorse a livello di sistema facili da utilizzare e con un basso overhead delle prestazioni. Quando utilizzi le proprietà di sistema, non devi utilizzare la comunicazione interprocesso (IPC) anche se una proprietà di sistema è condivisa tra più processi. Tuttavia, le proprietà di sistema sono simili alle variabili globali e possono essere dannose se utilizzate in modo improprio. L'uso improprio delle proprietà di sistema può causare problemi come vulnerabilità di sicurezza e inaccessibilità delle app per gli utenti. Prima di utilizzare le proprietà di sistema per archiviare le informazioni di configurazione, valuta le altre opzioni di configurazione.

Per ulteriori informazioni sulle proprietà di sistema, vedi Aggiungere proprietà di sistema

Configurazione del dispositivo nella fase iniziale di avvio

In Android 17 e versioni successive, il servizio init_dev_config fornisce supporto per la configurazione del dispositivo e l'inizializzazione delle proprietà di sistema. Questo meccanismo architetturale dinamico viene eseguito automaticamente nella fase iniziale di avvio.

Quando una singola immagine di sistema o fornitore deve supportare più varianti hardware, i valori di configurazione non possono sempre essere codificati in modo permanente al tempo di compilazione. Il servizio init_dev_config viene eseguito durante la fase early-init, subito prima di apexd-bootstrap, consentendo ai fornitori di ispezionare lo stato dell'hardware (ad esempio da argomenti del bootloader, partizioni montate in anticipo o tabelle di configurazione hardware) e inizializzare dinamicamente le proprietà di sistema prima che vengano inizializzati servizi e librerie dipendenti.

Integrazione e ciclo di vita dei servizi

Il servizio init_dev_config è definito per impostazione predefinita nel sistema init.rc ed eseguito in modo sincrono durante early-init, prima di apexd-bootstrap. Gli integratori non devono dichiarare un nuovo servizio init.

Il servizio esistente utilizza invece l'espansione della proprietà nel percorso eseguibile, separando la dichiarazione del servizio di sistema dal binario del fornitore. Gli integratori specificano il percorso del file binario del fornitore utilizzando la proprietà ro.vendor.init_dev_config.path e lo configurano con le etichette e le autorizzazioni SELinux richieste.

Requisiti di implementazione per le agenzie

Per eseguire l'integrazione con init_dev_config:

Configura il percorso binario del fornitore in fase di compilazione utilizzando PRODUCT_VENDOR_PROPERTIES. Il percorso binario fornito deve essere un percorso valido per un file binario installato nel sistema:
```
PRODUCT_VENDOR_PROPERTIES += \
    ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
```
Se questa proprietà non è impostata, init salta l'esecuzione del servizio e l'avvio continua normalmente.
Poiché il servizio viene eseguito prima di apexd-bootstrap, le librerie bionic fornite da APEX non sono ancora disponibili. In Android.bp, imposta bootstrap: true:
```
rust_binary {
    name: "init_dev_config",
    vendor: true,
    srcs: ["src/main.rs"],
    rustlibs: [
        "librustutils",
    ],
    bootstrap: true,
}
```

Scrivi la logica del servizio per rilevare la variante hardware e imposta le proprietà di sistema appropriate:

use rustutils::system_properties;

fn main() {
    let hw_sku = read_hardware_sku();

    // Dynamically initialize vendor-specific properties:
    let display_type = match hw_sku {
        1 => "oled",
        _ => "lcd",
    };
    system_properties::write("vendor.display.panel_type", display_type)
        .expect("Failed to set vendor display property");
}

Etichetta il binario del fornitore con init_dev_config_exec:

 /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0

Concedi l'autorizzazione del dominio init_dev_config per impostare i tipi di proprietà richiesti:
```
 set_prop(init_dev_config, vendor_my_sku_prop)
```

Per informazioni sull'utilizzo di init_dev_config per l'attivazione e la disattivazione di APEX, vedi Selezione di APEX del fornitore all'avvio.

Proprietà HAL

Quando l'origine attendibile di una configurazione proviene da un componente hardware di un dispositivo, l'HAL per l'hardware deve fornire le informazioni per quel componente. Definisci un nuovo metodo HAL nell'HAL esistente per accedere alla configurazione. Per ulteriori informazioni sullo sviluppo di un HAL, consulta AIDL per HAL.

File XML di configurazione del sistema

Se i dati di configurazione sono statici ma complessi (strutturati), valuta la possibilità di utilizzare XML o altri formati simili per i dati di configurazione. Assicurati che lo schema del file rimanga stabile. Per i file XML, puoi utilizzare xsd_config per mantenere stabile lo schema e sfruttare un parser XML generato automaticamente.

Sovrapposizione delle risorse

Puoi utilizzare le sovrapposizioni delle risorse per personalizzare un prodotto. Esistono due tipi di overlay delle risorse:

Overlay di risorse standard utilizzato per personalizzare un prodotto in fase di compilazione. Per informazioni sulle overlay delle risorse standard, consulta Personalizzare la build con le overlay delle risorse.
L'runtime resource overlay (RRO) viene utilizzato per modificare i valori delle risorse di un pacchetto di destinazione al runtime. Ad esempio, un'app installata sull'immagine di sistema potrebbe modificare il proprio comportamento in base al valore di una risorsa. Anziché codificare in modo permanente il valore della risorsa in tempo di compilazione, un RRO installato su una partizione diversa può modificare i valori delle risorse dell'app in tempo di esecuzione. Per ulteriori informazioni sulle RRO, consulta Modificare il valore delle risorse di un'app in fase di runtime.