Images système génériques

Une image système générique (GSI) est une image système dont les configurations sont ajustées pour les appareils Android. Il s'agit d'une implémentation Android pure avec du code de projet Android Open Source (AOSP) non modifié que n'importe quel appareil Android exécutant Android 9 ou version ultérieure peut exécuter.

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 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 à utiliser les GSI, consultez les sections suivantes pour en savoir plus sur les configurations GSI (et les écarts autorisés) et les types. Lorsque vous êtes prêt à utiliser une GSI, téléchargez-la et créez-la pour votre appareil cible, puis flashez-la sur un appareil Android.

Configuration et variances des GSI

La configuration de l'GSI Android actuelle est la suivante:

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

La GSI Android actuelle comprend les principales différences suivantes:

• Architecture de processeur. Compatibilité avec différentes instructions pour les processeurs (ARM, x86, etc.) et différentes quantités de bits (32 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 codebase Android 12, et chaque architecture de processeur possède un binaire GSI correspondant (consultez la liste des cibles de compilation dans Compiler des GSI).

Modifications apportées aux GSI Android 12

Les appareils lancés avec Android 12 ou mis à niveau 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édents:

• Nom de la cible Le nom cible GSI pour les tests de conformité est remplacé par gsi_$arch. Le GSI avec le nom de cible aosp_$arch est conservé pour les développeurs d'applications Android. Le plan de test CTS-on-GSI est également réduit pour tester l'interface du fournisseur.
• L'ancienne GSI est en cours d'abandon. 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 SEPolicy. Le gsi_$arch GSI contient userdebug_plat_sepolicy.cil. Lors du flashage de vendor_boot-debug.img ou boot-debug.img spécifiques à l'OEM, /system/bin/init charge userdebug_plat_sepolicy.cil à partir de system.img GSI. Pour en savoir plus, consultez Tests VTS avec le ramdisk de débogage.

Modifications apportées aux GSI Android 11

Les appareils lancés avec Android 11 ou mis à niveau vers cette version doivent utiliser des GSI Android 11 pour les tests de conformité. Cela inclut les modifications majeures suivantes 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 sous le dossier system/system_ext.
• APEXes Le GSI contient à la fois des APEX aplatis et compressés. La propriété système ro.apex.updatable dans la partition du fournisseur au moment de l'exécution détermine celle à utiliser. Pour en savoir plus, consultez la section Configurer le système pour prendre en charge les mises à jour APEX.

Modifications apportées aux GSI Android 10

Les appareils équipés d'Android 10 ou mis à jour vers celui-ci doivent utiliser les GSI Android 10 pour les tests de conformité. Cela inclut les modifications majeures suivantes par rapport aux GSI précédents:

• Build utilisateur GSI dispose d'un build utilisateur à partir 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 la section Tests VTS avec le ramdisk de débogage.
• Format non scindé Les GSI avec des cibles aosp_$arch sont créées dans un format non espacé. Si nécessaire, vous pouvez utiliser img2simg pour convertir une GSI non espacée en format creux.
• Système en tant que racine. L'ancienne cible de compilation GSI nommée aosp_$arch_a a été abandonné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. La init mise à niveau dans le ramdisk est compatible avec le fichier system.img OEM avec la mise en page système en tant que racine.
• Vérifiez le démarrage. Avec 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 à niveau 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édents:

• Fusionne les GSI et l'émulateur. Les GSI sont créées à partir des images système des produits de l'émulateur, par exemple aosp_arm64 et aosp_x86.
• System-as-root Dans les versions précédentes d'Android, les appareils qui n'étaient pas compatibles avec les mises à jour A/B pouvaient monter l'image système dans 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 de liaison 64 bits. Dans Android 8.x, les GSI 32 bits utilisaient l'interface de liaison 32 bits. Android 9 n'est pas compatible avec l'interface de liaison 32 bits. Par conséquent, les GSI 32 bits et 64 bits utilisent l'interface de liaison 64 bits.
• Application du VNDK. Dans Android 8.1, le VNDK était facultatif. À partir d'Android 9, VNDK est obligatoire. BOARD_VNDK_VERSION doit donc ê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 à Keymaster dans 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) indiquées par le système en cours d'exécution correspondaient aux informations de version indiqué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 changé pour permettre aux fournisseurs de démarrer une GSI. Plus précisément, Keymaster ne doit pas effectuer de validation, car les informations de version signalées par le GSI peuvent ne pas correspondre à celles signalées par le bootloader du fournisseur. Pour les appareils implémentant Keymaster 3 ou 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 basé sur le matériel.

Télécharger des GSI

Vous pouvez télécharger des GSI prédéfinies sur le site Web d'intégration continue (CI) d'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, consultez la section suivante pour en savoir plus sur la création de 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 générer 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 tables des cibles de compilation ci-dessous pour déterminer la version de GSI correcte pour votre appareil. Une fois la compilation terminée, la GSI est l'image système (system.img) et apparaît dans le dossier de sortie out/target/product/generic_arm64.

Par exemple, pour créer 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 GSI Android

Les cibles de compilation GSI suivantes sont destinées aux appareils lancés sur 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 à appliquer à tous les appareils. Pour obtenir des instructions explicites sur le flashage, renseignez-vous auprès du fabricant de l'appareil Android. Suivez les étapes ci-dessous comme guide général:

1. Assurez-vous que l'appareil dispose des éléments suivants :
   • Aiguisé
   • Une méthode de déverrouillage des appareils (afin qu'ils puissent être flashés avec fastboot)
   • État déverrouillé pour le rendre flashable via fastboot (pour vous assurer de disposer de la dernière version de fastboot, compilez-le à partir de l'arborescence source Android)
2. Effacez la partition système actuelle, puis flashez le GSI sur la partition du système.
3. Effacer les données utilisateur et 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 une 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 sous fastbootd en:

   $ 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 les données des autres partitions nécessaires (par exemple, les données utilisateur et les partitions système):

   $ fastboot -w

5. Redémarrez dans le bootloader:

   $ fastboot reboot-bootloader

6. Désactivez la validation du démarrage validé lors du flash du vbmeta fourni:

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

7. 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 accueille vos contributions au développement des GSI. Vous pouvez vous impliquer et contribuer à améliorer le GSI en:

• Création d'un correctif GSI. DESSERT-gsi n'est pas une branche de développement et n'accepte que les sélections de la branche principale d'AOSP. Pour envoyer un correctif GSI, vous devez :
  1. Envoyez le correctif à la branche AOSP main.
  2. Sélectionnez le correctif correspondant à DESSERT-gsi.
  3. Envoyez un bug pour que le choix sélectif soit examiné.
• Signaler des bugs GSI ou faire d'autres suggestions Consultez les instructions de la section Signaler des bugs, puis parcourez ou signalez des bugs GSI.

Conseils

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

Lors du démarrage avec GSI, le mode de 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.