Immagini di sistema generiche

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

I GSI vengono utilizzati per eseguire test VTS e CTS-on-GSI. L'immagine di sistema di un dispositivo Android viene sostituita con un GSI quindi testato con Vendor Test Suite (VTS) e Compatibility Test Suite (CTS) per garantire che il dispositivo implementi correttamente le interfacce del fornitore con la versione più recente di Android.

Per iniziare a utilizzare i GSI, consultare le seguenti sezioni per i dettagli sulle configurazioni GSI (e sulle variazioni consentite) e sui tipi . Quando sei pronto per utilizzare un GSI, scarica e crea il GSI per il tuo dispositivo di destinazione, quindi esegui il flashing del GSI su un dispositivo Android.

Configurazione e varianze del GSI

L'attuale Android GSI ha la seguente configurazione:

L'attuale Android GSI include le seguenti principali variazioni:

  • Architettura della CPU. Supporto per diverse istruzioni CPU (ARM, x86, ecc.) e bitness CPU (32 bit o 64 bit).

Obiettivi GSI per i test di conformità Treble

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

Tipo di dispositivo Costruisci obiettivo
Dispositivi che si avviano con Android 12 gsi_$arch-user (Firmato)
Dispositivi che si avviano con Android 11 gsi_$arch-user (Firmato)
Dispositivi che si avviano con Android 10 gsi_$arch-user (Firmato)
Dispositivi che si avviano con Android 9 gsi_$arch-userdebug

Tutti i GSI sono creati dalla codebase di Android 12 e ogni architettura della CPU ha un file binario GSI corrispondente (vedi l'elenco degli obiettivi di compilazione in Creazione di GSI ).

Modifiche al GSI di Android 12

I dispositivi avviati o aggiornati ad Android 12 devono utilizzare i GSI di Android 12 per i test di conformità. Ciò include le seguenti importanti modifiche rispetto ai GSI precedenti:

  • Nome dell'obiettivo. Il nome di destinazione GSI per i test di conformità viene modificato in gsi_$arch . Il GSI con nome di destinazione aosp_$arch viene mantenuto per gli sviluppatori di app Android. Anche il piano di test CTS-on-GSI è stato ridotto per testare l'interfaccia del fornitore.
  • Il GSI legacy viene gradualmente eliminato. GSI 12 rimuove le soluzioni alternative che supportano i dispositivi Android 8.0 o 8.1 che non sono completamente triplicati.
  • SEPolicy debug utente. Il GSI gsi_$arch contiene userdebug_plat_sepolicy.cil . Quando si esegue il flashing di vendor_boot-debug.img o boot-debug.img specifico dell'OEM, /system/bin/init caricherà userdebug_plat_sepolicy.cil dal GSI system.img . Fare riferimento a Test VTS con Debug Ramdisk per i dettagli.

Modifiche al GSI di Android 11

I dispositivi avviati o aggiornati ad Android 11 devono utilizzare i GSI di Android 11 per i test di conformità. Ciò include le seguenti importanti modifiche rispetto ai GSI precedenti:

  • contenuto system_ext. Android 11 definisce una nuova partizione system_ext . GSI inserisce il contenuto dell'estensione di sistema nella cartella system/system_ext .
  • APEX. GSI contiene APEX sia appiattiti che compressi. Quale utilizzare è determinato dalla proprietà di sistema ro.apex.updatable nella partizione del fornitore in fase di esecuzione. Fare riferimento alla configurazione del sistema per supportare gli aggiornamenti APEX per i dettagli.

Modifiche al GSI di Android 10

I dispositivi avviati o aggiornati ad Android 10 devono utilizzare i GSI di Android 10 per i test di conformità. Ciò include le seguenti importanti modifiche rispetto ai GSI precedenti:

  • Creazione dell'utente. GSI ha una build utente da Android 10. In Android 10, la build GSI utente può essere utilizzata nei test di conformità CTS-on-GSI/VTS. Fare riferimento al test VTS con Debug Ramdisk per i dettagli.
  • Formato non sparsiato. I GSI con target aosp_$arch sono costruiti con un formato non sparso. Se necessario, puoi utilizzare img2simg per convertire un GSI non sparso in un formato sparso.
  • Sistema come root. Il target di build GSI legacy denominato aosp_$arch_a è stato gradualmente eliminato. Per i dispositivi aggiornati da Android 8 o 8.1 ad Android 10 con ramdisk e non system-as-root, utilizzare il GSI legacy aosp_$arch_ab . L' init aggiornato in ramdisk supporta system.img OEM con layout system-as-root.
  • Verifica l'avvio. Utilizzando GSI è sufficiente sbloccare il dispositivo. Non è necessario disabilitare la verifica dell'avvio.

Modifiche al GSI di Android 9

I dispositivi avviati o aggiornati ad Android 9 devono utilizzare i GSI di Android 9 per i test di conformità. Ciò include le seguenti importanti modifiche rispetto ai GSI precedenti:

  • Unisce GSI ed emulatore. I GSI sono creati dalle immagini di sistema dei prodotti emulatori, ad esempio aosp_arm64 e aosp_x86 .
  • Sistema come 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 viene montata come radice del dispositivo.
  • Interfaccia raccoglitore a 64 bit. In Android 8.x, i GSI a 32 bit utilizzavano l'interfaccia del raccoglitore a 32 bit. Android 9 non supporta l'interfaccia del raccoglitore a 32 bit, quindi sia i GSI a 32 bit che i GSI a 64 bit utilizzano l'interfaccia del raccoglitore a 64 bit.
  • Applicazione VNDK. In Android 8.1, VNDK era facoltativo. A partire da Android 9, VNDK è obbligatorio, quindi è necessario impostare BOARD_VNDK_VERSION .
  • Proprietà del sistema compatibile. Android 9 abilita il controllo dell'accesso per una proprietà di sistema compatibile ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Android 9 Keymaster cambia

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 alle informazioni sulla versione riportate dal bootloader. Tali informazioni venivano generalmente 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 dal GSI potrebbero non corrispondere alle informazioni sulla versione riportate dal bootloader del fornitore. Per i dispositivi che implementano Keymaster 3 o versioni precedenti, i fornitori devono modificare l'implementazione di Keymaster per ignorare la verifica (o eseguire l'aggiornamento a Keymaster 4). Per dettagli su Keymaster, fare riferimento a Keystore supportato da hardware .

