Images système génériques

Une image système générique (GSI) est une image système dont les configurations ont été ajustées pour les appareils Android. Elle est considérée comme une implémentation Android pur avec un code de projet Android Open Source (AOSP) non modifié, qui peut s'exécuter correctement sur n'importe quel appareil Android équipé d'Android 9 ou version ultérieure.

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

Pour commencer à utiliser les ISG, consultez les sections suivantes pour en savoir plus sur les configurations (et les écarts autorisés) et les types d'ISG. Lorsque vous êtes prêt à utiliser une GSI, téléchargez et compilez la GSI pour la cible de votre appareil, puis flashez la GSI sur un appareil Android.

Configuration et écarts de l'identité de connexion Google

La configuration actuelle de la GSI Android est la suivante :

• Aigus : La GSI est entièrement compatible avec les modifications architecturales basées sur AIDL/HIDL (également appelées Treble), y compris avec les interfaces AIDL et les interfaces HIDL. Vous pouvez utiliser le GSI sur n'importe quel appareil Android qui utilise des interfaces fournisseur AIDL/HIDL. (Pour en savoir plus, consultez les ressources sur l'architecture.)
• Système de fichiers : La GSI utilise le système de fichiers ext4.

La GSI Android actuelle présente les principales différences suivantes :

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

Cibles GSI pour les tests de conformité Treble

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

Toutes les GSI sont créées à partir du code source Android 12. Chaque architecture de processeur possède un binaire GSI correspondant (consultez la liste des cibles de compilation dans Créer des GSI).

Modifications apportées aux GSI Android 12

Les appareils lancés avec Android 12 ou mis à jour vers cette version doivent utiliser des GSI Android 12 pour les tests de conformité. Cela inclut les modifications majeures suivantes par rapport aux GSI précédentes :

• Nom de la cible. Le nom de la cible GSI pour les tests de conformité est remplacé par gsi_$arch. La GSI avec le nom cible aosp_$arch est conservée pour les développeurs d'applications Android. Le plan de test CTS-on-GSI est également réduit pour l'interface du fournisseur de tests.
• L'ancienne GSI est abandonnée. GSI 12 supprime les solutions de contournement pour les appareils Android 8.0 ou 8.1 qui ne sont pas entièrement Treblized.
• Userdebug SEPolicy. La GSI gsi_$arch contient userdebug_plat_sepolicy.cil. Lors du flashage de vendor_boot-debug.img ou boot-debug.img spécifiques à l'OEM, /system/bin/init chargera userdebug_plat_sepolicy.cil à partir de l'image système générique system.img. Pour en savoir plus, consultez Tests VTS avec Debug Ramdisk.

Modifications apportées aux GSI Android 11

Les appareils lancés avec Android 11 ou mis à jour vers cette version doivent utiliser les GSI Android 11 pour les tests de conformité. Cela inclut les modifications majeures suivantes par rapport aux GSI précédentes :

• 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.
• APEXes. GSI contient des APEX aplatis et compressés. Le choix de l'un ou l'autre est déterminé par la propriété système ro.apex.updatable dans la partition du fournisseur au moment de l'exécution. Pour en savoir plus, consultez Configurer le système pour prendre en charge les mises à jour APEX.

Modifications apportées aux GSI Android 10

Les appareils lancés avec Android 10 ou mis à jour vers cette version doivent utiliser des GSI Android 10 pour les tests de conformité. Cela inclut les modifications majeures suivantes par rapport aux GSI précédentes :

• Build utilisateur : La GSI est une version utilisateur d'Android 10. Dans Android 10, la GSI de compilation utilisateur peut être utilisée dans les tests de conformité CTS-on-GSI/VTS. Pour en savoir plus, consultez Tests VTS avec Debug Ramdisk.
• Format non éparse : Les GSI avec cibles aosp_$arch sont créées au format non éparse. Vous pouvez utiliser img2simg pour convertir un index de recherche et d'identité globale non éparse au format éparse si nécessaire.
• System-as-root L'ancienne cible de compilation GSI nommée aosp_$arch_a a été supprimée. Pour les appareils mis à niveau d'Android 8 ou 8.1 vers Android 10 avec ramdisk et non-system-as-root, utilisez l'ancienne GSI aosp_$arch_ab. Le init mis à niveau dans le ramdisk est compatible avec le système OEM system.img avec une mise en page system-as-root.
• Vérifiez le démarrage. Avec la GSI, il vous suffit de déverrouiller l'appareil. Il n'est pas nécessaire de désactiver le démarrage validé.

Modifications apportées aux GSI Android 9

Les appareils lancés avec Android 9 ou mis à jour vers cette version doivent utiliser des GSI Android 9 pour les tests de conformité. Cela inclut les modifications majeures suivantes par rapport aux GSI précédentes :

