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:
- Alti. GSI include il supporto completo per le modifiche all'architettura basate su AIDL/HIDL (note anche come Treble), compreso il supporto per le interfacce AIDL e le interfacce HIDL. Puoi utilizzare il GSI su qualsiasi dispositivo Android che utilizzi le interfacce dei fornitori AIDL/HIDL. Per ulteriori dettagli, consulta Risorse sull'architettura.
- File system. GSI utilizza il file system ext4.
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 destinazioneaosp_$arch
viene conservato per gli sviluppatori di app per Android. Anche il piano di testCTS-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
contieneuserdebug_plat_sepolicy.cil
. Quando viene eseguito il flashingvendor_boot-debug.img
oboot-debug.img
specifico per l'OEM,/system/bin/init
caricheràuserdebug_plat_sepolicy.cil
dal GSIsystem.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 cartellasystem/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 utilizzareimg2simg
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 GSIaosp_$arch_ab
. L'upgradeinit
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
eaosp_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:
- 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 difastboot
, compilala dall'albero di origine di Android).
- Cancella la partizione di sistema attuale, quindi esegui il flashing del GSI sulla partizione di sistema.
- Cancella i dati utente e quelli da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema).
- riavvia il dispositivo.
Ad esempio, per eseguire il flashing di una GSI su qualsiasi dispositivo Pixel:
- Avvia in modalità
fastboot
e sblocca il bootloader. - I dispositivi che supportano
fastbootd
devono anche avviarsi infastbootd
seguendo questa procedura:$ fastboot reboot fastboot
- Resetta e esegui il flashing del GSI nella partizione di sistema:
$ fastboot erase system $ fastboot flash system system.img
- Resetta i dati utente ed elimina i dati da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema):
$ fastboot -w
- Riavvia il bootloader:
$ fastboot reboot-bootloader
- Disattiva la verifica dell'Avvio verificato durante il flashing del file vbmeta fornito:
$ fastboot --disable-verification flash vbmeta vbmeta.img
- Reboot:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failed
$ fastboot delete-logical-partition product_a
_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:- Invia la patch al ramo
AOSP
main
. - Scegli la patch da applicare a
DESSERT-gsi
. - Segnala un bug per richiedere la revisione del cherry-pick.
- Invia la patch al ramo
AOSP
- 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.