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. Elle est considérée comme une implémentation Android pure. avec du code de projet Android Open Source (AOSP) non modifié que tout un appareil fonctionnant sous Android 9 ou une version ultérieure peut fonctionner correctement.

Les GSI sont utilisées pour exécuter des tests VTS et CTS sur GSI. L'image système d'une L'appareil Android est remplacé par une GSI, puis testé avec la la suite de test fournisseur (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 commencer à utiliser les GSI, consultez les sections suivantes pour en savoir plus sur Configurations GSI (et les autorisations les écarts) et les types. Lorsque vous êtes prêt à utiliser une GSI, Téléchargez et créez les GSI pour votre appareil. cible, puis flashez la GSI sur un appareil.

Configuration et variances des GSI

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

• Aigus. Les GSI sont entièrement compatibles avec Modifications d'architecture basées sur AIDL/HIDL (également appelés aigus), y compris pour les interfaces AIDL et Interfaces HIDL. Vous pouvez utiliser les GSI sur tout appareil Android utilisant des interfaces de fournisseurs AIDL/HIDL. Pour en savoir plus, consultez Ressources d'architecture.)
• Système de fichiers : Les GSI utilisent le système de fichiers ext4.

Les GSI Android actuelles incluent les variations majeures suivantes:

• Architecture de processeur. Compatibilité avec différentes instructions de processeur (ARM, x86, etc.) et le débit du processeur (32 ou 64 bits).

Cibles GSI pour les tests de conformité Treble

Les GSI utilisées pour les tests de conformité sont déterminées par la version d'Android de lancement de l’appareil.

Toutes les GSI sont créées à partir du codebase Android 12. chaque architecture de processeur possède un binaire GSI correspondant (voir la liste des dans la section Créer des GSI).

Modifications apportées aux GSI Android 12

Les appareils équipés d'Android 12 ou mis à jour vers celui-ci doivent utiliser Android 12 GSI pour les tests de conformité. Cela inclut les suite aux modifications majeures apportées par les GSI précédentes:

• Nom de la cible : Nom de la cible GSI à des fins de conformité tests est remplacé par gsi_$arch. GSI avec le nom de la cible aosp_$arch est conservé pour les développeurs d'applications Android. Plan de test CTS-on-GSI est également réduit pour tester l'interface du fournisseur.
• Les anciennes GSI sont supprimées. GSI 12 supprime les solutions de contournement pour les appareils Android 8.0 ou 8.1 qui ne sont pas entièrement triées par ordre décroissant.
• Userdebug SEPolicy. Le GSI gsi_$arch contient userdebug_plat_sepolicy.cil. Pendant le clignotement l'attribut vendor_boot-debug.img propre à l'OEM ou Chargement de boot-debug.img, /system/bin/init userdebug_plat_sepolicy.cil à partir du GSI system.img Références VTS Testing avec Déboguez Ramdisk pour obtenir plus d'informations.

Modifications apportées aux GSI Android 11

Les appareils équipés d'Android 11 ou mis à jour vers celui-ci doivent utiliser Android 11 GSI pour les tests de conformité. Cela inclut les suite aux modifications majeures apportées par les GSI précédentes:

• system_ext content. Android. 11 définit une nouvelle partition system_ext. GSI place le contenu de l'extension système sous le dossier system/system_ext
• AXES. Les GSI contiennent à la fois des APEX aplatis et compressés. Celle à utiliser est déterminée par la propriété système ro.apex.updatable dans la partition des fournisseurs au moment de l'exécution. Références <ph type="x-smartling-placeholder"></ph> Configuration du système pour qu'elle accepte les mises à jour APEX pour en savoir plus.

Modifications apportées aux GSI Android 10

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

• Build de l'utilisateur. GSI utilise un build d'utilisateur Android 10. Sous Android 10, les GSI de build utilisateur peuvent être utilisées dans les tests de conformité CTS-on-GSI/VTS. Références Tests VSS avec Debug Ramdisk pour en savoir plus.
• Format non espacé. GSI avec cibles Les aosp_$arch sont compilées avec un format non espacé. Vous pouvez utiliser img2simg pour convertir une GSI non espacée en format creux si nécessaires.
• Système en tant que racine. L'ancienne cible de compilation GSI nommée aosp_$arch_a a été supprimé. Pour les appareils mis à niveau d'Android 8 ou 8.1 à Android 10 avec ramdisk et sans système en tant que racine, utilisez l'ancienne version de GSI aosp_$arch_ab. Le init mis à niveau dans ramdisk est compatible avec le système OEM.img avec une mise en page système en tant que racine.
• Vérifier le démarrage Avec 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 apportées aux GSI Android 9

