Images système génériques

Une image système générique (GSI) est une image système avec des configurations ajustées pour les appareils Android. Il est considéré comme une implémentation Android pure avec un code Android Open Source Project (AOSP) non modifié que tout appareil Android exécutant Android 9 ou supérieur peut fonctionner avec succès.

Les GSI sont utilisés pour exécuter les tests VTS et CTS-on-GSI. L'image système d'un appareil Android est remplacée par un GSI, puis testée avec la suite de tests du fournisseur (VTS) et la suite de tests de compatibilité (CTS) pour s'assurer que l'appareil implémente correctement les interfaces du fournisseur avec la dernière version d'Android.

Pour commencer avec les GSI, consultez les sections suivantes pour plus de détails sur les configurations GSI (et les variations autorisées) et les types . Lorsque vous êtes prêt à utiliser un GSI, téléchargez et créez le GSI pour votre appareil cible, puis flashez le GSI sur un appareil Android.

Configuration et variantes GSI

Le GSI Android actuel a la configuration suivante :

Le GSI actuel d'Android comprend les principaux écarts suivants :

  • Architecture du processeur. Prise en charge de différentes instructions CPU (ARM, x86, etc.) et du bitness CPU (32 bits ou 64 bits).

Objectifs GSI pour les tests de conformité Treble

Le GSI utilisé pour les tests de conformité est déterminé par la version d'Android avec laquelle l'appareil est lancé.

Type d'appareil Cible de construction
Appareils lancés avec Android 12 gsi_$arch-user (Signé)
Appareils lancés avec Android 11 gsi_$arch-user (Signé)
Appareils lancés avec Android 10 gsi_$arch-user (Signé)
Appareils lancés avec Android 9 gsi_$arch-userdebug

Tous les GSI sont construits à partir de la base de code Android 12, et chaque architecture de CPU a un binaire GSI correspondant (voir la liste des cibles de construction dans Building GSIs ).

Modifications d'Android 12 GSI

Les appareils lancés avec ou mis à jour vers Android 12 doivent utiliser les GSI Android 12 pour les tests de conformité. Cela inclut les changements majeurs suivants par rapport aux GSI précédents :

  • Nom cible. Le nom de la cible GSI pour les tests de conformité est remplacé par gsi_$arch . Le GSI avec le nom cible aosp_$arch est réservé aux développeurs d'applications Android. Le plan de test CTS-on-GSI est également réduit pour tester l'interface fournisseur.
  • L'ancien GSI est supprimé. GSI 12 supprime les solutions de contournement adaptées aux appareils Android 8.0 ou 8.1 qui ne sont pas entièrement Treblized.
  • Userdebug SEPolicy. Le GSI gsi_$arch contient userdebug_plat_sepolicy.cil . Lors du flashage du vendor_boot-debug.img ou boot-debug.img spécifique à l'OEM , /system/bin/init chargera userdebug_plat_sepolicy.cil à partir de GSI system.img . Référence VTS Testing with Debug Ramdisk pour plus de détails.

Modifications d'Android 11 GSI

Les appareils lancés avec ou mis à jour vers Android 11 doivent utiliser les GSI Android 11 pour les tests de conformité. Cela inclut les changements majeurs suivants par rapport aux GSI précédents :

  • contenu de system_ext. Android 11 définit une nouvelle partition system_ext . GSI place le contenu de l'extension système dans le dossier system/system_ext .
  • APEX. GSI contient à la fois des APEX aplatis et compressés. Celui à utiliser est déterminé par la propriété système ro.apex.updatable dans la partition fournisseur au moment de l'exécution. Référence Configuration du système pour prendre en charge les mises à jour APEX pour le détail.

Modifications d'Android 10 GSI

