Questions fréquentes sur CTS

Programme de compatibilité Android est le principal moteur de l'échange de 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. Le modèle l'ajout de scénarios de test a permis d'améliorer de manière significative appareils compatibles.

Questions générales

Cette section fournit des questions fréquentes générales sur CTS.

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

La CTS vérifie que toutes les API Android de type fort compatibles sont présents et se comportent correctement. Le CTS teste également d'autres systèmes non-API tels que le cycle de vie et les performances de l'application.

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 CTS ?

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

Questions spécifiques aux tests

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

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

Le fractionnement CTS et le fractionnement TF sont des plans de test totalement différents, basés sur des codebases d'infrastructure de test différents. 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 appareils testés 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 à l'appui. Il est donc nécessaire d'exécuter une application des ABI spécifiques. Vous trouverez ci-dessous les consignes concernant plusieurs ABI:

  • Pour CTS et CTS Verifier, il existe des versions ARM et x86 pour chaque architecture. Chacun d'eux est compatible avec le mode 32 ou 64 bits.
  • Pour les tests CTS, si un appareil est compatible à la fois avec ARM et x86, il doit s'exécuter et réussissent respectivement les tests ARM et x86 CTS.

Voir 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 agressivement avant d'être terminés. Par conséquent, le nombre de Modules terminés a été signalé sans que le scénario de test ne soit terminé, même lorsque certains appareils ont rencontré des problèmes. Le nouveau système de test est plus conservateur un plus grand nombre 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 :

  • L'exécution d'un test du module a été interrompue en raison d'un problème de connexion d'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, par exemple :

    • --inclure-filtre
    • --exclude-filter
    • -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 (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 d'une limitation d'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 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 le pare-feu et le proxy sont courants, ce qui entraîne l'échec de la préparation du test. Exécuter la ligne suivante ou ajoutez-le à .profile (sous 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 n'a PAS besoin de prendre en charge les applications Android accédant des éléments sécurisés, que ce soit UICC (par exemple, une carte SIM) distribué par les opérateurs de réseau mobile. (opérateurs) ou intégré à l'appareil, vous pouvez configurer le HIDL manifeste pour ne pas inclure l'HAL android.hardware.secure_element . Dans ce cas, android.se.omapi.SEService.getReaders() L'API signale une liste vide et le test CTS est automatique et signale une carte pour la CTS.
  • Si votre appareil DOIT être compatible avec les applications Android qui accèdent à l'un des les é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). Intégré dans l'appareil : vous devez implémenter correctement le composant sécurisé et la tester en interne. Test CTS pour l'élément 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 effectuer des tests supplémentaires par vous-même depuis la couverture du test CTS est minime.

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

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

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

Le scénario 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 le l'exécution du CTS avec la segmentation de jetons.