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 améliore 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 ?

Le CTS vérifie que toutes les API Android typées 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 que celle utilisée par la majeure partie d'Android.

Les codecs sont-ils validés par 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 le fractionnement CTS et le fractionnement TF ?

Le fractionnement CTS et le fractionnement TF sont des plans de test totalement différents, basés sur un code de base d'infrastructure de test différent. Bien que la commande d'exécution soit la même pour 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 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 comme Module terminé trop tôt avant d'être finalisés. Par conséquent, un nombre Modules Done a été signalé sans que l'ensemble du cas de test soit terminé, même lorsque certains appareils rencontraient des problèmes. Le nouveau banc d'essais est plus conservateur 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") dans le rapport lors des événements suivants:

  • Un test du module a été interrompu par un problème de connexion de l'appareil.
  • Toutes les exécutions de test prévues 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, par exemple:

    • --include-filter
    • --exclude-filter
    • -t/--test (option pas encore prise en charge lors de la nouvelle tentative)
    • Échec de --retry-type
    • --subplan

Pour obtenir un état Module Done (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 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 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, un pare-feu et un proxy sont courants, ce qui entraîne l'échec de la préparation des tests. 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() indique une liste vide, et le test CTS réussit automatiquement et indique un succès pour le 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 vous 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.