Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

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 8.1 ou supérieur peut fonctionner 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 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 avec les GSI, consultez les sections suivantes pour plus de détails sur les configurations GSI (et les écarts autorisés), les types (Android GSI et Legacy GSI), les binaires des fournisseurs et les dépendances VNDK . 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 écarts 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 HIDL (également appelées Treble ) introduites dans Android 8.0, y compris la prise en charge des interfaces HIDL . Vous pouvez utiliser le GSI sur n'importe quel appareil Android qui utilise les interfaces de fournisseur HIDL. (Pour plus de détails, voir les ressources d'architecture .)
  • Vérifiez le démarrage. Le GSI n'inclut pas de solution de démarrage de vérification (telle que vboot 1.0 ou AVB ). Pour flasher le GSI sur un appareil lancé sous Android 9 ou une version antérieure, l'appareil doit disposer d'une méthode permettant de désactiver la vérification du démarrage.
  • Système de fichiers. Le GSI utilise le système de fichiers ext4.
  • Disposition de la partition. Le GSI utilise une disposition de partition système en tant que racine .

Le GSI Android actuel comprend les écarts majeurs suivants:

  • Architecture du processeur. Prise en charge de différentes instructions CPU (ARM, x86, etc.) et bitness 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 Créer une cible
Appareils lancés avec Android 10 aosp_$arch-user
Appareils lancés avec Android 9 aosp_$arch-userdebug
Appareils lancés avec Android 8.0 ou Android 8.1 aosp_$arch_ab-userdebug

Tous les GSI sont construits à partir de la base de code Android 10, et chaque architecture de processeur a un binaire GSI correspondant (voir la liste des cibles de construction dans Création de GSI ).

Modifications Android 10 GSI

Les appareils lancés avec 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 de l'utilisateur. GSI a une version utilisateur 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érez-vous aux tests VTS avec Debug Ramdisk pour plus de détails.
  • Format non analysé. GSI avec des cibles aosp_$arch sont construits avec un format non analysé. Vous pouvez utiliser img2simg pour convertir un GSI non analysé en format fragmenté si nécessaire.
  • Système en tant que racine. L'ancienne cible de build 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'ancien GSI aosp_$arch_ab . L' init mis à niveau dans ramdisk prend en charge OEM system.img avec une disposition système en tant que racine.

Pour tester les appareils qui se lancent sur Android 9 ou 10 avec CTS-on-GSI, utilisez les cibles de build Android GSI .

GSI hérité

GSI hérités nommés avec le suffixe _ab (par exemple, aosp_arm64_ab ). Ces GSI sont construits à partir de l'arborescence des sources d'Android 10, mais contiennent les configurations rétrocompatibles suivantes pour les appareils mis à niveau à partir d'Android 8 ou 8.1:

  • Espace utilisateur 32 bits + interface de classeur 32 bits. Les GSI 32 bits peuvent continuer à utiliser l'interface de classeur 32 bits.
  • 8.1 VNDK. Les appareils peuvent utiliser le 8.1 VNDK inclus.
  • Monter les répertoires. Certains périphériques hérités utilisent des répertoires comme pointeurs de montage (par exemple, /bluetooth , /firmware/radio et /persist ).

Pour tester les appareils lancés sur Android 8 ou 8.1 avec CTS-on-GSI, utilisez les cibles de build Legacy GSI .

Modifications Android 9 GSI

Les GSI Android 9 incluent les changements majeurs suivants par rapport aux GSI précédents:

  • Fusionne GSI et émulateur. Les GSI sont construits à partir des images système des produits d' aosp_arm64 , 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 sous le répertoire /system . Dans 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 liant 32 bits. Android 9 ne prend pas en charge l'interface de liant 32 bits, de sorte que les GSI 32 bits et les GSI 64 bits utilisent l'interface de liant 64 bits.
  • Application VNDK. Dans Android 8.1, VNDK était facultatif. À partir d'Android 9, VNDK est obligatoire, donc BOARD_VNDK_VERSION doit ê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 à Android 9 Keymaster

Dans les versions antérieures d'Android, les appareils mettant en œuvre Keymaster 3 ou une version ro.build.version.release 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 supérieur, 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 inférieur, les fournisseurs doivent modifier l'implémentation Keymaster pour ignorer la vérification (ou passer à Keymaster 4). Pour plus de détails sur Keymaster, reportez -vous à Keystore matériel .

Binaires de fournisseur et dépendances VNDK

Les appareils mis à niveau vers Android 10 ont des chemins de mise à niveau différents en fonction de la version des binaires du fournisseur utilisée sur l'appareil et des configurations liées au VNDK utilisées pour construire l'appareil. Le tableau suivant résume le support GSI hérité pour les périphériques mis à niveau.

Cas d'utilisation Vendeur
binaires
version
BOARD_VNDK_VERSION GSI hérité
version des binaires système
Prise en charge de l'héritage GSI
0 8,0 (tout) dix Non
1 8.1 (vide) dix Non
2 8.1 current dix Oui
3 dix current dix Oui

