Développement CTS

Initialiser le client de dépôt

Suivez les instructions de l'article Télécharger la source pour obtenir et compiler le code source Android. Lorsque vous exécutez la commande repo init, spécifiez une branche CTS spécifique à l'aide de -b. Cela garantit que vos modifications CTS sont incluses dans les versions ultérieures de CTS.

L'exemple de code suivant montre comment utiliser repo init.

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

Créer et exécuter CTS

Exécutez les commandes suivantes pour créer CTS et démarrer l'interface interactive Console CTS:

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Dans la console CTS, saisissez:

tf> run cts --plan CTS

Écrire des tests CTS

Les tests CTS utilisent JUnit et les API de test Android. Consultez les Tester votre application tutoriel et tests existants dans le répertoire cts/tests. Les tests CTS suivent principalement les mêmes conventions que celles utilisées dans les autres tests Android.

CTS fonctionne sur de nombreux appareils de production. Les tests doivent donc suivre ces règles:

  • Tenez compte des différentes tailles d'écran, orientations et dispositions de clavier.
  • Utilisez uniquement des méthodes d'API publiques. En d'autres termes, évitez toutes les classes, méthodes et champs avec l'annotation hide.
  • Évitez d'utiliser des mises en page de vue ou de vous fier aux dimensions d'éléments qui ne figurent peut-être pas sur certains appareils.
  • Ne vous fiez pas aux privilèges racine.

Ajouter une annotation Java

Si votre test vérifie le comportement d'une API, annotez votre code de test avec @ApiTest et répertoriez toutes les API impliquées dans le champ apis. Utilisez le format approprié parmi les les exemples suivants:

Type d'API Format des annotations Notes
Méthode android.example.ClassA#methodA Cas d'utilisation le plus courant.
Méthode avec clé-valeurs android.example.ClassB#methodB(KeyA) À n'utiliser que lorsque votre test utilise une méthode API pour valider un champ, comme dans cet exemple.
Champ android.example.ClassC#FieldA À n'utiliser que lorsque votre test valide directement un champ d'API, comme dans cet exemple.

Si votre test vérifie une exigence du CDD, annotez l'ID de l'exigence (y compris la section CDD) et l'ID de la demande) avec @CddTest dans le code de test CTS, comme indiqué dans les dans l'exemple suivant. Dans votre message de commit, indiquez l'exigence CDD testée par votre test en se référant aux ID des exigences du CDD. Les identifiants des exigences liées au CDD sont une combinaison d'ID de section et l'identifiant de l'exigence, connectés par une barre oblique (/), comme dans 7.3.1/C-1-1. 


/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

Pour CTS Verifier, annotez chaque activité de votre AndroidManifest.xml avec le ID de CDD approprié. Les formats des champs de valeur sont similaires aux formats des annotations Java CTS. Dans le message de commit, indiquez l'exigence CDD appliquée en référençant le CDD. ID de condition. 


  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

Dans le message de commit

Expliquez clairement pourquoi votre test doit être ajouté et ajoutez des liens pertinents pour obtenir de l'aide. Pour CTS-D de test, incluez un lien vers la proposition test que vous avez créée dans Google Issue Tracker dans le cadre le processus d'envoi CTS-D.

Créer un sous-plan

Par exemple, vous pouvez ajouter un fichier SubPlan.xml dans android-cts/subplans comme suit:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

Pour exécuter le sous-plan:

run cts --subplan aSubPlan

Le format de saisie du sous-plan est le suivant:

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

Nom et emplacement du test

La plupart des scénarios de test CTS ciblent une classe spécifique dans l'API Android. Ces tests comportent des noms de packages Java avec le suffixe cts et des noms de classe avec un suffixe Suffixe Test. Chaque scénario comprend plusieurs tests, où chacun test exerce généralement une méthode spécifique de la classe testée. Ces tests sont organisés dans une structure de répertoires dans laquelle ils sont regroupés des catégories différentes, comme les "widgets", ou "vues".

Par exemple, le test CTS du package Java android.widget.TextView correspond à android.widget.cts.TextViewTest par son nom de package Java comme android.widget.cts et son nom de classe en tant que TextViewTest

  • Nom du package Java
    Nom du package Java pour les tests CTS est le nom du package de la classe testée, suivi de .cts Dans notre exemple, le nom du package serait android.widget.cts
  • Nom de la classe
    Le nom de la classe pour les tests CTS est le nom de la classe testée avec "Test" ajouté. Par exemple, si un test cible TextView, le nom de la classe doit être TextViewTest.
  • Nom du module (CTS v2 uniquement)
    CTS v2 organise les tests par module. Le nom du module est généralement la deuxième chaîne du nom du package Java (dans notre Exemple : widget).

La structure du répertoire et l'exemple de code varient selon que vous utilisez CTS v1 ou non. ou CTS v2.

CTS v1

Pour Android 6.0 ou version antérieure, utilisez la version 1 du CTS. Pour CTS v1, l'exemple de code se trouve à l'adresse cts/tests/tests/example

