Questions fréquentes sur CTS

Le Programme de compatibilité Android est le principal moteur pour maintenir les commentaires positifs sur l'écosystème Android. Le CTS est l'outil clé pour garantir la qualité de la compatibilité à grande échelle. L'équipe Android continue d'améliorer l'outil CTS et la couverture des tests. L'ajout régulier de scénarios de test permet d'améliorer considérablement la qualité des appareils compatibles.

Questions générales

Cette section fournit des réponses aux questions fréquentes sur le CTS.

Quels types de tests le CTS effectue-t-il ?

La CTS vérifie que toutes les API Android de type fort compatibles sont présentes et se comportent correctement. Le CTS teste également d'autres comportements système non liés aux API, tels que le cycle de vie et les performances des applications.

Comment la CTS est-elle concédée sous licence ?

Le CTS est sous licence Apache Software License 2.0, la même licence que la majeure partie d'Android.

Les codecs sont-ils validés par le CTS ?

Oui. Tous les codecs obligatoires sont validés par CTS.

Questions spécifiques au test

Cette section contient des questions fréquentes qui vous aideront à exécuter les tests CTS plus efficacement.

Quelle est la différence entre la segmentation CTS et la segmentation TF ?

La segmentation CTS et la segmentation TF sont des plans de test totalement différents basés sur un codebase d'infrastructure de test différent. Bien que la commande d'exécution soit identique entre les différentes versions, le résultat du fractionnement se comporte différemment. La segmentation CTS attribue de manière statique des scénarios de test aux appareils testés (DUT) comme suit:

La segmentation TF attribue de manière dynamique des scénarios de test aux DUT disponibles comme suit:

Que doit-on attendre d'un appareil compatible avec plusieurs ABI ?

L'appareil doit réussir tous les tests CTS et CTS Verifier pour chaque mode d'ABI qu'il prétend prendre en charge. Par conséquent, il est nécessaire d'exécuter une application pour les ABI spécifiques. Voici les consignes à respecter pour les ABI multiples:

  • 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 bits ou 64 bits.
  • Pour les tests CTS, si un appareil est compatible avec ARM et x86, il doit exécuter et réussir les tests CTS ARM et x86, respectivement.

Voir le CDD 3.3.1. Interfaces binaires d'application pour connaître les exigences de CDD concernant les ABI.

Est-il suffisant d'exécuter un test uniquement sur l'ABI principale (par exemple, 64 bits) pour réduire la durée d'exécution du test ?

Non. Une application Android s'exécute sur ses propres environnements d'exécution 32 bits ou 64 bits. Le code machine, le chemin de code et l'état réels sont différents entre 32 et 64. Si vous ignorez un mode, vous ne couvrez que 50% de l'ABI de l'appareil.

Pourquoi tant de cas de test sont-ils signalés comme "Non exécutés" ?

Vous devez vérifier le nombre Module terminé au lieu du nombre Non exécuté.

Dans les versions précédentes, les modules CTS étaient signalés de manière trop agressive dans la catégorie Module Done (Module terminé) avant d'être terminés. Par conséquent, un nombre Modules Done était signalé sans que l'ensemble du cas de test soit terminé, même lorsque certains appareils rencontraient des problèmes. La nouvelle fonctionnalité de test est plus conservatrice et signale un nombre plus élevé de tests Non exécutés en cas de problème.

Un module exécuté jusqu'à la fin indique Module Not Done (Module non terminé) dans l'appel le plus récent (done="false") du rapport dans les cas suivants:

  • Un test du module a été interrompu par un problème de connexion de l'appareil.
  • Certaines exécutions de test attendues pour le module n'ont pas été effectuées.

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

    • --include-filter
    • --exclure-filtre
    • -t/--test (option non encore prise en charge lors de la nouvelle tentative)
    • Échec de --retry-type
    • --sous-plan

Pour obtenir un état Module Done (terminé="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 zéro test restant) est marqué comme Module terminé dans le nouveau rapport.

Exceptions

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

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

Toutes les suites de tests automatisées tentent de télécharger les fichiers multimédias CTS ou les fichiers de logique métier pendant l'exécution. Dans de nombreux environnements d'entreprise, l'utilisation d'un pare-feu et d'un proxy est courante, ce qui entraîne l'échec de 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 le composant sécurisé ?

La nécessité d'une carte SIM pour le test dépend de la confirmation que la fonctionnalité est prise en charge sur l'appareil de test.

  • Si votre appareil NE DOIT PAS 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ée par les opérateurs de réseau mobile (opérateurs) ou intégrée à l'appareil, vous pouvez configurer le fichier manifeste HIDL pour qu'il n'inclue pas 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 et signale automatiquement une réussite pour l'outil CTS.
  • Si votre appareil DOIT prendre en charge les applications Android qui accèdent à des éléments sécurisés, que ce soit dans l'UICC (par exemple, une carte SIM) distribuée par les opérateurs de réseau mobile (opérateurs) ou intégrée à l'appareil, vous devez implémenter correctement l'élément sécurisé et le tester en interne. Test CTS pour le composant sécurisé explique comment se préparer à exécuter les tests CTS qui garantissent que le package d'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 minimale.

Où puis-je obtenir les cartes SIM pour CTS pour le composant sécurisé ?

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

Pourquoi la carte SIM Orange s'affiche-t-elle sur l'écran de verrouillage lors de l'exécution du CTS avec le fractionnement de jetons ?

Le cas de test ne démarre pas, car la carte SIM est verrouillée. Désactivez l'option Verrouiller la carte SIM dans les paramètres de verrouillage de la carte SIM avant d'exécuter le CTS avec le fractionnement de jetons.