• Fusionne la GSI et l'émulateur. Les GSI sont créées à partir des images système des produits d'émulateur, par exemple aosp_arm64 et aosp_x86.
• System-as-root 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 installée en tant que racine de l'appareil.
• Interface Binder 64 bits. Dans Android 8.x, les GSI 32 bits utilisaient l'interface Binder 32 bits. Android 9 ne prend pas en charge l'interface Binder 32 bits. Par conséquent, les GSI 32 bits et 64 bits utilisent l'interface Binder 64 bits.
• Application du VNDK : Dans Android 8.1, le VNDK était facultatif. À partir d'Android 9, le VNDK est obligatoire. BOARD_VNDK_VERSION doit donc être défini.
• Propriété du système compatible. Android 9 permet de vérifier l'accès à une propriété système compatible (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Modifications apportées à Keymaster dans Android 9

Dans les versions antérieures d'Android, les appareils implémentant Keymaster 3 ou une version antérieure devaient vérifier que les informations sur la version (ro.build.version.release et ro.build.version.security_patch) signalées par le système en cours d'exécution correspondaient à celles signalées par le bootloader. 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 été modifiée pour permettre aux fournisseurs de démarrer une GSI. Plus précisément, Keymaster ne doit pas effectuer de validation, car les informations sur la version signalées par la GSI peuvent ne pas correspondre à celles signalées par le bootloader 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 validation (ou passer à Keymaster 4). Pour en savoir plus sur Keymaster, consultez Keystore avec protection matérielle.

Télécharger des GSI

Vous pouvez télécharger des GSI prédéfinies depuis le site Web d'intégration continue (CI) AOSP sur ci.android.com. Si le type de GSI pour votre plate-forme matérielle n'est pas disponible au téléchargement, consultez la section suivante pour savoir comment créer des GSI pour des cibles spécifiques.

Créer des GSI

À partir d'Android 9, chaque version d'Android dispose d'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 une GSI, configurez l'arborescence source Android en téléchargeant à partir d'une branche GSI et en choisissant une cible de compilation GSI. Utilisez les tableaux des cibles de compilation ci-dessous pour déterminer la version GSI appropriée pour votre appareil. Une fois la compilation terminée, la 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 compiler la cible de compilation 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 compilation Android GSI

Les cibles de compilation GSI suivantes sont destinées aux appareils lancés sous Android 9 ou version ultérieure.

Conditions requises pour flasher les GSI

Les appareils Android peuvent avoir des conceptions différentes. Il n'existe donc pas de commande ni d'ensemble d'instructions génériques pour flasher une GSI et l'appliquer à tous les appareils. Pour obtenir des instructions explicites sur le flashage, renseignez-vous auprès du fabricant de l'appareil Android. Voici une procédure générale à suivre :

1. Assurez-vous que l'appareil dispose des éléments suivants :
   • Treblized
   • Méthode de déverrouillage des appareils (pour qu'ils puissent être flashés à l'aide de fastboot)
   • Un état déverrouillé pour permettre le flashage via fastboot (pour vous assurer d'avoir la dernière version de fastboot, compilez-la à partir de l'arborescence source Android).
2. Effacez la partition système actuelle, puis flashez la GSI sur la partition système.
3. Effacez les données utilisateur et les données des autres partitions nécessaires (par exemple, les partitions des données utilisateur et du système).
4. Redémarrez l'appareil.

Par exemple, pour flasher un GSI sur un appareil Pixel :

1. Démarrez en mode fastboot et déverrouillez le bootloader.
2. Les appareils compatibles avec fastbootd doivent également démarrer sur fastbootd en procédant comme suit :

   $ fastboot reboot fastboot

3. Effacez et flashez la GSI sur la partition système :

   $ fastboot erase system
   $ fastboot flash system system.img

4. Si votre appareil est compatible avec Android Virtual Framework, flashez le micrologiciel de la machine virtuelle protégée :

   $ fastboot flash pvmfw pvmfw.img
   

5. Effacez les données utilisateur et supprimez les données des autres partitions nécessaires (par exemple, les partitions des données utilisateur et du système) :

   $ fastboot -w

6. Redémarrez en mode bootloader :

   $ fastboot reboot-bootloader

7. Désactivez la validation du démarrage validé lors du flashage du fichier vbmeta fourni :

   $ fastboot --disable-verification flash vbmeta vbmeta.img

8. Reboot:

   $ fastboot reboot

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

$ fastboot delete-logical-partition product_a

Contribuer aux GSI

Android vous invite à contribuer au développement des GSI. Vous pouvez participer et contribuer à améliorer la GSI en :

• Créer un correctif GSI DESSERT-gsi n'est pas une branche de développement et n'accepte que les cherry-picks de la dernière branche de version AOSP (android16-release). Par conséquent, pour envoyer un correctif GSI, vous devez :
  1. Envoyez le correctif à la branche AOSP android16-release.
  2. Sélectionnez le correctif à appliquer à DESSERT-gsi.
  3. Créez un rapport de bug pour que le cherry-pick soit examiné.
• Signaler des bugs liés à GSI ou faire d'autres suggestions Consultez les instructions de la section Signaler des bugs, puis parcourez ou signalez les bugs liés à GSI.

Conseils

Modifier le mode de la barre de navigation à l'aide d'adb

Lors du démarrage avec GSI, le mode de la barre de navigation est configuré par le 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.