À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Exécuter des tests multiappareils avec le vérificateur CTS

Cette page contient des instructions pour utiliser les tests CTS Verifier (CTS-V) Better Together pour Android 16 QPR2 ou version ultérieure.

Configurer des tests multiappareils côté hôte

Cette section explique comment configurer des tests multi-appareils.

Vérifiez que votre ordinateur de bureau respecte la configuration requise pour le système d'exploitation du CTS.
Suivez les étapes 2 et 5 de Installer un logiciel pour ordinateur pour installer et vérifier que adb, AAPT2 et Python sont correctement installés sur votre ordinateur.
- Votre version de Python doit être 3.11 ou ultérieure. Pour déterminer votre version de Python, exécutez python3 --version. Si la version est antérieure à la version 3.11, installez la dernière version officielle de Python. Pour en savoir plus, consultez la section Téléchargements de python.org.
- Certains tests nécessitent que l'hôte dispose du module Python venv. Sur les systèmes Debian et Ubuntu, ce module n'est peut-être pas installé par défaut. Pour déterminer si votre version de Python dispose du module venv, exécutez python3 -m venv venv. Si cette commande échoue, un message d'erreur s'affiche. Suivez les instructions pour installer le package python3.x-venv.
Préparez deux appareils testés (DUT) identiques, chacun avec CTS-V configuré.
- Pour savoir comment configurer un appareil en test, consultez Configurer l'appareil en test.
- Pour savoir comment configurer CTS-V, consultez Configuration.
Accédez à la section de configuration correspondant à votre type de test :
- Pour les tests NFC, consultez Configurer les tests NFC.
- Pour les tests de connexion au point d'accès Wi-Fi, consultez Configurer des tests de connexion au point d'accès Wi-Fi.
- Pour tester le module CDM, accédez à Configurer des tests standards sur deux appareils, puis à Configurer des tests CDM.
Si votre test ne figure pas dans cette liste, passez à Configurer des tests standards à deux appareils.

Configurer des tests NFC

Les tests NFC utilisent un DUT et une puce NFC PN532.

Pour configurer des tests NFC :

Achetez une puce NFC PN532. Nous vous recommandons d'utiliser le lecteur tout-en-un PN532.
Sur le DUT, accédez à l'application Paramètres.
Activez le NFC.
Positionnez la puce NFC :
- Pour les téléphones, positionnez le lecteur NFC du DUT comme indiqué sur la figure 1 :
  
  Figure 1 : Positionnement de la puce NFC.
- Pour les autres types d'appareils, placez la puce à côté de l'antenne NFC de l'appareil.
Connectez la puce NFC PN532 à votre poste de travail de test à l'aide d'un câble USB.

Facultatif : Configurer des tests de connexion au point d'accès Wi-Fi

Les tests de connexion au point d'accès Wi-Fi (CtsWifiConnectionTests) testent la connectivité entre un DUT et un point d'accès. Nous vous recommandons vivement d'exécuter ces tests, mais ils ne sont pas obligatoires dans CTS-V Android 16 16 QPR2.

Ces tests nécessitent un DUT et un point d'accès OpenWrt Banana Pi R3.

Pour configurer des tests de connexion au point d'accès Wi-Fi :

Achetez le Banana Pi R3 AP et les accessoires listés dans ce tableau :

Élément	Quantité
Carte BPi-R3, semblable à la carte routeur Banana Pi BPI-R3 avec puce MediaTek MT7986 ,compatible avec le Wi-Fi 6 ,2 Go de RAM DDR et 8 Go de mémoire flash eMMC intégrée	1
Boîtier en aluminium BPi-R3, semblable au boîtier BPI-R3 Iron	1
Dissipateur thermique en aluminium BPi-R3 (ventilateur), semblable au dissipateur thermique en aluminium BPI-R3 avec ventilateur	1
Antenne 2 et 5 GHz avec câble, semblable à l'antenne 5 dB de la boutique BPI	8
Adaptateur secteur, semblable à l'alimentation 12 V/2 A CC	1

Pour effectuer votre achat, consultez la section Easy to buy (Facile à acheter) de la page Banana Pi BPI-R3.

Configurez le point d'accès. Pour savoir comment configurer le point d'accès, consultez Configurer le point d'accès Banana Pi BPI-R3.
Facultatif : Si vous ne disposez pas d'un boîtier de protection, nous vous recommandons le boîtier de protection JTP-SR101. Achetez cette boîte en utilisant les informations suivantes :

