Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Immagini di sistema generiche

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

I GSI vengono utilizzati per l'esecuzione di 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 GSI, consultare le seguenti sezioni per i dettagli sulle configurazioni GSI (e le variazioni consentite), i tipi (Android GSI e Legacy GSI), i binari del fornitore e le dipendenze VNDK . Quando sei pronto per utilizzare un GSI, scarica e crea il GSI per la destinazione del tuo dispositivo, quindi invia il GSI a un dispositivo Android.

Configurazione e varianze GSI

L'attuale GSI Android ha la seguente configurazione:

  • Treble. GSI include il supporto completo per le modifiche all'architettura basate su HIDL (noto anche come Treble ) introdotto in Android 8.0, incluso il supporto per le interfacce HIDL . È possibile utilizzare GSI su qualsiasi dispositivo Android che utilizza interfacce fornitore HIDL. (Per ulteriori dettagli, consultare Risorse di architettura .)
  • Verifica l'avvio. GSI non include una soluzione di avvio di verifica (come vboot 1.0 o AVB ). Per eseguire il flashing di GSI su un dispositivo che si avvia su Android 9 o versioni precedenti, il dispositivo deve disporre di un metodo per disabilitare l'avvio di verifica.
  • File system. GSI utilizza il file system ext4.
  • Layout della partizione. GSI utilizza il layout di partizione di sistema come root .

L'attuale GSI Android include le seguenti variazioni principali:

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

Obiettivi GSI per i test di conformità degli acuti

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

Tipo di dispositivo Costruisci bersaglio
Dispositivi che si avviano con Android 10 aosp_$arch-user
Dispositivi che si avviano con Android 9 aosp_$arch-userdebug
Dispositivi che si avviano con Android 8.0 o Android 8.1 aosp_$arch_ab-userdebug

