Configurer CTS

Pour exécuter CTS, préparez d'abord votre environnement physique, votre ordinateur de bureau et l'appareil Android que vous utilisez pour les tests.

Environnement physique

Balises Bluetooth LE

Si l'appareil testé est compatible avec la technologie Bluetooth LE, placez au moins trois balises Bluetooth LE à moins de 5 mètres de l'appareil pour tester la technologie Bluetooth LE. Ces balises n'ont pas besoin d'être configurées ou émettent quelque chose de spécifique et peuvent être de n'importe quel type, y compris des iBeacon, Eddystone ou même des appareils simulant des balises BLE.

Bande ultralarge

Si l'appareil testé est compatible avec la bande ultralarge (UWB), un autre appareil compatible avec la technologie UWB doit être placé suffisamment près et orienté de manière à ne pas comporter d'antenne ni de zone morte radio. Les tests de précision de la distance nécessitent des besoins spécifiques en termes de positionnement et d'orientation. Pour en savoir plus sur la configuration, consultez la configuration requise pour l'UWB. Le test UWB doit être exécuté manuellement, en spécifiant dans la ligne de commande les deux appareils qui sont à un mètre l'un de l'autre. Pour en savoir plus sur la segmentation requise pour ce test, consultez la section Segmentation locale.

Appareils photo

Lorsque vous exécutez l'outil CTS de l'appareil photo, utilisez des conditions d'éclairage normales avec un graphique de motifs de test (un motif en damier, par exemple). Placez le graphique des modèles de test en fonction de la distance de mise au point minimale de l'appareil testé, afin de vous assurer qu'il n'est pas trop proche de l'objectif.

Dirigez les capteurs de l'appareil photo vers une scène offrant un éclairage suffisant pour permettre aux capteurs testés d'atteindre le nombre maximal d'images par seconde (FPS) configuré, comme spécifié dans CONTROL_AE_TARGET_FPS_RANGE. Cela s'applique à tous les capteurs de caméra signalés par getCameraIdList, car le test est itéré sur les appareils répertoriés et mesure les performances individuellement.

Si l'appareil testé est compatible avec les caméras externes, telles que les webcams USB, branchez une caméra externe lorsque vous exécutez CTS. Sinon, les tests CTS échouent.

GPS/GNSS

Si l'appareil testé est compatible avec la fonctionnalité GPS/GNSS, fournissez-lui un signal GPS/GNSS à un niveau de signal approprié pour calculer la réception et la localisation GPS. La partie GPS doit être conforme à la norme ICD-GPS-200C. Sinon, le signal GPS/GNSS peut être de n'importe quel type, y compris un simulateur de satellite ou un répéteur GPS/GNSS de signaux extérieurs. Vous pouvez également placer l'appareil testé suffisamment près d'une fenêtre pour recevoir directement un signal GPS/GNSS suffisant.

Wi-Fi et IPv6

Les tests CTS nécessitent un réseau Wi-Fi compatible avec IPv4 et IPv6, qui dispose d'une connexion Internet avec un DNS opérationnel pour IPv4 et IPv6, qui accepte la multidiffusion IP et qui peut traiter l'appareil testé comme un client isolé. Un client isolé est une configuration dans laquelle l'appareil testé n'a pas de visibilité sur les messages broadcast/multiréseaux sur ce sous-réseau. Cela se produit avec une configuration de point d'accès Wi-Fi (PA) ou lorsque l'appareil testé est exécuté sur un sous-réseau isolé sans que d'autres appareils soient connectés.

Si vous n'avez pas accès à un réseau IPv6 natif, à un réseau d'opérateur IPv6 ou à un VPN pour réussir certains tests en fonction de l'IPv6, vous pouvez utiliser un point d'accès Wi-Fi et un tunnel IPv6.

Pour réussir CTS, l'appareil testé doit disposer des options UP, BROADCAST et MULTICAST au niveau de l'interface Wi-Fi. Des adresses IPv4 et IPv6 doivent être attribuées à l'interface Wi-Fi. Vérifiez les propriétés de l'interface Wi-Fi avec adb shell ifconfig.

Pour les appareils compatibles avec la simultanéité STA/STA Wi-Fi, plusieurs réseaux Wi-Fi (au moins deux) sont requis. Pour transmettre la CTS, les réseaux Wi-Fi doivent fonctionner sur des bandes différentes avec des SSID différents ou sur le même SSID avec des BSSID différents.