Les appareils lancés avec ou mis à jour vers Android 10 doivent utiliser les GSI Android 10 pour les tests de conformité. Cela inclut les changements majeurs suivants par rapport aux GSI précédents :

  • Construction utilisateur. GSI a une version utilisateur à partir d'Android 10. Dans Android 10, la version utilisateur GSI peut être utilisée dans les tests de conformité CTS-on-GSI/VTS. Référence VTS Testing with Debug Ramdisk pour plus de détails.
  • Format non épargné. Les GSI avec des cibles aosp_$arch sont construits avec un format non épars. Vous pouvez utiliser img2simg pour convertir un GSI non épars au format épars si nécessaire.
  • Système en tant que racine. La cible de génération GSI héritée nommée aosp_$arch_a a été progressivement supprimée. Pour les appareils mis à niveau d'Android 8 ou 8.1 vers Android 10 avec disque RAM et non-système en tant que racine, utilisez l'ancien GSI aosp_$arch_ab . L' init mis à niveau dans le disque virtuel prend en charge le fichier OEM system.img avec la disposition système en tant que racine.
  • Vérifiez le démarrage. En utilisant GSI, il vous suffit de déverrouiller l'appareil. Il n'est pas nécessaire de désactiver la vérification du démarrage.

Modifications d'Android 9 GSI

Les appareils lancés avec ou mis à jour vers Android 9 doivent utiliser les GSI Android 9 pour les tests de conformité. Cela inclut les changements majeurs suivants par rapport aux GSI précédents :

  • Fusionne GSI et émulateur. Les GSI sont créés à partir des images système des émulateurs, par exemple, aosp_arm64 et aosp_x86 .
  • Système en tant que racine. Dans les versions précédentes d'Android, les appareils qui ne prenaient pas en charge les mises à jour A/B pouvaient monter l'image système sous le répertoire /system . Dans Android 9, la racine de l'image système est montée en tant que racine de l'appareil.
  • Interface de reliure 64 bits. Dans Android 8.x, les GSI 32 bits utilisaient l'interface de classeur 32 bits. Android 9 ne prend pas en charge l'interface de classeur 32 bits, donc les GSI 32 bits et les GSI 64 bits utilisent l'interface de classeur 64 bits.
  • Application VNDK. Dans Android 8.1, VNDK était facultatif. À partir d'Android 9, VNDK est obligatoire, donc BOARD_VNDK_VERSION doit être défini.
  • Propriété système compatible. Android 9 active la vérification d'accès pour une propriété système compatible ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Modifications apportées à Android 9 Keymaster

Dans les versions antérieures d'Android, les appareils implémentant Keymaster 3 ou une version antérieure devaient vérifier que les informations de version ( ro.build.version.release et ro.build.version.security_patch ) signalées par le système en cours d'exécution correspondaient aux informations de version signalées par le chargeur de démarrage. Ces informations étaient généralement obtenues à partir de l'en-tête de l'image de démarrage.

Dans Android 9 et versions ultérieures, cette exigence a changé pour permettre aux fournisseurs de démarrer un GSI. Plus précisément, Keymaster ne doit pas effectuer de vérification car les informations de version rapportées par le GSI peuvent ne pas correspondre aux informations de version rapportées par le chargeur de démarrage du fournisseur. Pour les appareils implémentant Keymaster 3 ou une version antérieure, les fournisseurs doivent modifier l'implémentation Keymaster pour ignorer la vérification (ou mettre à niveau vers Keymaster 4). Pour plus d'informations sur Keymaster, reportez-vous à la section Hardware-backed Keystore .

Téléchargement des GSI

Vous pouvez télécharger des GSI prédéfinis à partir du site Web d'intégration continue (CI) AOSP à l' adresse ci.android.com . Si le type de GSI pour votre plate-forme matérielle n'est pas disponible au téléchargement, reportez-vous à la section suivante pour plus de détails sur la création de GSI pour des cibles spécifiques.

Construire des GSI

À partir d'Android 9, chaque version d'Android a une branche GSI nommée DESSERT -gsi sur AOSP (par exemple, android12-gsi est la branche GSI sur Android 12). Les branches GSI incluent le contenu d'Android avec tous les correctifs de sécurité et les correctifs GSI appliqués.

