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 assurer la qualité de la compatibilité à l'é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 questions fréquentes générales sur le CTS.

Quels types d'éléments le CTS teste-t-il ?

Le CTS teste que toutes les API Android à typage 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 le CTS est-il concédé sous licence ?

La suite de tests de conformité est concédée sous licence Apache Software License 2.0, qui est la même que celle utilisée par la majeure partie d'Android.

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

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

Questions spécifiques aux tests

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

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

Le partitionnement CTS et le partitionnement TF sont des plans de test totalement différents, basés sur différents codes d'infrastructure de test. Bien que la commande d'exécution soit la même pour différentes versions, le résultat du partitionnement se comporte différemment. La segmentation CTS attribue statiquement des scénarios de test aux appareils testés (DUT) comme suit :

TF Sharding attribue dynamiquement des scénarios de test aux DUT disponibles comme suit :

Que doit faire 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. Il est donc nécessaire d'exécuter une application pour les ABI spécifiques. Voici les consignes à suivre pour plusieurs ABI :

  • 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 CDD 3.3.1. Interfaces binaires d'application pour les exigences du CDD concernant l'ABI.

Est-il suffisant d'exécuter un test uniquement sur l'ABI principale (par exemple, 64 bits) pour réduire le temps 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 bits. 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 Done au lieu du nombre Not Executed.

Dans les versions précédentes, les modules CTS étaient signalés comme Module Done de manière trop agressive avant d'être terminés. Par conséquent, un nombre Modules Done a été signalé sans que tous les scénarios de test soient terminés, même lorsque certains appareils présentaient des problèmes. Le nouveau harnais de test est plus conservateur et signale un plus grand nombre de tests Non exécutés en cas de problème.

Un module exécuté jusqu'à la fin indique Module non terminé dans la dernière invocation (done="false") du rapport dans les cas suivants :

  • L'exécution d'un test pour le module a été interrompue en raison d'un problème de connexion de l'appareil.
  • Toutes les exécutions de tests attendues pour le module n'ont pas été effectuées.

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

    • --include-filter
    • --exclude-filter
    • -t/--test (option non encore compatible avec la réexécution)
    • Échec de --retry-type
    • --subplan

Pour obtenir l'état Module terminé (done="true") pour ces modules, réessayez ce qui suit pour la dernière invocation :

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.

Exceptions

  • CtsNNAPITestCases présente un problème connu en raison de la limitation des arguments sous 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 aux tests échoue derrière un pare-feu d'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 lors de l'exécution. Dans de nombreux environnements d'entreprise, un pare-feu et un proxy sont généralement utilisés, 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 les CTS pour Secure Element ?

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

  • Si votre appareil N'A PAS besoin de prendre en charge les applications Android qui accèdent aux éléments sécurisés (dans l'UICC, par exemple une carte SIM, distribuée par les opérateurs de réseau mobile 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() renvoie une liste vide, et le test CTS est automatiquement réussi.
  • Si votre appareil DOIT être compatible avec les applications Android qui accèdent à des éléments sécurisés (dans l'UICC, par exemple une carte SIM, distribuée par les opérateurs de réseau mobile ou intégrée à l'appareil), vous devez implémenter correctement l'élément sécurisé et le tester en interne. CTS Test for Secure Element explique comment se préparer à exécuter les tests CTS qui garantissent le bon fonctionnement du package d'API android.se.omapi ajouté dans Android 9. 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 Secure Element ?

Vous pouvez contacter le fournisseur de carte SIM de votre choix.

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

Le cas de test ne démarre pas, car le test de la carte SIM est verrouillé. 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 partage de jetons.