DAR Wi-Fi

Android inclut l'API de DAR Wi-Fi pour une fonctionnalité de délai aller-retour Wi-Fi (DAR). Les appareils peuvent ainsi mesurer leur distance avec des points d'accès avec une précision de 1 à 2 mètres, ce qui améliore considérablement la précision de la localisation en intérieur. Google Wifi et le point d'accès "fitlet2" de Compulab (défini sur une bande passante de 40 MHz à 5 GHz) sont recommandés pour prendre en charge le DAR Wi-Fi.

Les points d'accès doivent être sous tension, mais ne nécessitent pas de connexion réseau. Les points d'accès n'ont pas besoin d'être à côté de l'appareil de test, mais il est recommandé de se trouver à moins de 12 mètres de l'appareil testé. Un point d'accès suffit généralement.

Configuration de l'ordinateur de bureau

Attention: CTS est compatible avec les machines Linux 64 bits. CTS n'est pas compatible avec les systèmes d'exploitation Windows et macOS.

FMPEG

Installez le package ffmpeg version 5.1.3 (ou ultérieure) sur la machine hôte.

Mise à niveau de la machine hôte

Nous vous recommandons vivement de mettre à niveau la RAM de la machine hôte CTS à 128 Go et le disque dur à 256 Go. Elle est nécessaire pour prendre en charge l'augmentation du nombre de scénarios de test CTS et de la réservation d'espace de tas de mémoire Java dans les données échangées.

ADB et AAPT2

Avant d'exécuter CTS, assurez-vous d'avoir installé les versions récentes d'Android Debug Bridge (adb) et d'Android Asset Packaging Tool (AAPT2), et d'avoir ajouté l'emplacement de ces outils au chemin d'accès système de votre machine.

Pour installer ADB et AAPT2, téléchargez les dernières versions des outils de plate-forme du SDK Android et des outils de compilation du SDK Android à partir de SDK Manager d'Android Studio ou de l'outil de ligne de commande sdkmanager.

Assurez-vous que adb et aapt2 se trouvent dans votre chemin d'accès système. La commande suivante suppose que vous avez téléchargé les archives de package dans un sous-répertoire appelé android-sdk de votre répertoire d'accueil:

export PATH=$PATH:$HOME/android-sdk/platform-tools:$HOME/android-sdk/build-tools/<tools version number>

Java Development Kit pour Ubuntu

Installez la version appropriée du kit de développement Java (JDK).

  • Pour Android 11, installez OpenJDK11.
  • Pour Android 9 et Android 10, installez OpenJDK9.
  • Pour Android 7.0, 7.1, 8.0 et 8.1, installez OpenJDK8.

Pour en savoir plus, consultez les exigences concernant le JDK.

Configuration pour la compatibilité avec Python

Installez virtualenv pour votre plate-forme en suivant les instructions d'installation.

Vous pouvez vérifier que l'installation a réussi en appelant virtualenv -h.

Fichiers CTS

Téléchargez et ouvrez les packages CTS à partir des Téléchargements de la suite de tests de compatibilité correspondant à la version d'Android de vos appareils et à toutes les interfaces binaires d'application (ABI) compatibles avec vos appareils.

Téléchargez et ouvrez la dernière version des fichiers multimédias CTS.

Télécharger les fichiers CTS liés à Mainline (facultatif)

Lorsque vous exécutez une version CTS pour la première fois, CTS télécharge de manière dynamique certains fichiers CTS liés à Mainline, ce qui ajoute au moins 10 minutes à la durée d'exécution, en fonction de la vitesse de votre réseau.

Pour éviter cette nouvelle durée d'exécution CTS, vous pouvez télécharger les fichiers CTS liés à Mainline avant d'exécuter la version CTS. Pour ce faire, procédez comme suit:

  1. Obtenez le niveau d'API Android sur l'appareil en exécutant la commande suivante:

    adb shell getprop ro.build.version.sdk
    
  2. Suivez les instructions du script download_mcts.sh pour télécharger les fichiers CTS Mainline.

    Le téléchargement prend au moins 10 minutes, selon le débit de votre réseau.

Détection des appareils

Suivez la procédure pour configurer votre système afin qu'il détecte votre appareil.

Limite de mémoire

