Immagini di sistema generiche

Un'immagine di sistema generica (GSI) è un'immagine di sistema con configurazioni regolate per i dispositivi Android. È considerata un'implementazione di Android puro con codice Android Open Source Project (AOSP) non modificato che qualsiasi dispositivo Android con Android 9 o versioni successive può eseguire correttamente.

I GSI vengono utilizzati per eseguire i test VTS e CTS su GSI. L'immagine di sistema di un dispositivo Android viene sostituita con una GSI, poi testata con la Vendor Test Suite (VTS) e la Compatibility Test Suite (CTS) per verificare che il dispositivo implementi correttamente le interfacce del fornitore con la versione più recente di Android.

Per iniziare a utilizzare gli GSI, consulta le sezioni seguenti per informazioni dettagliate su configurazioni (e variazioni consentite) e tipi degli GSI. Quando è tutto pronto per utilizzare un GSI, scarica e compila il GSI per il tuo dispositivo di destinazione, quindi esegui il flashing del GSI su un dispositivo Android.

Configurazione e varianti GSI

L'attuale GSI di Android ha la seguente configurazione:

L'attuale GSI di Android include le seguenti principali varianti:

  • Architettura della CPU. Supporto di diverse istruzioni della CPU (ARM, x86 e così via) e della loro ampiezza in bit (32 o 64 bit).

Target GSI per i test di conformità di Treble

Il GSI utilizzato per i test di conformità è determinato dalla versione di Android con cui viene lanciato il dispositivo.

Tipo di dispositivo Target di compilazione
Dispositivi lanciati con Android 15 gsi_$arch-user (firmato)
Dispositivi lanciati con Android 14 gsi_$arch-user (firmato)
Dispositivi lanciati con Android 13 gsi_$arch-user (firmato)
Dispositivi lanciati con Android 12L gsi_$arch-user (firmato)
Dispositivi lanciati con Android 12 gsi_$arch-user (firmato)
Dispositivi lanciati con Android 11 gsi_$arch-user (firmato)