Tutti i GSI sono creati dal codebase di Android 10 e ogni architettura CPU ha un binario GSI corrispondente (vedere l'elenco delle destinazioni di compilazione in Building GSIs ).

Modifiche GSI per Android 10

I dispositivi che si avviano con Android 10 devono utilizzare Android 10 GSI per i test di conformità. Ciò include le seguenti principali modifiche rispetto ai precedenti GSI:

  • Build dell'utente. GSI ha la build dell'utente da Android 10. In Android 10, la build dell'utente GSI può essere utilizzata nei test di conformità CTS-on-GSI / VTS. Test di riferimento VTS con debug Ramdisk per i dettagli.
  • Formato non risparmiato. GSI con target aosp_$arch sono costruiti con un formato non analizzato. È possibile utilizzare img2simg per convertire un GSI non analizzato in formato sparse, se necessario.
  • System-as-root. Il target di build GSI legacy chiamato 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-come-root, utilizzare GSI aosp_$arch_ab . L' init aggiornato in ramdisk supporta system.img OEM con layout system-as-root.

Per testare i dispositivi che si avviano su Android 9 o 10 con CTS-on-GSI, utilizzare i target di build GSI di Android .

Legacy GSI

GSI legacy denominati con il suffisso _ab (ad esempio, aosp_arm64_ab ). Questi GSI sono creati dall'albero dei sorgenti di Android 10 ma contengono le seguenti configurazioni compatibili con le versioni precedenti per i dispositivi aggiornati da Android 8 o 8.1:

  • Area utenti a 32 bit + interfaccia binder a 32 bit. I GSI a 32 bit possono continuare a utilizzare l'interfaccia del raccoglitore a 32 bit.
  • 8.1 VNDK. I dispositivi possono utilizzare 8.1 VNDK incluso.
  • Montare le directory. Alcuni dispositivi legacy utilizzano le directory come puntatori di montaggio (ad esempio, /bluetooth , /firmware/radio e /persist ).

Per testare i dispositivi che si avviano su Android 8 o 8.1 con CTS-on-GSI, utilizzare i target di build GSI legacy .

Modifiche GSI per Android 9

I GSI di Android 9 includono le seguenti principali modifiche rispetto ai GSI precedenti:

  • Unisce GSI ed emulatore. I GSI sono creati 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 /system 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, i GSI a 32 bit utilizzavano l'interfaccia del raccoglitore a 32 bit. Android 9 non supporta l'interfaccia del binder a 32 bit, quindi sia GSI a 32 bit che GSI a 64 bit utilizzano l'interfaccia del binder a 64 bit.
  • Applicazione VNDK. In Android 8.1, VNDK era facoltativo. A partire da Android 9, VNDK è obbligatorio, quindi BOARD_VNDK_VERSION necessario impostare BOARD_VNDK_VERSION .
  • Proprietà di sistema compatibile. Android 9 abilita il controllo di accesso per una proprietà di sistema compatibile ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Modifiche di Keymaster per Android 9

Nelle versioni precedenti di Android, i dispositivi che implementavano Keymaster 3 o precedenti erano tenuti a 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 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 un GSI. In particolare, Keymaster non dovrebbe eseguire la verifica poiché 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 di Keymaster per saltare la verifica (o eseguire l'aggiornamento a Keymaster 4). Per i dettagli su Keymaster, consultare Keystore supportato da hardware .

Binari del fornitore e dipendenze VNDK

I dispositivi che eseguono l'aggiornamento ad Android 10 hanno percorsi di aggiornamento diversi a seconda della versione dei binari del fornitore in uso sul dispositivo e delle configurazioni relative a VNDK utilizzate per costruire il dispositivo. La tabella seguente riepiloga il supporto GSI legacy per i dispositivi aggiornati.

Caso d'uso venditore
binari
versione
BOARD_VNDK_VERSION Legacy GSI
versione dei binari di sistema
Supporto GSI legacy
0 8.0 (qualunque) 10 No
1 8.1 (vuoto) 10 No
2 8.1 current 10
3 10 current 10

Il caso d'uso più comune supportato è il n. 2, in cui i GSI legacy supportano i dispositivi che eseguono Android 8.1 che sono stati creati con BOARD_VNDK_VERSION impostato su current .

Il caso n. 1 non è supportato. In questo caso, i GSI legacy NON supportano i dispositivi che eseguono Android 8.1 in cui BOARD_VNDK_VERSION è omesso dalla build. Questi dispositivi non possono essere supportati perché i binari dei loro fornitori dipendono dalle librerie condivise non 8.1 VNDK di Android 8.1, che non sono incluse nei GSI legacy. Per rendere questi dispositivi compatibili con un GSI legacy, è necessario effettuare una delle seguenti operazioni:

  • Abilita BOARD_VNDK_VERSION senza BOARD_VNDK_RUNTIME_DISABLE (caso d'uso n. 2).

    O

  • Porta / aggiorna i file binari del fornitore per dipendere dalle librerie condivise da Android 10 (caso d'uso n. 3).

Download di GSI

È possibile scaricare GSI preconfigurati dal sito Web AOSP di integrazione continua (CI) 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 destinazioni specifiche.

Costruire GSI

A partire da Android 9, ogni versione di Android ha un ramo GSI chiamato DESSERT -gsi su AOSP (ad esempio, android10-gsi è il ramo GSI su Android 10). Le filiali GSI includono il contenuto di Android con tutte le patch di sicurezza e le patch GSI applicate.

Per creare un GSI, configurare l'albero dei sorgenti Android scaricando da un ramo GSI e scegliendo un target di build GSI . Utilizzare le tabelle di destinazione di compilazione di seguito per determinare la versione GSI corretta per il dispositivo. Al termine della compilazione, GSI è l'immagine di sistema (ovvero system.img ) e viene visualizzata nella cartella di output out/target/product/ generic_arm64 . La build genera anche vbmeta.img , che è possibile utilizzare per disabilitare l'avvio di verifica sui dispositivi utilizzando Android Verified Boot .

Ad esempio, per aosp_arm64-userdebug target di build GSI aosp_arm64-userdebug sul ramo GSI android10-gsi , eseguire i comandi seguenti.

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Target di build GSI Android

I seguenti target di build GSI sono per i dispositivi che si avviano su Android 9 o versioni successive. A causa della riduzione delle variazioni tra le architetture, Android 10 include solo quattro prodotti GSI.

Nome GSI CPU arch Testimone interfaccia Binder System-as-radice Costruisci bersaglio
aosp_arm BRACCIO 64 Y aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 X 86 64 Y aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y aosp_x86_64-user
aosp_x86_64-userdebug

Target di build GSI legacy

I seguenti target di build GSI legacy sono per l'aggiornamento di dispositivi da Android 8.0 o 8.1 ad Android 10. I nomi GSI legacy includono il suffisso _ab per distinguerli dai nomi GSI di Android 10.

Nome GSI CPU arch Testimone interfaccia Binder System-as-radice Costruisci bersaglio
aosp_arm_ab BRACCIO 32 Y aosp_arm_ab-userdebug
aosp_arm_64b_ab BRACCIO 64 Y aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y aosp_arm64_ab-userdebug
aosp_x86_ab X 86 32 Y aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y aosp_x86_64_ab-userdebug

Requisiti per il flashing GSI

I dispositivi Android possono avere design diversi, quindi non esiste un comando generico o un insieme di istruzioni per il flashing di un GSI da applicare a tutti i dispositivi. Verificare con il produttore del dispositivo Android le istruzioni di lampeggiamento esplicito. Utilizzare i seguenti passaggi come linea guida generale:

  1. Assicurarsi che il dispositivo disponga di:
    • Treblized
    • Un metodo per sbloccare i dispositivi (in modo che possano essere eseguiti in flash utilizzando l' fastboot )
    • Un metodo per disabilitare l'avvio di verifica (ad esempio, vboot 1.0 o AVB )
    • Uno stato sbloccato per renderlo flashable tramite fastboot (Per assicurarti di avere l'ultima versione di fastboot , fastboot dall'albero dei sorgenti di Android.)
  2. Disabilita verifica avvio.
  3. Cancella la partizione di sistema corrente, quindi invia il GSI alla partizione di sistema.
  4. Cancella i dati utente e cancella i dati da altre partizioni necessarie (ad esempio, dati utente e partizioni di sistema).
  5. 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 . I dispositivi che supportano fastbootd devono anche avviarsi in fastbootd :
    $ fastboot reboot fastboot
  2. Disabilita verifica avvio (AVB) facendo lampeggiare vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  3. Cancella e invia il GSI alla 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. Reboot:
    $ fastboot reboot
Sui dispositivi Android 10 con partizioni di sistema più piccole, durante il flashing di GSI potrebbe apparire 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 il flashing di GSI:
$ fastboot delete-logical-partition product_a
Il postfisso _a deve corrispondere _a 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 essere coinvolto e contribuire a migliorare GSI:

  • Creazione di una patch GSI. DESSERT -gsi non è un ramo di sviluppo e accetta solo cherrypicks dal ramo master AOSP, quindi per inviare una patch GSI, è necessario:
    1. Invia la patch al ramo master AOSP .
    2. Cripta la patch su DESSERT -gsi .
    3. Invia un bug per ottenere la revisione del cherrypick.
  • Segnalare bug GSI o dare altri suggerimenti. Rivedere le istruzioni in Segnalazione dei bug , quindi sfogliare o archiviare i bug di GSI .

Suggerimenti

Modifica della modalità della barra di navigazione tramite adb

Quando si avvia con GSI, la modalità della barra di navigazione è configurata dall'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 la mode può essere a threebutton , a due twobutton , gestural e così via.