Vous voudrez peut-être augmenter la mémoire maximale disponible lors de l'exécution du test dans le script cts-tradefed. Pour en savoir plus, consultez l'exemple de CL.

Configuration des appareils Android

Builds utilisateur

Un appareil compatible est défini comme un appareil avec une version signée par un utilisateur ou une clé de version. Votre appareil doit exécuter une image système basée sur le build utilisateur compatible (Android 4.0 ou version ultérieure) provenant de noms de code, tags et numéros de build.

Propriété de compilation du premier niveau d'API

Certaines exigences CTS dépendent de la version avec laquelle un appareil a été initialement expédié. Par exemple, les appareils initialement livrés avec des versions antérieures peuvent être exclus de la configuration système requise qui s'applique aux appareils livrés avec des versions ultérieures.

Pour que ces informations soient disponibles pour CTS, les fabricants d'appareils auraient pu définir la propriété ro.product.first_api_level au moment de la compilation. La valeur de cette propriété correspond au premier niveau d'API avec lequel l'appareil a été lancé dans le commerce.

Les fabricants d'appareils peuvent réutiliser l'implémentation sous-jacente commune pour lancer un nouveau produit en tant que mise à niveau d'un produit existant du même groupe d'appareils. Les fabricants d'appareils peuvent éventuellement définir le niveau d'API du produit existant sur ro.product.first_api_level, afin que les exigences de mise à niveau soient appliquées à CTS et Treble/VTS.

Les fabricants d'appareils peuvent définir PRODUCT_SHIPPING_API_LEVEL dans leur fichier device.mk pour définir cette propriété, comme illustré dans l'exemple suivant:

# PRODUCT_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
PRODUCT_SHIPPING_API_LEVEL := 21

Premier niveau d'API pour Android 9 ou version ultérieure

Pour les appareils lancés avec Android 9 ou version ultérieure, définissez la propriété ro.product.first_api_level sur une valeur valide parmi Codenames, Tags, and Build Numbers (Noms de code, tags et numéros de version).

Premier niveau d'API pour Android 8.x ou version antérieure

Pour les appareils lancés sous Android 8.x ou version antérieure, annulez (supprimez) la propriété ro.product.first_api_level pour la première compilation du produit. Pour toutes les compilations suivantes, définissez ro.product.first_api_level sur la valeur correcte du niveau d'API. Cela permet à la propriété d'identifier correctement un nouveau produit et conserve les informations sur le premier niveau d'API du produit. Si l'indicateur n'est pas défini, Android attribue Build.VERSION.SDK_INT à ro.product.first_api_level.

Paquets de shims CTS

Android 10 ou version ultérieure inclut un format de package appelé APEX. Pour exécuter des tests CTS pour les API de gestion des APEX (tels que la mise à jour vers une nouvelle version ou la création de rapports sur les APEX actifs), vous devez préinstaller un package CtsShimApex sur une partition /system.

Le test de validation du correctif APEX vérifie l'implémentation de CtsShimApex.

Conditions requises pour ro.apex.updatable

  • Si la propriété ro.apex.updatable est définie sur true, CtsShimApex est obligatoire pour tous les appareils compatibles avec la gestion des packages APEX.

  • Si la propriété ro.apex.updatable est manquante ou n'est pas définie, CtsShimApex n'a pas besoin d'être préinstallé sur un appareil.

Le test de validation du correctif APEX vérifie l'implémentation de CtsShimApex.

Préinstallations et préchargements de CtsShim

À partir d'Android 11, CtsShimApex contient deux applications prédéfinies (créées à partir d'une source de compilation), qui ne contiennent aucun code à l'exception du fichier manifeste. CTS utilise ces applications pour tester les privilèges et les autorisations.

Si l'appareil n'est pas compatible avec la gestion des packages APEX (c'est-à-dire que la propriété ro.apex.updatable est manquante ou n'est pas définie), ou s'il exécute la version 10 ou une version antérieure, les deux applications prédéfinies doivent être préinstallées séparément dans le système.

Si APEX est compatible, les préinstallations de la version appropriée doivent être placées en tant que /system/apex/com.android.apex.cts.shim.apex.

Si des applications prédéfinies standards sont utilisées, CtsShim et CtsShimPriv pour la version appropriée doivent être placés respectivement sous /system/app/CtsShimPrebuilt.apk et /system/priv-app/CtsShimPrivPrebuilt.apk.