Tutti i GSI vengono compilati dalla base di codice di Android 12 e ogni architettura CPU ha un file binario GSI corrispondente (vedi l'elenco dei target di compilazione in Compilare i GSI).

Modifiche a GSI di Android 12

I dispositivi lanciati con Android 12 o aggiornati ad Android 12 devono utilizzare GSI di Android 12 per i test di conformità. Sono incluse le seguenti modifiche principali rispetto ai GSI precedenti:

  • Nome target. Il nome target GSI per i test di conformità è stato modificato in gsi_$arch. Il GSI con nome di destinazione aosp_$arch viene conservato per gli sviluppatori di app per Android. Anche il piano di test CTS-on-GSI è stato ridotto per testare l'interfaccia del fornitore.
  • La versione precedente di GSI verrà ritirata. GSI 12 rimuove le soluzioni alternative compatibili con i dispositivi Android 8.0 o 8.1 che non sono completamente Treblized.
  • Userdebug SEPolicy. Il GSI gsi_$arch contiene userdebug_plat_sepolicy.cil. Quando viene eseguito il flashing vendor_boot-debug.img o boot-debug.img specifico per l'OEM, /system/bin/init caricherà userdebug_plat_sepolicy.cil dal GSI system.img. Per informazioni dettagliate, consulta VTS Testing with Debug Ramdisk.

Modifiche alla versione GSI di Android 11

I dispositivi lanciati con Android 11 o aggiornati ad Android 11 devono utilizzare immagini di sistema generiche Android 11 per i test di conformità. Sono incluse le seguenti modifiche principali rispetto ai GSI precedenti:

  • Contenuti di system_ext. Android 11 definisce una nuova partizione system_ext. GSI inserisce i contenuti dell'estensione di sistema nella cartella system/system_ext.
  • APEX. GSI contiene APEX bidimensionali e compressi. Quale utilizzare è determinato dalla proprietà di sistema ro.apex.updatable nella partizione del fornitore in fase di esecuzione. Per maggiori dettagli, consulta Configurare il sistema per supportare gli aggiornamenti APEX.

Modifiche a GSI di Android 10

I dispositivi lanciati con Android 10 o aggiornati ad Android 10 devono utilizzare GSI di Android 10 per i test di conformità. Sono incluse le seguenti modifiche principali rispetto ai GSI precedenti:

  • Compilazione utente. GSI ha la build utente da Android 10. In Android 10, la compilazione GSI dell'utente può essere utilizzata nei test di conformità CTS-on-GSI/VTS. Per maggiori dettagli, consulta VTS Testing with Debug Ramdisk.
  • Formato non sparso. I GSI con destinazioni aosp_$arch sono creati in un formato non sparso. Puoi utilizzare img2simg per convertire un GSI non sparso in formato sparso, se necessario.
  • System-as-root. Il target di compilazione GSI precedente denominato aosp_$arch_a è stato eliminato gradualmente. Per i dispositivi di cui è stato eseguito l'upgrade da Android 8 o 8.1 ad Android 10 con ramdisk e non system-as-root, utilizza la versione precedente di GSI aosp_$arch_ab. L'upgrade init in ramdisk supporta lo standard OEM system.img con layout system-as-root.
  • Verifica l'avvio. Con GSI devi solo sbloccare il dispositivo. Non è necessario disattivare l'avvio verificato.

Modifiche a GSI di Android 9

I dispositivi lanciati con Android 9 o aggiornati ad Android 9 devono utilizzare GSI di Android 9 per i test di conformità. Sono incluse le seguenti modifiche principali rispetto ai GSI precedenti:

  • Unisce GSI e l'emulatore. I GSI vengono creati dalle immagini di sistema dei prodotti di emulazione, ad esempio aosp_arm64 e aosp_x86.
  • System-as-root. Nelle versioni precedenti di Android, i dispositivi che non supportavano gli aggiornamenti A/B potevano montare l'immagine di sistema nella directory /system. In Android 9, la directory principale dell'immagine di sistema viene montata come directory principale del dispositivo.
  • Interfaccia binder a 64 bit. In Android 8.x, le GSI a 32 bit utilizzavano l'interfaccia binder a 32 bit. Android 9 non supporta l'interfaccia binder a 32 bit, pertanto sia le versioni GSI a 32 bit che GSI a 64 bit la utilizzano.
  • Applicazione di VNDK. In Android 8.1, VNDK era facoltativo. A partire da Android 9, VNDK è obbligatorio, quindi BOARD_VNDK_VERSION deve essere impostato.
  • Proprietà di sistema compatibile. Android 9 attiva il controllo dell'accesso per una proprietà di sistema compatibile (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Modifiche a Keymaster in Android 9

Nelle versioni precedenti di Android, i dispositivi che implementavano Keymaster 3 o versioni precedenti dovevano verificare che le informazioni sulla versione (ro.build.version.release e ro.build.version.security_patch) riportate dal sistema in esecuzione corrispondessero a quelle riportate dal bootloader. In genere queste informazioni venivano ottenute dall'intestazione dell'immagine di avvio.

In Android 9 e versioni successive, questo requisito è cambiato per consentire ai fornitori di avviare un GSI. Nello specifico, Keymaster non dovrebbe eseguire la verifica perché le informazioni sulla versione riportate da GSI potrebbero non corrispondere a quelle riportate dal bootloader del fornitore. Per i dispositivi che implementano Keymaster 3 o versioni precedenti, i fornitori devono modificare l'implementazione di Keymaster per saltare la verifica (o eseguire l'upgrade a Keymaster 4). Per maggiori dettagli su Keymaster, consulta Keystore basato su hardware.

Scarica GSI

Puoi scaricare GSI precompilati dal sito web di integrazione continua (CI) AOSP all'indirizzo ci.android.com. Se il tipo di GSI per la tua piattaforma hardware non è disponibile per il download, consulta la sezione seguente per informazioni dettagliate sulla creazione di GSI per target specifici.

Crea GSI

A partire da Android 9, ogni versione di Android ha un ramo GSI denominato DESSERT-gsi su AOSP (ad esempio, android12-gsi è il ramo GSI su Android 12). I rami GSI includono il contenuto di Android con tutte le patch di sicurezza e le patch GSI applicate.

