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 :
- Tripler. Le GSI inclut une prise en charge complète des modifications architecturales basées sur AIDL/HIDL (également connues sous le nom de Treble ), y compris la prise en charge des interfaces AIDL et HIDL . Vous pouvez utiliser le GSI sur n'importe quel appareil Android utilisant les interfaces des fournisseurs AIDL/HIDL. (Pour plus de détails, voir Ressources d'architecture .)
- Système de fichiers. Le GSI utilise le système de fichiers ext4.
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 cibleaosp_$arch
est réservé aux développeurs d'applications Android. Le plan de testCTS-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
contientuserdebug_plat_sepolicy.cil
. Lors du flashage duvendor_boot-debug.img
ouboot-debug.img
spécifique à l'OEM,/system/bin/init
chargerauserdebug_plat_sepolicy.cil
à partir dusystem.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 dossiersystem/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 utiliserimg2simg
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 GSIaosp_$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
etaosp_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 :
- 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 defastboot
, construisez-le à partir de l'arborescence des sources Android.)
- Effacez la partition système actuelle, puis flashez le GSI sur la partition système.
- 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).
- Redémarrez l'appareil.
Par exemple, pour flasher un GSI sur n'importe quel appareil Pixel :
- Démarrez en mode
fastboot
et déverrouillez le chargeur de démarrage . - Les appareils prenant en charge
fastbootd
doivent également démarrer dansfastbootd
par :$ fastboot reboot fastboot
- Effacez et flashez le GSI sur la partition système :
$ fastboot erase system $ fastboot flash system system.img
- 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
- Redémarrer :
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failedUtilisez 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_aLe 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 :- Soumettez le correctif à la branche
main
AOSP . - Choisissez le patch sur
DESSERT -gsi
. - Déposez un bug pour que le Cherrypick soit examiné.
- Soumettez le correctif à la branche
- 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.