FAQ CTS

Le programme de compatibilité Android est le principal moteur du maintien des retours positifs sur l'écosystème Android. CTS est l'outil clé pour garantir la qualité de la compatibilité dans la balance. L'équipe Android continue d'améliorer l'outil CTS et la couverture des tests. L'ajout régulier de cas de tests améliore considérablement la qualité des appareils compatibles.

Questions générales

Cette section fournit une FAQ générale sur CTS.

Quels genres de choses le CTS teste-t-il ?

Le CTS teste que toutes les API à typage fort Android prises en charge sont présentes et se comportent correctement. Le CTS teste également d'autres comportements du système non-API tels que le cycle de vie et les performances des applications.

Comment le CTS est-il agréé ?

Le CTS est sous licence sous la même licence logicielle Apache 2.0 que celle utilisée par la majeure partie d'Android.

Les codecs sont-ils vérifiés par CTS ?

Oui. Tous les codecs obligatoires sont vérifiés par CTS.

Questions spécifiques au test

Cette section fournit des FAQ qui aident à exécuter les tests CTS plus efficacement.

Quelle est la différence entre le partage CTS et le partage TF ?

CTS Sharding et TF Sharding sont des plans de test totalement différents alimentés par une base de code d'infrastructure de test différente. Bien que la commande d'exécution soit la même dans les différentes versions, le résultat du partitionnement se comporte différemment. CTS Sharding attribue statiquement les scénarios de test aux appareils sous test (DUT) comme suit :

TF Sharding attribue dynamiquement les cas de test aux DUT disponibles comme suit :

Qu’attend-on d’un appareil prenant en charge plusieurs ABI ?

L'appareil doit réussir tous les tests CTS et CTS Verifier pour chaque mode ABI qu'il prétend prendre en charge. Par conséquent, il est nécessaire d’exécuter une application pour les ABI particuliers. Les lignes directrices pour plusieurs ABI sont les suivantes :

  • Pour CTS et CTS Verifier, il existe des versions ARM et x86 pour chaque architecture. Chacun d'eux peut prendre en charge le mode 32 ou 64 bits.
  • Pour les tests CTS, si un appareil prend en charge à la fois ARM et x86, il doit exécuter et réussir les tests CTS ARM et x86 respectivement.

Voir CDD 3.3.1. Interfaces binaires d'application pour les exigences CDD sur ABI.

Est-il suffisant d'exécuter un test uniquement sur l'ABI principal (par exemple 64 bits) pour réduire le temps d'exécution des tests ?

Non. Une application Android fonctionne sur son propre environnement d'exécution 32 bits ou 64 bits. Le code machine réel, le chemin du code et l'état sont différents entre 32 et 64. Si vous sautez un mode, vous ne couvrez que 50 % de l'ABI de l'appareil.

Pourquoi y a-t-il tant de cas de test signalés comme non exécutés ?

Vous devez vérifier le numéro du module terminé au lieu du numéro non exécuté .

Dans les versions précédentes, les modules CTS étaient signalés comme Module Terminé de manière trop agressive avant d'être terminés. Par conséquent, un numéro de modules terminés a été signalé sans que tous les scénarios de test soient terminés, même lorsque certains appareils rencontraient des problèmes. Le nouveau faisceau de tests est plus conservateur et signale un nombre plus élevé de tests non exécutés lorsqu'un problème survient.

Un module exécuté jusqu'à la fin signale que le module n'est pas terminé lors de l'appel le plus récent (done="false") dans le rapport dans les cas suivants :

  • Un test du module a été interrompu par un problème de connexion de l'appareil.
  • Tous les tests attendus pour le module n'ont pas été effectués.

  • Nouvelle tentative (à l'aide de l'option -r/--retry ) avec des options de filtrage supplémentaires, telles que :

    • --include-filtre
    • --exclure-filtre
    • -t/--test (option non encore prise en charge lors d'une nouvelle tentative)
    • --retry-type a échoué
    • --sous-plan

Pour obtenir un statut Module Terminé (done="true") pour ces modules, réessayez ce qui suit pour l'appel le plus récent :

run retry --retry <session_id> for Android 9 and later versions

run cts --retry <session_id> for Android 8.1 and previous versions

Un module exécuté sans aucun des problèmes mentionnés précédemment (même avec 0 test restant) est marqué Module terminé dans le nouveau rapport.

Des exceptions

  • CtsNNAPITestCases a un problème connu en raison de la limitation des arguments Linux/OS. Le module peut être réexécuté de manière isolée via run cts -m CtsNNAPITestCases directement.

Comment puis-je éviter l'échec de la préparation des tests derrière le pare-feu de l'entreprise ?

Toutes les suites de tests automatisés tentent de télécharger soit les fichiers multimédias CTS, soit les fichiers de logique métier pendant l'exécution. Dans de nombreux environnements d'entreprise, un pare-feu et un proxy sont courants, ce qui fait échouer la préparation du test. Exécutez la ligne suivante ou ajoutez-la à .profile (sur Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

Ai-je besoin d'une carte SIM pour CTS pour Secure Element ?

La nécessité ou non d'une carte SIM pour le test dépend de la compréhension de la prise en charge de la fonctionnalité par l'appareil de test.

  • Si votre appareil N'A PAS besoin de prendre en charge les applications Android accédant aux éléments sécurisés, que ce soit dans l' UICC (par exemple, une carte SIM) distribué par les opérateurs de réseau mobile (opérateurs) ou intégré dans l'appareil, vous pouvez configurer le manifeste HIDL pour ne pas inclure l'élément HAL android.hardware.secure_element . Dans ce cas, l'API android.se.omapi.SEService.getReaders() signale une liste vide et le test CTS réussit automatiquement et signale une réussite pour le CTS.
  • Si votre appareil doit prendre en charge les applications Android accédant à des éléments sécurisés, soit dans l' UICC (par exemple, une carte SIM) distribué par les opérateurs de réseau mobile (opérateurs), soit intégrés dans l'appareil, vous devez implémenter correctement l'élément sécurisé et le tester. en interne. Le test CTS pour Secure Element explique comment se préparer à exécuter les tests CTS qui garantissent que le package API android.se.omapi ajouté dans Android 9 est fonctionnel. Nous vous recommandons également d'effectuer des tests supplémentaires par vous-même, car la couverture des tests CTS est minime.

Où puis-je me procurer les cartes SIM pour CTS pour Secure Element ?

Vous pouvez contacter votre fournisseur de carte SIM préféré.

Pourquoi Orange SIM est-il sur l'écran de verrouillage lors de l'exécution de CTS avec partage de token ?

Le scénario de test ne démarre pas car le test de la carte SIM est verrouillé. Désactivez le verrouillage de la carte SIM dans **Paramètres de verrouillage de la carte SIM avant d'exécuter le CTS avec le partage de jeton.