Questions fréquentes sur CTS

Le programme de compatibilité Android est le principal moteur de la satisfaction des utilisateurs de l'écosystème Android. 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 a permis 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 CTS.

Quels types d'éléments sont testés par CTS ?

CTS teste que toutes les API Android fortement typées compatibles sont présentes et se comportent correctement. CTS teste également d'autres comportements du système non liés aux API, tels que le cycle de vie et les performances des applications.

Comment la licence CTS est-elle gérée ?

CTS est sous licence Apache Software License 2.0, comme 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 réponses aux questions fréquentes qui vous aideront à exécuter les tests CTS plus efficacement.

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

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

Le partitionnement TF attribue dynamiquement des scénarios de test aux appareils testés disponibles comme suit :

Qu'attend-on 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. 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. Chacune d'elles peut prendre en charge le mode 32 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.

Consultez la section 3.3.1 du CDD. Interfaces binaires d'application pour les exigences du CDD concernant l'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 s'exécute sur ses propres environnements d'exécution 32 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 autant de scénarios de test sont-ils signalés comme "Non exécutés" ?

Vous devez vérifier le nombre de modules terminés plutôt que le nombre de modules non exécutés.

Dans les versions précédentes, les modules CTS étaient signalés comme terminés de manière trop agressive avant d'être terminés. Par conséquent, un nombre de modules terminés était 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 nombre plus élevé de tests non exécutés en cas de problème.

Un module exécuté jusqu'à la fin signale Module non terminé dans l'invocation la plus récente (done="false") du rapport lors des opérations suivantes :

  • L'exécution d'un test pour le module a été interrompue par un problème de connexion de l'appareil.
  • Toutes les 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
    • --exclude-filter
    • -t/--test (option non encore compatible avec la nouvelle tentative)
    • --retry-type failed
    • --subplan

Pour obtenir l'état Module terminé (done="true") pour ces modules, réessayez les éléments suivants pour l'invocation la plus récente :

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é comme Module terminé dans le nouveau rapport.

Exceptions

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

Comment éviter l'échec de la préparation des tests 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 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 for Secure Element ?

La nécessité d'une carte SIM pour le test dépend de la compréhension de la compatibilité de la fonctionnalité 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 (dans l' UICC , par exemple une carte SIM) distribués par les opérateurs de réseau mobile (opérateurs) ou intégrés à l'appareil, vous pouvez configurer le fichier 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 CTS.
  • Si votre appareil DOIT prendre en charge les applications Android accédant à des composants sécurisés (dans la UICC , par exemple une carte SIM) distribués par les opérateurs de réseau mobile (opérateurs) ou intégrés à l'appareil, vous devez implémenter correctement le composant sécurisé et le tester en interne. La section Test CTS for Secure Element explique comment vous 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, car la couverture des tests CTS est minimale.

Où puis-je obtenir les cartes SIM pour CTS for Secure Element ?

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

Pourquoi la carte SIM Orange s'affiche-t-elle sur l'écran de verrouillage lors de l'exécution de CTS avec le partitionnement de 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 d' exécuter CTS avec le partitionnement de jetons.

Exécution des tests lorsque les indicateurs de fonctionnalité sont désactivés sur l'appareil

Pour tous les indicateurs des builds de version, l'annotation @RequiresFlagsEnabled ou @RequiresFlagsDisabled utilise les valeurs des indicateurs de la configuration de la version binaire CTS, et non de la configuration de la version de l'appareil. La désactivation des indicateurs sur l'appareil ne désactive pas le test, car l'ensemble des tests CTS exécutés pour une version donnée est fixé à la configuration publiée sur la plate-forme AOSP.