Dong Guan Zheng Sheng Electronics Technology Co., LTD
Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, Chine
Contact : Forest Pan
Adresse e-mail : forest.pan@jtpmak.cn
Téléphone (Chine) : +86 18676993556

Remarque : Un boîtier blindé permet d'isoler les signaux externes et de séparer le DUT et le PA de 10 cm.
Connectez le DUT et le PA à l'hôte, puis placez-les dans une boîte blindée RF. Le DUT et le point d'accès doivent être espacés d'au moins 10 cm. La figure 2 illustre cette configuration :

Figure 2. DUT et PA dans une boîte blindée.
Utilisez SSH pour vérifier que le point d'accès est accessible depuis l'hôte.

Configurer des tests standards à deux appareils

Pour la configuration par défaut à deux appareils :

Placez deux appareils Android de test identiques à environ 20 cm l'un de l'autre.
Pour configurer un environnement propre, placez les deux appareils dans une boîte blindée.

Remarque : Si vous rencontrez des problèmes avec ces tests et que vous avez besoin d'aide, vérifiez que les tests ont été exécutés avec les deux appareils dans une boîte blindée.
Facultatif : Configurez un renifleur OTA pour le débogage du Wi-Fi.

Configurer les tests CDM

Le comportement du cas de test test_permissions_sync() varie en fonction du type de compilation des appareils sur lesquels le test est exécuté. Il est essentiel que les OEM testent les deux versions (débogables [userdebug ou eng] et non débogables [user]) et que les tests réussissent pour les deux.

Exemption

La clause CDD pour l'implémentation de l'API de synchronisation des autorisations exige uniquement qu'elle soit capable de transférer des données entre les appareils sur un canal sécurisé. Étant donné que l'implémentation du canal sécurisé n'est pas une exigence de conformité du CDD, ce test peut être ignoré sur les builds non débogables (utilisateur), mais uniquement si vous souhaitez désactiver la fonctionnalité de synchronisation des autorisations CDM.

Les tests doivent réussir sur les builds débogables sans exception.

Conditions requises pour effectuer des tests sur des builds non débogables

Si vous n'êtes pas exempté par les clauses d'exemption précédentes, vérifiez que vous remplissez les conditions préalables suivantes.

Le canal sécurisé utilise AVF (AttestationVerificationFramework) pour vérifier la fiabilité du matériel. Les attestations générées par les deux parties contiennent plusieurs informations sur elles-mêmes pour s'assurer qu'aucune modification non autorisée n'a été apportée à leur système. L'AVF vérifie les états suivants lors du processus de validation :

L'appareil a accès à Internet
L'appareil utilise le démarrage sécurisé et la compilation doit être signée avec une clé de version, et non une clé de développement.
Le bootloader de l'appareil est verrouillé. Pour obtenir des instructions détaillées, consultez Verrouiller le bootloader.
Les niveaux de correctifs de l'OS, du boot principal et du fournisseur de clés datent de moins de 12 mois. N'utilisez pas une version datant de plus d'un an.
L'attestation de l'appareil est soutenue par l'un des certificats racine approuvés par le fournisseur. Spécifiez vos certificats racine de confiance dans la superposition de ressources vendor_required_attestation_certificates.xml.

Exécuter des tests multiappareils côté hôte (AOSP 16 ou version ultérieure)

CTS Verifier 16 est compatible avec les tests multiappareils côté hôte. Ces tests peuvent être exécutés à l'aide de scripts automatisés sur l'hôte, au lieu de l'opération de test manuel sur l'appareil. Une fois chaque test terminé, les résultats sont automatiquement importés sur l'appareil testé et affichés dans l'application CTS Verifier.

Cette section explique comment exécuter les tests multidispositifs côté hôte.

Exécuter des tests multidétecteurs

Pour effectuer un test multi-appareil :

Sur votre poste de travail de test, lancez la console cts-v-host à partir du répertoire dans lequel le package zip CTS-V a été décompressé :
```
./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed
```
Dans l'application CTS Verifier sur l'appareil à tester, cliquez sur Host-side Tests. La figure 3 montre les tests côté hôte dans l'application CTS Verifier :

Figure 3. Tests multiappareils côté hôte dans l'application CTS Verifier.

