Immagini di sistema generiche

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

I GSI vengono utilizzati per eseguire i 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 l'ultima versione di Android.

Per iniziare con i GSI, esamina le sezioni seguenti per i dettagli sulle configurazioni GSI (e sulle varianze consentite) e sui tipi . Quando sei pronto per utilizzare un GSI, scarica e crea il GSI per il tuo dispositivo target, quindi esegui il flashing del GSI su un dispositivo Android.

Configurazione e varianze 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 bit della 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 di Android con cui viene avviato il dispositivo.

Tipo di dispositivo Costruisci l'obiettivo
Dispositivi avviati con Android 12 gsi_$arch-user (firmato)
Dispositivi avviati con Android 11 gsi_$arch-user (firmato)
Dispositivi avviati con Android 10 gsi_$arch-user (firmato)
Dispositivi avviati con Android 9 gsi_$arch-userdebug

Tutti i GSI sono costruiti dalla base di codice di Android 12 e ogni architettura della CPU ha un binario GSI corrispondente (vedi l'elenco dei target di build in Building GSIs ).

Modifiche al GSI di Android 12

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

  • Nome di destinazione. Il nome della destinazione GSI per i test di conformità viene modificato in gsi_$arch . Il GSI con il nome di destinazione aosp_$arch viene mantenuto per gli sviluppatori di app Android. Anche il piano di test CTS-on-GSI è ridotto per il test dell'interfaccia del fornitore.
  • L'eredità GSI viene gradualmente eliminata. GSI 12 rimuove le soluzioni alternative per 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 si vendor_boot-debug.img o boot-debug.img , /system/bin/init caricherà userdebug_plat_sepolicy.cil da GSI system.img . Fare riferimento al test VTS con Debug Ramdisk per i dettagli.

Modifiche al GSI di Android 11

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

  • contenuto di sistema_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 appiattiti e 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 al GSI di Android 10

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

  • Creazione utente. GSI ha build utente da Android 10. In Android 10, la build utente GSI può essere utilizzata nei test di conformità CTS-on-GSI/VTS. Fare riferimento al test VTS con Debug Ramdisk per i dettagli.
  • Formato senza par. GSI con obiettivi aosp_$arch sono costruiti con un formato senza spargimento. Se necessario, puoi utilizzare img2simg per convertire un GSI non suddiviso in formato sparse.
  • Sistema come root. Il target di build GSI legacy denominato aosp_$arch_a era 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 OEM system.img con layout system-as-root.
  • Verifica avvio. Usando GSI devi solo sbloccare il dispositivo. Non è necessario disabilitare la verifica dell'avvio.

Modifiche al GSI di Android 9

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

  • Unisce GSI ed emulatore. I GSI sono costruiti dalle immagini di sistema dei prodotti di emulazione, 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 del 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 opzionale. A partire da Android 9, VNDK è obbligatorio, quindi è necessario impostare BOARD_VNDK_VERSION .
  • Proprietà di 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 sono state generalmente ottenute dall'intestazione dell'immagine di avvio.

In Android 9 e versioni successive, questo requisito è stato modificato per consentire ai fornitori di avviare un GSI. In particolare, Keymaster non dovrebbe eseguire la verifica perché le informazioni sulla versione riportate da 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 Keymaster per saltare la verifica (o eseguire l'aggiornamento a Keymaster 4). Per i dettagli su Keymaster, fare riferimento a Keystore supportato da hardware .

Download dei GSI

È possibile scaricare GSI predefiniti dal sito Web di integrazione continua (CI) AOSP all'indirizzo ci.android.com . Se il tipo GSI per la piattaforma hardware non è disponibile per il download, fare riferimento alla sezione seguente per i dettagli sulla creazione di GSI per target specifici.

Costruire 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). Le filiali GSI includono il contenuto di Android con tutte le patch di sicurezza e le patch GSI applicate.

Per creare un GSI, imposta l'albero dei sorgenti di Android scaricando da un ramo GSI e scegliendo una destinazione di build GSI . Utilizza le tabelle dei target di build seguenti per determinare la versione GSI corretta per il tuo dispositivo. Al termine della compilazione, il GSI è l'immagine di sistema (ovvero system.img ) e viene visualizzato nella cartella di output out/target/product/ generic_arm64 .

Ad esempio, per compilare il target di build GSI gsi_arm64-userdebug sul ramo GSI android12-gsi , eseguire 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 Android GSI

I seguenti target di build GSI sono per dispositivi con Android 9 o versioni successive.

nome GSI CPU arch Bitness dell'interfaccia del raccoglitore Sistema come root Costruisci l'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 un insieme 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 abbia quanto segue:
    • triplicato
    • Un metodo per sbloccare i dispositivi (in modo che possano essere flashati usando il fastboot )
    • Uno stato sbloccato per renderlo flashable tramite fastboot (per assicurarti di avere l'ultima versione di fastboot , compilalo dall'albero dei sorgenti di Android.)
  2. Cancella la partizione di sistema corrente, quindi esegui 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. Riavvia 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. I dispositivi che supportano fastbootd devono anche essere avviati in fastbootd tramite:
    $ fastboot reboot fastboot
  3. Cancella e aggiorna il GSI sulla 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 successivi con 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
Utilizzare il comando seguente 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.

Contributo 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 cherrypick dal ramo principale AOSP, quindi per inviare una patch GSI, devi:
    1. Invia la patch al ramo master AOSP .
    2. Scegli la patch per DESSERT -gsi .
    3. Segnala un bug per far rivedere il cherrypick.
  • Segnalazione di bug GSI o altri suggerimenti. Esamina le istruzioni in Segnalazione bug , quindi sfoglia o segnala i bug GSI .

Consigli

Modificare la modalità della barra di navigazione utilizzando adb

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

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

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