Immagini di sistema generiche

Un'immagine di sistema generica (GSI) è un'immagine di sistema con configurazioni regolate per i dispositivi Android. Viene considerata un'implementazione Android pura con codice AOSP (Android Open Source Project) non modificato che qualsiasi utente dispositivo con Android 9 o versioni successive.

I GSI vengono utilizzati per eseguire test VTS e CTS su GSI. L'immagine di sistema Il dispositivo Android viene sostituito con un GSI e viene 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, consulta le sezioni seguenti per dettagli su Configurazioni GSI (e consentite variabili) e tipi. Quando vuoi usare un GSI, scaricare e creare la GSI per il dispositivo target, quindi eseguire il flashing del GSI su un dispositivo.

Configurazione e varianze GSI

L'attuale GSI di Android ha la seguente configurazione:

• Alti. Il GSI include il supporto completo per Modifiche all'architettura basate su AIDL/HIDL (noto anche come Alti), che include il supporto per interfacce AIDL e Interfacce HIDL. Puoi utilizzare il GSI su qualsiasi dispositivo Android che utilizzi le interfacce dei fornitori AIDL/HIDL. Per ulteriori dettagli, vedi Risorse di architettura.)
• File system. Il GSI utilizza il file system ext4.

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

• Architettura della CPU. Supporto per istruzioni CPU diverse (ARM, x86, ecc.) e bitness della CPU (32 bit 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 che con cui si avvia il dispositivo.

Tutti i GSI sono basati sul codebase Android 12 e ciascuna architettura CPU ha un file binario GSI corrispondente (vedi l'elenco delle in Creazione di GSI).

Modifiche a GSI in Android 12

I dispositivi che vengono lanciati o aggiornati ad Android 12 devono usare Android 12 GSI per i test di conformità. È incluso il le seguenti modifiche principali rispetto ai GSI precedenti:

• Nome destinazione. Il nome della destinazione GSI per la conformità test è stato modificato in gsi_$arch. Il GSI con nome destinazione aosp_$arch viene conservato per gli sviluppatori di app per Android. Il piano di test CTS-on-GSI è ridotto anche per i test dell'interfaccia del fornitore.
• GSI legacy viene gradualmente eliminato. GSI 12 rimuove le soluzioni alternative compatibili con i dispositivi Android 8.0 o 8.1 che non hanno una classificazione completa.
• Userdebug SEPolicy. gsi_$arch di GSI contiene userdebug_plat_sepolicy.cil. Quando lampeggia i componenti specifici dell'OEM vendor_boot-debug.img o boot-debug.img, verrà caricato /system/bin/init userdebug_plat_sepolicy.cil dal GSI system.img. Riferimento Test VTS con Esegui il debug di Ramdisk per i dettagli.

Modifiche alla versione GSI di Android 11

I dispositivi che vengono lanciati o aggiornati ad Android 11 devono usare Android 11 GSI per i test di conformità. È incluso il le seguenti modifiche principali rispetto ai GSI precedenti:

• contenuti 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 usare è determinato dalla proprietà di sistema ro.apex.updatable nella partizione del fornitore in fase di esecuzione. Riferimento È in corso la configurazione del sistema per supportare gli aggiornamenti APEX per i dettagli.

Modifiche a GSI in Android 10

I dispositivi che vengono lanciati o aggiornati ad Android 10 devono utilizzare Android 10 GSI per i test di conformità. È incluso il le seguenti modifiche principali rispetto ai GSI precedenti:

• Build dell'utente. GSI ha una build utente da Android 10: In Android 10, Il GSI della build dell'utente può essere utilizzato per i test di conformità CTS su GSI/VTS. Riferimento Test VTS con Ramdisk di debug per maggiori dettagli.
• Formato non sparso. GSI con destinazioni aosp_$arch vengono creati in un formato non sparso. Puoi utilizzare img2simg per convertire un GSI non sparso in formato sparso se necessaria.
• System-as-root. La destinazione della build GSI precedente denominata aosp_$arch_a è stato eliminato. 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 il sistema OEM.img con layout system as-root.
• Verifica l'avvio. Utilizzando GSI devi solo sbloccare il dispositivo. Non è necessario disattivare la verifica dell'avvio.

Modifiche a GSI di Android 9

I dispositivi che vengono lanciati o aggiornati ad Android 9 devono utilizzare Android 9 GSI per i test di conformità. È incluso il le seguenti modifiche principali rispetto ai GSI precedenti:

• Unisce GSI e l'emulatore. I GSI vengono creati dal sistema immagini di prodotti emulatori, 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 sotto la Directory /system. In Android 9, la directory principale dell'immagine di sistema viene montata come la directory principale del dispositivo.
• Interfaccia binder a 64 bit. In Android 8.x, GSI a 32 bit ha utilizzato l'interfaccia binder a 32 bit. Android 9 non supporta l'interfaccia binder a 32 bit, quindi sia GSI a 32 bit che Le versioni GSI a 64 bit utilizzano l'interfaccia del binder a 64 bit.
• Applicazione di VNDK. In Android 8.1, VNDK era facoltativo. A partire da Android 9, il campo VNDK è obbligatorio, quindi È necessario impostare BOARD_VNDK_VERSION.
• Proprietà di sistema compatibile. Android 9 attiva il controllo dell'accesso per un proprietà di sistema (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Modifiche Keymaster

Nelle versioni precedenti di Android, i dispositivi che implementavano Keymaster 3 o versioni precedenti erano necessario per verificare che le informazioni sulla versione (ro.build.version.release e ro.build.version.security_patch) segnalato dal sistema in esecuzione corrisponde alle informazioni sulla versione segnalate dal bootloader. Queste informazioni erano in genere dall'intestazione dell'immagine di avvio.

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

Scarica GSI

Puoi scaricare i GSI predefiniti dall'integrazione continua (CI) di AOSP sito web all'indirizzo ci.android.com. Se il tipo GSI del tuo hardware non è disponibile per il download, consulta la sezione seguente per i dettagli sulla creazione di GSI per obiettivi specifici.

GSI della build

A partire da Android 9, ogni versione 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 Patch GSI applicate.

Per creare un GSI, configura la struttura di origine Android il download da un ramo GSI scelta di una build GSI target. Utilizza le tabelle di destinazione della build riportate di seguito per determinare il GSI corretto per il tuo dispositivo. Al termine della build, GSI è il sistema (system.img) e compare nella cartella di output out/target/product/generic_arm64.

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

I seguenti target di build GSI sono per i dispositivi che vengono lanciati su Android 9 o successiva.

Requisiti per il flashing di GSI

I dispositivi Android possono avere design diversi, quindi non c'è un comando generico o insieme di istruzioni per il flashing di una GSI da applicare a tutti i dispositivi. Verifica con il produttore del dispositivo Android per istruzioni di lampeggiamento esplicite. Come regola generale, segui questi passaggi:

1. Assicurati che sul dispositivo siano presenti quanto segue:
   • Altitudine
   • Un metodo per sbloccare i dispositivi (in modo che possano essere lampeggiati utilizzando fastboot
   • Uno stato sbloccato per renderlo accessibile tramite fastboot (per assicurarti di avere l'ultima versione di fastboot, crea dalla struttura di origine Android.
2. Cancella la partizione di sistema corrente, quindi esegui il flashing del GSI nel sistema della partizione di testo.
3. Cancella i dati utente da altre partizioni necessarie (ad ad esempio i dati utente e le partizioni di sistema).
4. riavvia il dispositivo.

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

1. Avvia a fastboot e sblocca bootloader,
2. I dispositivi che supportano fastbootd Inoltre, è necessario avviare fastbootd nei seguenti modi:

   $ fastboot reboot fastboot

3. Resetta e esegui il flashing del GSI nella partizione di sistema:

   $ fastboot erase system
   $ fastboot flash system system.img
   

4. Cancella i dati utente da altre partizioni necessarie (ad (ad esempio, i dati utente e le partizioni di sistema):

   $ fastboot -w

5. Riavvio:

   $ fastboot reboot

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

$ fastboot delete-logical-partition product_a

Contribuisci ai GSI

Android è lieta di dare il suo contributo allo sviluppo di GSI. Puoi partecipare e contribuire a migliorare GSI:

• Creazione di una patch GSI. DESSERT-gsi non è un ramo di sviluppo e accetta solo cherrypicks da al ramo principale di AOSP, quindi per inviare una patch GSI devi:
  1. Invia la patch al AOSP Ramo main.
  2. Scegli la patch per DESSERT-gsi.
  3. Segnala un bug per far esaminare la ciliegina sulla torta.
• Segnalazione di bug GSI o altri suggerimenti. Rivedi le istruzioni in Segnalare bug, quindi sfoglia o archivia GSI o malfunzionamenti.

Suggerimenti

Modificare la modalità della barra di navigazione utilizzando ADB

Durante l'avvio con GSI, la modalità della barra di navigazione viene configurata dall'override del fornitore. Puoi modifica la modalità della barra di navigazione eseguendo questo 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.