Immagini di sistema generiche

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

Le GSI vengono utilizzate per eseguire i test VTS e CTS-on-GSI. L'immagine di sistema di un dispositivo Android viene sostituita con una GSI, quindi testata con la Vendor Test Suite (VTS) e la Compatibility Test Suite (CTS) per garantire che il dispositivo implementi correttamente le interfacce del fornitore con l'ultima versione di Android.

Per iniziare a utilizzare gli intent integrati, consulta le sezioni seguenti per informazioni dettagliate su configurazioni (e variazioni consentite) e tipi di intent integrati. Quando è tutto pronto per utilizzare una GSI, scarica e crea la GSI per la destinazione del tuo dispositivo, quindi flasha la GSI su un dispositivo Android.

Configurazione e varianze di GSI

L'attuale GSI Android ha la seguente configurazione:

• Alti. L'immagine di sistema generica include il supporto completo per i cambiamenti architetturali basati su AIDL/HIDL (noti anche come Treble), incluso il supporto per le interfacce AIDL e interfacce HIDL. Puoi utilizzare la GSI su qualsiasi dispositivo Android che utilizza interfacce fornitore AIDL/HIDL. Per ulteriori dettagli, consulta Risorse di architettura.
• File system. La GSI utilizza il file system ext4.

L'attuale GSI Android include le seguenti principali varianti:

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

Target GSI per i test di conformità Treble

La GSI utilizzata per i test di conformità è determinata dalla versione di Android con cui viene avviato il dispositivo.