Le tableau suivant répertorie les préinstallations et les préchargements disponibles pour chaque version d'appareil et architecture.

Version de l'appareil Préinstaller
(si APEX est compatible)
Précharger
ARM x86 ARM x86
Android 14 android14-arm-release android14-x86-release android14-arm-CtsShim.apk

android14-arm-CtsShimPriv.apk

android14-x86-CtsShim.apk

android14-x86-CtsShimPriv.apk

Android 13 android13-arm-release android13-x86-release android13-arm-CtsShim.apk

android13-arm-CtsShimPriv.apk

android13-x86-CtsShim.apk

android13-x86-CtsShimPriv.apk

Android 12 android12-arm-release android12-x86-release android12-arm-CtsShim.apk

android12-arm-CtsShimPriv.apk

android12-x86-CtsShim.apk

android12-x86-CtsShimPriv.apk

Android 11 android11-arm-release android11-x86-release android11-arm-CtsShim.apk

android11-arm-CtsShimPriv.apk

android11-x86-CtsShim.apk

android11-x86-CtsShimPriv.apk

Android 10 android10-release android10-arm-CtsShim.apk

android10-arm-CtsShimPriv.apk

android10-x86-CtsShim.apk

android10-x86-CtsShimPriv.apk

Android 9, O et O-MR1 N/A N/A arm-CtsShim.apk

arm-CtsShimPriv.apk

x86-CtsShim.apk

x86-CtsShimPriv.apk

Pour réussir les tests, préchargez les applications dans les répertoires appropriés de l'image système sans avoir à les signer à nouveau.

Exemple d'applet

Android 9 a introduit les API Open Mobile. Pour les appareils qui signalent plusieurs éléments sécurisés, CTS ajoute des scénarios de test pour valider le comportement des API Open Mobile. Ces scénarios de test nécessitent l'installation unique d'un exemple d'applet dans l'élément sécurisé intégré (eSE) de l'appareil testé ou dans la carte SIM utilisée par l'appareil. L'exemple d'applet eSE et l'exemple d'applet SIM sont disponibles dans AOSP.

Pour en savoir plus sur les scénarios de test de l'API Open Mobile et du contrôle des accès, consultez la page Test CTS du composant sécurisé.

Exigences de stockage

Les tests de contrainte sur les médias CTS exigent que les extraits vidéo se trouvent sur un espace de stockage externe (/sdcard). La plupart d'entre eux proviennent de Big Buck Bunny, dont les droits d'auteur sont détenus par la Blender Foundation sous la licence Creative Commons Attribution 3.0.

L'espace requis dépend de la résolution de lecture vidéo maximale acceptée par l'appareil. Consultez la section 5 du document de définition de compatibilité Android pour connaître la version de plate-forme des résolutions requises.

Voici les exigences de stockage en fonction de la résolution maximale de lecture des vidéos:

  • 480 x 360: 98 Mo
  • 720 x 480: 193 Mo
  • 1 280 x 720: 606 Mo
  • 1 920 x 1 080: 1 863 Mo

Écran et stockage

  • Tout appareil sans écran intégré doit être connecté à un écran.
  • Si l'appareil dispose d'un emplacement pour carte mémoire, branchez une carte SD vide. Utilisez une carte SD compatible avec les bus UHS (ultra haut débit) disposant d'une capacité SDHC ou SDXC, ou une carte dont la classe de vitesse 10 ou supérieure est supérieure, pour vous assurer de passer la CTS.

  • Si l'appareil dispose d'emplacements pour carte SIM, branchez une carte SIM activée dans chacun d'eux. Si l'appareil prend en charge les SMS, chaque carte SIM doit avoir son propre champ de numéro renseigné. Pour les appareils équipés d'Android 12 ou version ultérieure, toutes les cartes SIM doivent être compatibles avec le stockage des numéros abrégés (ADN). Les cartes GSM et USIM contenant le fichier dédié aux télécommunications (DFTelecom) répondent à cette exigence.

UICC pour les développeurs

Pour exécuter les tests de l'API d'opérateur CTS, l'appareil doit utiliser une carte SIM dotée de privilèges d'opérateur CTS répondant aux exigences spécifiées dans Préparer l'UICC.