Une liste de modules de test multiappareils côté hôte s'affiche.
Identifiez le nom du module de test que vous souhaitez exécuter. Par exemple, le module CompanionDeviceManager est listé sous CtsCompanionDeviceManagerMultiDeviceTestCases.

Remarque : Si vous appuyez sur un module côté hôte dans l'application CTS Verifier, vous ne verrez pas de liste de cas de test individuels. Au lieu de cela, l'UI est automatiquement renseignée avec les résultats des cas de test une fois le module exécuté sur l'hôte.
Dans la console cts-v-host, exécutez la commande suivante :
```
run cts-v-host -m test_module_name
```
Exemple :
```
run cts-v-host -m CtsCompanionDeviceManagerMultiDeviceTestCases
```
Remarque : Si vous exécutez cts-v-host sans utiliser -m test_module_name, la commande tente d'exécuter tous les modules de test, en ignorant les écarts dans les exigences concernant l'appareil et le matériel. Exécutez plutôt la commande run cts-v-host-default-devices pour exécuter les tests avec la configuration standard en tant que sous-plan unique.
Remarque : Vous pouvez indiquer les DUT spécifiques à tester à l'aide de leur numéro de série : run cts-v-host -m test_module_name -s\ device1_serial -s device2_serial ...

Une fois que la console xTS a terminé d'exécuter les tests, les résultats s'affichent dans l'application CTS Verifier. Les tests marqués en vert ont réussi. Les tests marqués en rouge ont échoué. La figure 4 montre des exemples de résultats pour les tests CtsCompanionDeviceManager :

Figure 4. Résultats des tests multiappareils côté hôte dans l'application CTS Verifier.

Remarque : Les résultats côté hôte sont automatiquement ajoutés au rapport de test CTS-V global.

Facultatif : Exécuter des tests de connexion au point d'accès Wi-Fi

Pour exécuter des tests de connexion à un point d'accès Wi-Fi :

Modifiez le fichier de configuration du banc d'essai (WifiConnectionTestbed.yaml). Ce fichier se trouve dans le répertoire où CTS-Verifier est décompressé :
```
./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
```
Remplacez la valeur du champ hostname par l'adresse IP du point d'accès, en fonction de vos paramètres SSH locaux. Pour identifier l'adresse IP, consultez Trouver l'adresse IP du point d'accès.

L'exemple suivant montre l'emplacement du champ hostname dans le fichier WifiConnectionTestbed.yaml :
```
TestBeds:
- Name: WifiConnectionTestbed
  Controllers:
    # Specify settings for the AP.
    OpenWrtDevice:
    - hostname: AP-IP
      skip_init_reboot: True
```
Dans la console cts-v-host, exécutez la commande suivante :
```
run everything -m CtsWifiConnectionTests
```
Remarque : Pour en savoir plus sur la console cts-v-host, consultez Exécuter des tests multidispositifs.

Résoudre les problèmes liés aux tests multi-appareils

Cette section fournit des conseils de dépannage pour les problèmes potentiels.

Corriger l'absence de réponse pour GetFirmwareVersion lors des tests NFC

Si le message verify_firmware_version RuntimeError: No response for GetFirmwareVersion s'affiche lorsque vous exécutez les tests multidispositifs, cela signifie que les tests ne peuvent pas accéder à la carte NFC PN532.

Pour résoudre ce problème, identifiez le chemin série utilisé par la carte NFC PN532 sur votre hôte, tel que dev/ttyUSB1, puis spécifiez-le manuellement à l'aide de l'argument --module-arg dans la console :

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Corriger le message d'erreur "Échec de la transaction" lors des tests NFC

Si le message Transaction failed, check device logs for more information. s'affiche pour tous les cas de test NFC, cela signifie probablement que la puce NFC du DUT ne peut pas détecter le PN532.

Si plusieurs appareils sont connectés à l'hôte et que certains d'entre eux ne sont pas équipés d'un PN532, le mauvais DUT peut avoir été sélectionné. Pour en savoir plus, consultez Configurer des tests NFC.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

Définissez le numéro de série du DUT dans votre commande de test côté hôte à l'aide de l'indicateur -s.
Déconnectez tous les appareils autres que le DUT de l'hôte.

Le scénario de test CDM `test_permissions_sync` est ignoré

Si le test est exécuté sur des appareils non débogables, vérifiez si vous êtes exempté. Sinon, vérifiez que les deux appareils répondent aux conditions préalables.