Le cas d'utilisation pris en charge le plus courant est le n ° 2, où les anciens GSI prennent en charge les appareils exécutant Android 8.1 qui ont été BOARD_VNDK_VERSION avec BOARD_VNDK_VERSION défini sur current .

Le cas n ° 1 n'est pas pris en charge. Dans ce cas, les anciens GSI ne prennent PAS en charge les appareils exécutant Android 8.1 sur lesquels BOARD_VNDK_VERSION est omis de la compilation. Ces appareils ne peuvent pas être pris en charge, car les binaires de leurs fournisseurs dépendent des bibliothèques partagées Android 8.1 non VNDK, qui ne sont pas incluses dans les anciens GSI. Pour rendre ces appareils compatibles avec un GSI hérité, vous devez effectuer l'une des opérations suivantes:

  • Activez BOARD_VNDK_VERSION sans BOARD_VNDK_RUNTIME_DISABLE (cas d'utilisation n ° 2).

    OU

  • Portez / mettez à niveau les binaires du fournisseur pour qu'ils dépendent des bibliothèques partagées d'Android 10 (cas d'utilisation n ° 3).

Téléchargement des GSI

Vous pouvez télécharger des GSI prédéfinis à partir du site Web d'intégration continue (CI) AOSP à ci.android.com . Si le type GSI de votre plate-forme matérielle n'est pas disponible pour le 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 a une branche GSI nommée DESSERT -gsi sur AOSP (par exemple, android10-gsi est la branche GSI sur Android 10). Les branches GSI incluent le contenu d'Android avec tous les correctifs de sécurité et 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 des cibles de construction 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 . La version vbmeta.img également vbmeta.img , que vous pouvez utiliser pour désactiver le démarrage de vérification sur les appareils à l'aide d' Android Verified Boot .

Par exemple, pour créer la cible de aosp_arm64-userdebug GSI aosp_arm64-userdebug sur la branche GSI android10-gsi , exécutez les commandes suivantes.

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Cibles de build Android GSI

Les cibles de build GSI suivantes concernent les appareils lancés sur Android 9 ou version ultérieure. En raison d'une réduction des écarts entre les architectures, Android 10 ne comprend que quatre produits GSI.

Nom GSI Arc de CPU Bitness d'interface de liant Système en tant que racine Créer une cible
aosp_arm BRAS 64 Oui aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Oui aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Oui aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Oui aosp_x86_64-user
aosp_x86_64-userdebug

Cibles de build héritées GSI

Les cibles de build héritées suivantes sont destinées aux appareils passant d'Android 8.0 ou 8.1 à Android 10. Les noms GSI hérités incluent le suffixe _ab pour les distinguer des noms Android 10 GSI.

Nom GSI Arc de CPU Bitness d'interface de liant Système en tant que racine Créer une cible
aosp_arm_ab BRAS 32 Oui aosp_arm_ab-userdebug
aosp_arm_64b_ab BRAS 64 Oui aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Oui aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Oui aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Oui aosp_x86_64_ab-userdebug

Exigences pour les GSI clignotants

Les appareils Android peuvent avoir des conceptions différentes, il n'y a donc pas de commande générique ou 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 à titre indicatif:

  1. Assurez-vous que l'appareil dispose des éléments suivants:
    • Treblisé
    • Une méthode pour déverrouiller les appareils (afin qu'ils puissent être flashés à l'aide de fastboot )
    • Une méthode pour désactiver la vérification du démarrage (par exemple, vboot 1.0 ou AVB )
    • Un état déverrouillé pour le rendre flashable via fastboot (pour vous assurer que vous disposez de la dernière version de fastboot , fastboot -le à partir de l'arborescence des sources Android.)
  2. Désactivez la vérification du démarrage.
  3. Effacez la partition système actuelle, puis flashez le GSI sur la partition système.
  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).
  5. Redémarrez l'appareil.

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

  1. Démarrez en mode de démarrage fastboot et déverrouillez le chargeur de démarrage . Les périphériques prenant en charge fastbootd doivent également démarrer dans fastbootd en:
    $ fastboot reboot fastboot
  2. Désactivez la vérification du démarrage (AVB) en faisant clignoter vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  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 dotés de partitions système plus petites, le message d'erreur suivant peut apparaître lors du clignotement 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'ID d'emplacement de la partition système, tel que system_a dans cet exemple.

Contribuer aux GSI

Android accueille 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 cherrypicks de la branche maître AOSP, donc pour soumettre un patch GSI, vous devez:
    1. Soumettez le correctif à la branche master AOSP .
    2. Cherrypiquez le patch sur DESSERT -gsi .
    3. Enregistrez un bogue pour vérifier le cherrypick.
  • Signaler des bogues GSI ou faire d'autres suggestions. Passez en revue les instructions dans Signaler les bogues , puis parcourez ou enregistrez les bogues GSI .

Conseils

Changer 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é en remplaçant le 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ù le mode peut être threebutton , deux twobutton , gestural , etc.