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 du code AOSP (Android Open Source Project) non modifié que tout appareil Android exécutant Android 9 ou version ultérieure peut exécuter 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 Vendor Test Suite (VTS) et la Compatibility Test Suite (CTS) pour garantir que l'appareil implémente correctement les interfaces du fournisseur avec la dernière version d'Android.

Pour démarrer avec les GSI, consultez les sections suivantes pour plus de détails sur les configurations GSI (et les écarts autorisés) 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 du GSI

Le GSI Android actuel a la configuration suivante :

Le GSI Android actuel comprend les principales variantes suivantes :

  • Architecture du processeur. Prise en charge de différentes instructions CPU (ARM, x86, etc.) et du nombre de bits du 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 Construire la cible
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 processeur possède un binaire GSI correspondant (voir la liste des cibles de construction dans Création de GSI ).

Modifications du GSI d'Android 12

Les appareils lancés 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 de la 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 du fournisseur.
  • L'ancien GSI est progressivement supprimé. GSI 12 supprime les solutions de contournement adaptées aux appareils Android 8.0 ou 8.1 qui ne sont pas entièrement treblisés.
  • Userdebug SEPolice. 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 du system.img GSI. Référencez les tests VTS avec Debug Ramdisk pour plus de détails.

Modifications du GSI d'Android 11

Les appareils lancés 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 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 des APEX aplatis et compressés. Le choix à utiliser est déterminé par la propriété système ro.apex.updatable dans la partition du fournisseur au moment de l'exécution. Référence Configuration du système pour prendre en charge les mises à jour APEX pour plus de détails.

Modifications d'Android 10 GSI

Les appareils lancés 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érencez les tests VTS avec Debug Ramdisk pour plus de détails.
  • Format non fragmenté. Les GSI avec les cibles aosp_$arch sont construits avec un format non fragmenté. Vous pouvez utiliser img2simg pour convertir un GSI non fragmenté au format clairsemé si nécessaire.
  • Système en tant que racine. L'ancienne cible de build GSI 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 virtuel et sans système en tant que racine, utilisez l'ancien GSI aosp_$arch_ab . L' init mise à niveau dans le disque virtuel prend en charge le fichier OEM system.img avec une 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 du GSI d'Android 9

Les appareils lancés 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 l'émulateur. Les GSI sont construits à partir des images système de produits d'émulation, 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 dans le répertoire /system . Sous Android 9, la racine de l’image système est montée en tant que racine de l’appareil.
  • Interface de classeur 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 du VNDK. Sous Android 8.1, VNDK était facultatif. À partir d'Android 9, VNDK est obligatoire, donc BOARD_VNDK_VERSION doit être défini.
  • Propriété du système compatible. Android 9 permet la vérification d'accès à une propriété système compatible ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Modifications du Keymaster d'Android 9

Dans les versions antérieures d'Android, les appareils implémentant Keymaster 3 ou 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 signalées par le GSI peuvent ne pas correspondre aux informations de version signalé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 de Keymaster pour ignorer la vérification (ou passer à Keymaster 4). Pour plus de détails sur Keymaster, reportez-vous à Keystore matériel .

Télécharger les 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 possède 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 des sources Android en téléchargeant à partir d'une branche GSI et en choisissant une cible de construction GSI . Utilisez les tableaux de cibles de build 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 build 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

Objectifs de build Android GSI

Les cibles de build GSI suivantes concernent les appareils lancés sur Android 9 ou version ultérieure.

Nom GSI Arc du processeur Nombre de bits de l'interface du classeur Système en tant que racine Construire la cible
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 le flashage des GSI

Les appareils Android peuvent avoir des conceptions différentes, il n'y a donc pas de commande générique ni d'ensemble d'instructions pour flasher un GSI à appliquer à tous les appareils. Vérifiez auprès du 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 :
    • Triplé
    • Une méthode pour déverrouiller les appareils (afin qu'ils puissent être flashés à l'aide fastboot )
    • Un état déverrouillé pour le rendre flashable via fastboot (Pour vous assurer que vous disposez de la dernière version de fastboot , construisez-le à partir de l'arborescence des sources 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 chargeur de démarrage .
  2. Les appareils 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émarrer :
    $ 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 apparaître 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 un 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, comme system_a dans cet exemple.

Contribuer aux GSI

Android accueille favorablement vos contributions au développement de GSI. Vous pouvez vous impliquer et contribuer à l’amélioration du GSI en :

  • Création d'un patch GSI. DESSERT -gsi n'est pas une branche de développement et n'accepte que les sélections de la branche principale AOSP, donc pour soumettre un patch GSI, vous devez :
    1. Soumettez le correctif à la branche main AOSP .
    2. Choisissez le patch sur DESSERT -gsi .
    3. Déposez un bug pour que le Cherrypick soit examiné.
  • Signaler des bugs GSI ou faire d'autres suggestions. Consultez les instructions dans Signalement des bogues , puis parcourez ou classez les bogues GSI .

Conseils

Changer le mode de la barre de navigation en utilisant 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 au moment 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.