Per compilare un GSI, configura la struttura del codice sorgente di Android scaricandola da un ramo GSI e scegliendo un target di compilazione GSI. Utilizza le tabelle di destinazione di compilazione riportate di seguito per determinare la versione GSI corretta per il tuo dispositivo. Al termine della compilazione, l'immagine del sistema (ovvero system.img) è l'immagine del sistema (ovvero system.img) e viene visualizzata nella cartella di output out/target/product/generic_arm64.

Ad esempio, per compilare il target di compilazione GSI gsi_arm64-userdebug sul ramo GSI android12-gsi, esegui i seguenti comandi.

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

Destinazioni di build GSI di Android

I seguenti target di compilazione GSI sono destinati ai dispositivi lanciati su Android 9 o versioni successive.

Nome GSI Architettura della CPU Velocità in bit dell'interfaccia Binder Sistema come root Target di compilazione
gsi_arm ABILITA 32 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 32 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Requisiti per il flashing di GSI

I dispositivi Android possono avere design diversi, pertanto non esiste un comando generico o un insieme di istruzioni per il flashing di un GSI da applicare a tutti i dispositivi. Rivolgiti al produttore del dispositivo Android per istruzioni esplicite sul flashing. Utilizza i seguenti passaggi come linee guida generali:

  1. Assicurati che il dispositivo abbia quanto segue:
    • Treblizzato
    • Un metodo per sbloccare i dispositivi (in modo che possano essere lampeggiati utilizzando fastboot)
    • Uno stato sbloccato per renderlo flashabile tramite fastboot (per assicurarti di avere la versione più recente di fastboot, compilala dall'albero di origine di Android).
  2. Cancella la partizione di sistema attuale, quindi esegui il flashing del GSI sulla partizione di sistema.
  3. Cancella i dati utente e quelli da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema).
  4. riavvia il dispositivo.

Ad esempio, per eseguire il flashing di una GSI su qualsiasi dispositivo Pixel:

  1. Avvia in modalità fastboot e sblocca il bootloader.
  2. I dispositivi che supportano fastbootd devono anche avviarsi in fastbootd seguendo questa procedura:
    $ fastboot reboot fastboot
  3. Resetta e esegui il flashing del GSI nella partizione di sistema:
    $ fastboot erase system
    $ fastboot flash system system.img
  4. Resetta i dati utente ed elimina i dati da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema):
    $ fastboot -w
  5. Riavvia il bootloader:
    $ fastboot reboot-bootloader
  6. Disattiva la verifica dell'Avvio verificato durante il flashing del file vbmeta fornito:
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  7. Reboot:
    $ fastboot reboot
Sui dispositivi con Android 10 o versioni successive che hanno partizioni di sistema più piccole, durante il flashing del GSI potrebbe essere visualizzato il seguente messaggio di errore:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Utilizza il comando seguente per eliminare la partizione del prodotto e liberare spazio per la partizione di sistema. In questo modo si ottiene spazio aggiuntivo per eseguire il flashing di GSI:
$ fastboot delete-logical-partition product_a
Il postfisso _a deve corrispondere all'ID slot della partizione di sistema, come system_a in questo esempio.

Contribuire ai GSI

Android accoglie con favore i tuoi contributi allo sviluppo di GSI. Puoi partecipare e contribuire a migliorare la GSI:

  • Creazione di una patch GSI. DESSERT-gsi non è un ramo di sviluppo e accetta solo cherrypick dal ramo principale AOSP, quindi per inviare una patch GSI devi:
    1. Invia la patch al ramo AOSP main.
    2. Scegli la patch da applicare a DESSERT-gsi.
    3. Segnala un bug per richiedere la revisione del cherry-pick.
  • Segnalare bug di GSI o fornire altri suggerimenti. Esamina le istruzioni riportate in Segnalare bug, quindi cerca o invia bug GSI.

Suggerimenti

Modificare la modalità della barra di navigazione utilizzando adb

Quando si avvia con GSI, la modalità della barra di navigazione viene configurata tramite l'override del fornitore. Puoi modificare la modalità della barra di navigazione eseguendo il seguente comando adb in fase di runtime.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Dove mode può essere threebutton, twobutton, gestural e così via.