Tutte le GSI sono create a partire dal codebase di Android 12 e ogni architettura CPU ha un binario GSI corrispondente (vedi l'elenco dei target di build in Creazione di GSI).

Modifiche alla GSI di Android 12

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

• Nome target. Il nome della destinazione GSI per i test di conformità è stato modificato in gsi_$arch. L'intent integrato con nome target aosp_$arch è mantenuto per gli sviluppatori di app per Android. Anche il piano di test CTS-on-GSI viene ridotto per l'interfaccia del fornitore di test.
• La vecchia GSI è stata ritirata. GSI 12 rimuove le soluzioni alternative che ospitano dispositivi Android 8.0 o 8.1 che non sono completamente Treblized.
• Userdebug SEPolicy. L'immagine GSI gsi_$arch contiene userdebug_plat_sepolicy.cil. Quando esegui il flashing di vendor_boot-debug.img o boot-debug.img specifico per l'OEM, /system/bin/init caricherà userdebug_plat_sepolicy.cil dalla GSI system.img. Riferimento VTS Testing with Debug Ramdisk per i dettagli.

Modifiche alla GSI di Android 11

I dispositivi lanciati con Android 11 o aggiornati a questa versione devono utilizzare le GSI di Android 11 per i test di conformità. Sono incluse le seguenti modifiche principali rispetto alle 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 compressi e non compressi. Quale utilizzare è determinato dalla proprietà di sistema ro.apex.updatable nella partizione del fornitore in fase di esecuzione. Riferimento Configurazione del sistema per supportare gli aggiornamenti APEX per i dettagli.

Modifiche alla GSI di Android 10

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

• Build utente. La GSI ha una build utente di Android 10. In Android 10, la GSI di build utente può essere utilizzata nei test di conformità CTS-on-GSI/VTS. Per maggiori dettagli, consulta Test VTS con Debug Ramdisk.
• Formato non analizzato. GSI con target aosp_$arch sono creati con il formato non compresso. Puoi utilizzare img2simg per convertire un indice secondario globale non sparso in formato sparso, se necessario.
• System-as-root. La build di GSI legacy denominata aosp_$arch_a è stata ritirata. 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 GSI legacy aosp_$arch_ab. init aggiornato in ramdisk supporta system.img OEM con layout system-as-root.
• Verifica l'avvio. Se utilizzi GSI, devi solo sbloccare il dispositivo. Non è necessario disattivare l'avvio verificato.

Modifiche alla GSI di Android 9

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

• Unisce GSI ed emulatore. Le GSI vengono create a partire dalle immagini di sistema dei prodotti dell'emulatore, 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 radice dell'immagine di sistema è montata come radice del dispositivo.
• Interfaccia del raccoglitore 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, quindi sia le GSI a 32 bit sia le GSI a 64 bit utilizzano l'interfaccia binder a 64 bit.
• Applicazione del VNDK. In Android 8.1, VNDK era facoltativo. A partire da Android 9, VNDK è obbligatorio, quindi BOARD_VNDK_VERSION deve essere impostato.
• Proprietà dell'impianto compatibile. Android 9 consente il controllo dell'accesso per una proprietà di sistema compatibile (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Modifiche a Keymaster

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

In Android 9 e versioni successive, questo requisito è stato modificato per consentire ai fornitori di avviare una GSI. In particolare, Keymaster non deve eseguire la verifica perché le informazioni sulla versione riportate dall'immagine di sistema generica 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 con supporto hardware.

Scaricare le GSI

Puoi scaricare le GSI predefinite 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 i contenuti di Android con tutte le patch di sicurezza e le patch GSI applicate.

Per creare una GSI, configura l'albero delle origini Android scaricandolo da un ramo GSI e scegliendo una destinazione di build GSI. Utilizza le tabelle dei target di build riportate di seguito per determinare la versione corretta di GSI per il tuo dispositivo. Al termine della build, la GSI è l'immagine di sistema (ovvero system.img) e viene visualizzata nella cartella di output out/target/product/generic_arm64.

Ad esempio, per creare la destinazione di build GSI gsi_arm64-userdebug sul ramo GSI android12-gsi, esegui questi 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

Target di build GSI Android

I seguenti target di build GSI sono per i dispositivi lanciati su Android 9 o versioni successive.

Requisiti per il flashing delle GSI

I dispositivi Android possono avere design diversi, quindi non esiste un comando generico o un insieme di istruzioni per il flashing di una GSI da applicare a tutti i dispositivi. Per istruzioni esplicite sul flashing, rivolgiti al produttore del dispositivo Android. Segui questi passaggi come linea guida generale:

1. Assicurati che il dispositivo disponga di quanto segue:
   • Treblized
   • Un metodo per sbloccare i dispositivi (in modo che possano essere flashati utilizzando fastboot)
   • Uno stato sbloccato per renderlo flashabile tramite fastboot (per assicurarti di avere l'ultima versione di fastboot, creala dall'albero delle origini di Android).
2. Cancella la partizione di sistema attuale, quindi installa la GSI nella partizione di sistema.
3. Cancella i dati utente e i dati delle altre partizioni necessarie (ad esempio le partizioni di dati utente e di sistema).
4. riavvia il dispositivo.

Ad esempio, per installare una GSI su qualsiasi dispositivo Pixel:

1. Avvia la modalità fastboot e sblocca il bootloader.
2. I dispositivi che supportano fastbootd devono anche avviarsi in fastbootd:

   $ fastboot reboot fastboot

3. Cancella e installa la GSI nella partizione di sistema:

   $ fastboot erase system
   $ fastboot flash system system.img

4. Se il tuo dispositivo supporta Android Virtual Framework, esegui il flash del firmware della macchina virtuale protetta:

   $ fastboot flash pvmfw pvmfw.img
   

5. Cancella i dati utente e cancella i dati dalle altre partizioni necessarie (ad esempio, partizioni di dati utente e di sistema):

   $ fastboot -w

6. Riavvia il bootloader:

   $ fastboot reboot-bootloader

7. Disattiva la verifica dell'avvio verificato durante il flashing di vbmeta fornito:

   $ fastboot --disable-verification flash vbmeta vbmeta.img

8. Reboot:

   $ fastboot reboot

    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed

$ fastboot delete-logical-partition product_a

Contribuire ai GSI

Android accoglie i tuoi contributi allo sviluppo di GSI. Puoi partecipare e contribuire a migliorare l'GSI:

• Creazione di una patch GSI. DESSERT-gsi non è un ramo di sviluppo e accetta solo cherry-pick dal ramo dell'ultima release AOSP (android16-release), quindi per inviare una patch GSI devi:
  1. Invia la patch al ramo AOSP android16-release.
  2. Seleziona la patch per DESSERT-gsi.
  3. Segnala un bug per far esaminare la selezione.
• Segnalare bug di GSI o fornire altri suggerimenti. Leggi le istruzioni riportate in Segnalazione di bug, quindi sfoglia o invia bug di GSI.

Suggerimenti

Modificare la modalità della barra di navigazione utilizzando adb

Quando si avvia il sistema operativo 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.