Pour créer un GSI, configurez l'arborescence source Android en téléchargeant à partir d'une branche GSI et en choisissant une cible de génération GSI . Utilisez les tableaux cibles de construction ci-dessous pour déterminer la version GSI correcte pour votre appareil. Une fois la construction terminée, le GSI est l'image système (c'est-à-dire, system.img ) et apparaît dans le dossier de sortie out/target/product/ generic_arm64 .

Par exemple, pour créer la cible de génération GSI gsi_arm64-userdebug sur la branche GSI android12-gsi , exécutez les commandes suivantes.

$ 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

Cibles de build Android GSI

Les cibles de build GSI suivantes concernent les appareils lancés sur Android 9 ou supérieur.

Nom de l'IGS Arche du processeur Bit d'interface de liant Système en tant que racine Cible de construction
gsi_arm BRAS 64 Oui gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Oui gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Oui gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Oui gsi_x86_64-user
gsi_x86_64-userdebug

Exigences pour les GSI clignotants

Les appareils Android peuvent avoir des conceptions différentes, il n'y a donc pas de commande générique ou d'ensemble d'instructions pour flasher un GSI à appliquer à tous les appareils. Consultez le fabricant de l'appareil Android pour obtenir des instructions de clignotement explicites. Utilisez les étapes suivantes comme ligne directrice générale :

  1. Assurez-vous que l'appareil dispose des éléments suivants :
    • Treblisé
    • Une méthode pour déverrouiller les appareils (afin qu'ils puissent être flashés à l'aide de fastboot )
    • Un état déverrouillé pour le rendre flashable via fastboot (Pour vous assurer que vous disposez de la dernière version de fastboot , créez-la à partir de l'arborescence source Android.)
  2. Effacez la partition système actuelle, puis flashez le GSI sur la partition système.
  3. Effacez les données utilisateur et effacez les données des autres partitions nécessaires (par exemple, les données utilisateur et les partitions système).
  4. Redémarrez l'appareil.

Par exemple, pour flasher un GSI sur n'importe quel appareil Pixel :

  1. Démarrez en mode fastboot et déverrouillez le bootloader .
  2. Les périphériques prenant en charge fastbootd doivent également démarrer dans fastbootd par :
    $ fastboot reboot fastboot
  3. Effacez et flashez le GSI sur la partition système :
    $ fastboot erase system
$ fastboot flash system system.img
  4. Effacez les données utilisateur et effacez les données des autres partitions nécessaires (par exemple, les données utilisateur et les partitions système) :
    $ fastboot -w
  5. Redémarrez :
    $ fastboot reboot
Sur les appareils Android 10 ou plus récents dotés de partitions système plus petites, le message d'erreur suivant peut s'afficher lors du flashage du GSI :
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Utilisez la commande suivante pour supprimer la partition du produit et libérer de l'espace pour la partition système. Cela fournit de l'espace supplémentaire pour flasher le GSI :
$ fastboot delete-logical-partition product_a
Le suffixe _a doit correspondre à l'identifiant d'emplacement de la partition système, tel que system_a dans cet exemple.

Contribuer aux GSI

Android accueille vos contributions au développement de GSI. Vous pouvez vous impliquer et aider à améliorer le GSI en :

  • Création d'un patch GSI. DESSERT -gsi n'est pas une branche de développement et n'accepte que les cherrypicks de la branche master AOSP, donc pour soumettre un patch GSI, vous devez :
    1. Soumettez le correctif à la branche master AOSP .
    2. Choisissez le patch pour DESSERT -gsi .
    3. Signalez un bogue pour faire réviser le cherrypick.
  • Signaler des bogues GSI ou faire d'autres suggestions. Passez en revue les instructions dans Signaler des bogues , puis parcourez ou enregistrez les bogues GSI .

Des astuces

Changer le mode de la barre de navigation avec adb

Lors du démarrage avec GSI, le mode de la barre de navigation est configuré par remplacement du fournisseur. Vous pouvez modifier le mode de la barre de navigation en exécutant la commande adb suivante lors de l'exécution.

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

Où mode peut être threebutton , twobutton , gestural , etc.