La structure de répertoires dans les tests CTS v1 se présente comme suit: 

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

CTS v2

Pour Android 7.0 ou version ultérieure, utilisez CTS v2. Pour en savoir plus, consultez les exemple de test dans le projet Android Open Source (AOSP).

La structure de répertoires CTS v2 se présente comme suit: 

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

Nouveaux exemples de packages

Lorsque vous ajoutez de nouveaux tests, il est possible qu'il n'y ait pas de répertoire existant pour placer votre test. Dans ce cas, vous devez créer le répertoire et copier les exemples de fichiers appropriés.

CTS v1

Si vous utilisez la version 1 de CTS, consultez l'exemple sous cts/tests/tests/example et créez un répertoire. Par ailleurs, veillez à ajouter le nom du module de votre nouveau package à partir de son Android.mk à CTS_COVERAGE_TEST_CASE_LIST dans cts/CtsTestCaseList.mk build/core/tasks/cts.mk utilise ce fichier makefile pour combiner tous les tests et créer le package CTS final.

CTS v2

Utiliser l'exemple de test /cts/tests/sample/ pour lancer rapidement votre nouveau module de test en procédant comme suit:

  1. Pour créer le répertoire de test et copier les exemples de fichiers, exécutez la commande suivante: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Accédez à cts/tests/module-name et remplacez toutes les instances de "[Échantillon]" avec le convention d'attribution de noms recommandée ci-dessus.
  3. Mettez à jour SampleDeviceActivity pour utiliser la fonctionnalité que vous testez.
  4. Mettez à jour SampleDeviceTest pour vous assurer que l'activité réussit ou journalise et ses erreurs.

Annuaires supplémentaires

D'autres répertoires Android tels que assets, jni, Vous pouvez également ajouter libs et res. Pour ajouter du code JNI, créez un répertoire à la racine du projet à côté de src avec le fichier du code et un fichier makefile Android.mk.

Le fichier makefile contient généralement les paramètres suivants: 

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni

# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)

# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)

Fichier Android.mk

Enfin, modifiez le fichier Android.mk à la racine de pour créer le code natif et en dépendre, comme indiqué ci-dessous:

# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner

# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni

# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)

#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))

Corriger ou supprimer des tests

En plus d'ajouter de nouveaux tests, vous pouvez corriger ou Supprimez les tests annotés avec BrokenTest ou KnownFailure.

Valider les modifications

Lorsque vous soumettez des correctifs CTS ou VTS dans AOSP, choisissez votre branche de développement en fonction des niveaux d'API auxquels le correctif s'applique.

  • Pour les modifications qui s'appliquent à plusieurs niveaux d'API, commencez par développer un correctif dans aosp/main, puis sélectionner le plus branche de test en amont. Autoriser la fusion automatique à fusionner les modifications en aval Branches de test AOSP. Voir Calendrier des mises à jour et informations sur les branches pour obtenir la liste des branches et de fusionner automatiquement les informations sur les chemins d'accès.
  • Pour les modifications spécifiques à un niveau d'API spécifique, développez ou sélectionnez les modifications apportées à la branche de test correcte avec NE PAS FUSIONNER ou RESTRICT AUTOMERGE dans le message de commit.

Suivez le workflow d'envoi de correctifs. pour contribuer aux modifications de CTS. Un examinateur sera chargé d'examiner votre modification en conséquence.

Calendrier des lancements et informations sur les agences

Les versions CTS suivent ce calendrier.

Version Niveau d'API Branch Fréquence
15 35 développeur-tests-android15 Tous les trimestres
14 34 développeur-tests-android14 Tous les trimestres
13 33 développeur-tests-android13 Tous les trimestres
12L 32 android12L-tests-dev Tous les trimestres
12 31 développeur-tests-android12 Tous les trimestres

Dates importantes de la sortie

  • Fin de la première semaine:gel de code. Modifications fusionnées dans la branche jusqu'à ce que le gel du code soit pris en compte pour la prochaine version de CTS. Les envois à la branche après le gel du code ou après un candidat pour est choisi, sont pris en compte pour la version suivante.
  • Deuxième ou troisième semaine:CTS est publié en AOSP :

Fusionner automatiquement le flux

Les branches de développement CTS ont été configurées de sorte que les modifications fusionne automatiquement avec les branches supérieures.

Pour les modifications directement apportées à une branche de développement de test AOSP, le chemin de fusion automatique est le suivant:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Pour les modifications apportées uniquement à la version suivante d'Android, le chemin de fusion automatique est le suivant:
aosp-main > <Internal git_main>

Si la fusion d'une liste de modifications (CL) échoue, l'auteur du correctif est envoyé. un e-mail contenant des instructions sur la façon de résoudre le conflit. Dans la plupart des cas, l'auteur du correctif peut utiliser les instructions pour éviter la fusion automatique la CL en conflit.

Si une branche plus ancienne nécessite la modification, le correctif doit être sélectionnés dans la branche la plus récente.