Configuration des appareils Android

  1. Rétablissez la configuration d'usine de l'appareil: Paramètres > Sauvegarder et réinitialiser > Rétablir la configuration d'usine.

  2. Définissez la langue de votre appareil sur Anglais (États-Unis): Paramètres > Langue et saisie > Langue.

  3. Si l'appareil prend en charge la personnalisation des polices par défaut, définissez la famille de polices sans-serif par défaut sur Roboto (la famille de polices sans-serif par défaut utilisée dans les builds AOSP).

  4. Activez le paramètre de localisation si l'appareil dispose d'une fonctionnalité GPS ou Wi-Fi/mobile: Settings > Location > On (Paramètres > Localisation > Activée).

  5. Connectez-vous à un réseau Wi-Fi compatible avec IPv6, pouvant traiter l'appareil testé comme un client isolé (voir Environnement physique ci-dessus) et disposer d'une connexion Internet: Settings > Wi-Fi (Paramètres > Wi-Fi).

  6. Assurez-vous qu'aucun schéma de verrouillage ni mot de passe n'est défini sur l'appareil : Settings > Security > Screen lock > None (Paramètres > Sécurité > Verrouillage de l'écran > Aucun).

  7. Activez Débogage USB sur votre appareil: Paramètres > Options pour les développeurs > Débogage USB.

  8. Définissez le format 12 heures: Paramètres > Date et heure > Utiliser le format 24 heures > Désactivé.

  9. Configurez l'appareil pour qu'il reste activé: Paramètres > Options pour les développeurs > Rester activé > Activé.

  10. Sous Android 5.x et 4.4.x uniquement, configurez l'appareil de manière à autoriser les positions fictives : Paramètres > Options pour les développeurs > Autoriser les positions fictives > Activé.

  11. Sur Android 4.2 ou version ultérieure, désactivez la validation des applications USB: Settings > Developer options > Verify apps over USB > Off (Paramètres > Options pour les développeurs > Vérifier les applications via USB > Désactivée).

  12. Sous Android 13 ou version ultérieure, configurez l'appareil pour autoriser le modem fictif : Settings > Developer options > Allow Mock Modem > On (Paramètres > Options pour les développeurs > Autoriser le modem fictif > Activé).

  13. Lancez le navigateur et fermez tous les écrans de démarrage/configuration.

  14. Connectez la machine de bureau qui sera utilisée pour tester l'appareil avec un câble USB.

  15. Avant d'exécuter CTS, définissez Roboto2 comme police sans-serif à l'aide d'un paramètre d' affordance accessible par l'utilisateur (non masqué).

Installation de fichiers

Installer et configurer des applications d'assistance sur l'appareil

  1. Configurez votre appareil en fonction de votre version CTS:

    • Versions CTS 2.1 R2 à 4.2 R4:configurez votre appareil (ou votre émulateur) pour exécuter les tests d'accessibilité avec : adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

      Sur l'appareil, activez la délégation: Paramètres > Accessibilité > Accessibilité > Délégation des services d'accessibilité.

    • Versions CTS 6.x ou antérieures:sur les appareils qui déclarent android.software.device_admin, configurez-le pour qu'il exécute le test d'administration des appareils à l'aide de la commande suivante : adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`

      Dans Settings > Security > Select device administrateurs (Paramètres > Sécurité > Sélectionner les administrateurs de l'appareil), activez les deux administrateurs d'appareil android.deviceadmin.cts.CtsDeviceAdminReceiver*. Assurez-vous que android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver et tous les autres administrateurs d'appareil préchargés restent désactivés.

  2. Copiez les fichiers multimédias CTS sur l'appareil comme suit:

    1. Accédez (cd) au chemin d'accès où les fichiers multimédias sont téléchargés et décompressés.
    2. Modifiez les autorisations du fichier : chmod u+x copy_media.sh

    3. Copiez les fichiers nécessaires:

      • Pour copier des extraits jusqu'à une résolution de 720 x 480, exécutez la commande suivante:

        ./copy_media.sh 720x480
        
      • Si vous n'êtes pas sûr de la résolution maximale, copiez tous les fichiers:

        ./copy_media.sh all
        
      • S'il y a plusieurs appareils sous adb, ajoutez l'option série (-s) d'un appareil spécifique à la fin. Par exemple, pour copier jusqu'à 720 x 480 pixels sur l'appareil portant la série 1234567, exécutez la commande suivante:

        ./copy_media.sh 720x480 -s 1234567