Les appareils équipés d'Android 9 ou mis à jour vers celui-ci doivent utiliser Android 9 GSI pour les tests de conformité. Cela inclut les suite aux modifications majeures apportées par les GSI précédentes:

• Fusionne les GSI et l'émulateur. Les GSI sont créées à partir du système des images de produits d'émulateur, par exemple, aosp_arm64 et aosp_x86
• Système en tant que racine. Dans les versions précédentes d'Android, les appareils qui n'étaient pas compatibles avec les mises à jour A/B pourraient installer l'image système sous Répertoire /system. Sous Android 9, la racine de l'image système est installée en tant que racine de l'appareil.
• Interface de liaison 64 bits. Sous Android 8.x, les GSI 32 bits utilisé l'interface de liaison 32 bits. Android 9 n'est pas compatible avec l'interface de liaison 32 bits, donc les GSI 32 bits et Les GSI 64 bits utilisent l’interface de liaison 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 être défini.
• Propriété système compatible. Android 9 permet de vérifier l'accès (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Modifications de Keymaster

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

Sous Android 9 ou version ultérieure, cette exigence a changé pour permettre pour démarrer une GSI. Plus précisément, Keymaster ne doit pas effectuer de validation car il est possible que les informations de version indiquées par le GSI ne correspondent pas à celles indiquées indiquées par le bootloader du fournisseur. Pour les appareils qui implémentent Keymaster 3 ou inférieur, les fournisseurs doivent modifier l'implémentation de Keymaster pour ignorer la vérification (ou passer à Keymaster 4). Pour en savoir plus sur Keymaster, consultez Keystore intégré au matériel.

Télécharger des GSI

Vous pouvez télécharger des GSI prédéfinies à partir de l'intégration continue (CI) AOSP site Web à l'adresse ci.android.com. Si le type de GSI de votre matériel plate-forme n'est pas disponible en téléchargement, reportez-vous à la section suivante pour 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'un 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é Correctifs GSI appliqués.

Pour créer une GSI, configurez l'arborescence source Android en procédant comme suit : téléchargement à partir d'une branche GSI et Choisir une version de GSI cible. Utilisez les tables des cibles de compilation ci-dessous pour déterminer la bonne GSI pour votre appareil. Une fois la compilation terminée, GSI est le système (c'est-à-dire system.img) et s'affiche 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 des GSI Android

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

Exigences concernant le flash des GSI

Les appareils Android peuvent avoir des conceptions différentes, il n'y a donc pas de commande ou ensemble d'instructions pour flasher une GSI à appliquer à tous les appareils. Vérifier auprès de au fabricant de l'appareil Android pour obtenir des instructions explicites sur le clignotement. Suivez les étapes ci-dessous à titre indicatif:

1. Assurez-vous que l'appareil dispose des éléments suivants: <ph type="x-smartling-placeholder">
   </ph>
   • Treblés
   • Une méthode de déverrouillage des appareils (afin qu’ils puissent être flashés à l’aide de fastboot).
   • État déverrouillé pour le rendre flashable via fastboot (Pour vous assurer que vous disposez de la dernière version de fastboot, compilez dans l'arborescence source Android.)
2. Effacez la partition système actuelle, puis flashez le GSI sur le système. partition.
3. effacer les données utilisateur et effacer les données des autres partitions nécessaires (par (par exemple, les données utilisateur et les partitions système).
4. Redémarrez l'appareil.

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

1. Démarrer pour mode fastboot et déverrouillez bootloader.
2. Les appareils prenant en charge fastbootd doivent également démarrer dans fastbootd en:

   $ fastboot reboot fastboot

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

   $ fastboot erase system
   $ fastboot flash system system.img
   

4. effacer les données utilisateur et effacer les données des autres partitions nécessaires (par par exemple, les données utilisateur et les partitions système):

   $ fastboot -w

5. Redémarrage:

   $ 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 souhaite que vous apportiez votre contribution au développement de GSI. Vous pouvez participer et contribuer à améliorer les GSI en:

• Créer un correctif GSI DESSERT-gsi n'est pas une branche de développement et n'accepte que les sélections de ce type la branche principale d'AOSP. Par conséquent, pour envoyer un correctif GSI, vous devez: <ph type="x-smartling-placeholder">
  </ph>
  1. Envoyez le correctif AOSP Branche main.
  2. Sélectionnez le correctif correspondant à DESSERT-gsi.
  3. Signalez un bug pour faire examiner la sélection.
• Signaler des bugs GSI ou faire d'autres suggestions Examiner les instructions fournies dans signaler des bugs, puis parcourir ou fichier GSI de bugs.

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 changez le mode de la barre de navigation en exécutant la commande adb suivante dans l'environnement d'exécution.

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

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