Scarica GSI

È possibile scaricare GSI predefiniti 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, fai riferimento alla sezione seguente per i dettagli sulla creazione di GSI per target specifici.

Costruisci 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 creare un GSI, configura l'albero dei sorgenti Android scaricandolo da un ramo GSI e scegliendo una destinazione di compilazione GSI . Utilizza le tabelle di destinazione della build riportate di seguito per determinare la versione GSI corretta per il tuo dispositivo. Una volta completata la compilazione, GSI è l'immagine del sistema (ovvero system.img ) e viene visualizzata nella cartella di output out/target/product/ generic_arm64 .

Ad esempio, per creare il target di build 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

Obiettivi di build Android GSI

I seguenti target di build GSI riguardano i dispositivi che si avviano su Android 9 o versioni successive.

Nome GSI Arco della CPU Bitness dell'interfaccia del raccoglitore Sistema come root Costruisci obiettivo
gsi_arm BRACCIO 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Requisiti per i GSI lampeggianti

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

  1. Assicurarsi che il dispositivo disponga di quanto segue:
    • Triplicato
    • Un metodo per sbloccare i dispositivi (in modo che possano essere flashati utilizzando fastboot )
    • Uno stato sbloccato per renderlo flashable tramite fastboot (per assicurarti di avere la versione più recente di fastboot , creala dall'albero dei sorgenti Android.)
  2. Cancellare la partizione di sistema corrente, quindi eseguire il flashing del GSI sulla partizione di sistema.
  3. Cancella i dati utente e cancella i dati da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema).
  4. Riavviare il dispositivo.

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

  1. Avvia in modalità fastboot e sblocca il bootloader .
  2. Anche i dispositivi che supportano fastbootd devono avviarsi in fastbootd tramite:
    $ fastboot reboot fastboot
  3. Cancella e installa il GSI nella partizione di sistema:
    $ fastboot erase system
$ fastboot flash system system.img
  4. Cancella i dati utente e cancella i dati da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema):
    $ fastboot -w
  5. Riavvio:
    $ fastboot reboot
Sui dispositivi Android 10 o più recenti dotati di partizioni di sistema più piccole, potrebbe essere visualizzato il seguente messaggio di errore durante il flashing di GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Utilizzare il seguente comando per eliminare la partizione del prodotto e liberare spazio per la partizione di sistema. Ciò fornisce spazio aggiuntivo per eseguire il flashing del GSI:
$ fastboot delete-logical-partition product_a
Il suffisso _a deve corrispondere all'ID dello slot della partizione di sistema, come system_a in questo esempio.

Contribuisci ai GSI

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

  • Creazione di una patch GSI. DESSERT -gsi non è un ramo di sviluppo e accetta solo cherrypicks dal ramo principale AOSP, quindi per inviare una patch GSI è necessario:
    1. Invia la patch al ramo main AOSP .
    2. Scegli la patch per DESSERT -gsi .
    3. Segnala un bug per far revisionare il cherrypick.
  • Segnalare bug GSI o dare altri suggerimenti. Rivedi le istruzioni in Segnalazione di bug , quindi sfoglia o archivia i bug GSI .

Suggerimenti

Cambia la modalità della barra di navigazione usando adb

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

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

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