Développement CTS

Initialisez votre client Repo

Suivez les instructions de Téléchargement de la source pour obtenir et créer le code source Android. Lors de l'exécution de la commande repo init , spécifiez une branche CTS spécifique à l'aide -b . Cela garantit que vos modifications CTS sont incluses dans les versions CTS ultérieures.

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

Créer et exécuter CTS

Exécutez les commandes suivantes pour créer CTS et démarrer la console CTS interactive :

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 le didacticiel Testez votre application et les tests existants dans le répertoire cts/tests . Les tests CTS suivent pour la plupart les mêmes conventions que celles utilisées dans d'autres tests Android.

CTS s'exécute 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 les méthodes API publiques. En d’autres termes, évitez toutes les classes, méthodes et champs avec l’annotation hide .
• Évitez d'utiliser des dispositions de vue ou de vous fier aux dimensions des ressources qui peuvent ne pas se trouver sur certains appareils.
• Ne comptez pas sur les privilèges root.

Ajouter une annotation Java

Si votre test vérifie un comportement d'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 exemples suivants :

Si votre test vérifie une exigence CDD, annotez l'ID de l'exigence (y compris l'ID de section CDD et l'ID de l'exigence) avec @CddTest dans le code de test CTS, comme indiqué dans l'exemple suivant. Dans votre message de validation, mentionnez quelle exigence CDD est testée par votre test en vous référant aux ID d'exigence CDD. Les ID d’exigence CDD sont une combinaison d’ID de section et d’ID d’exigence, relié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é dans votre AndroidManifest.xml avec l'ID CDD approprié. Les formats des champs de valeur sont similaires aux formats des annotations Java dans CTS. Dans le message de validation, mentionnez quelle exigence CDD est appliquée en faisant référence à l’ID de l’exigence CDD.

  <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 validation

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

Créer un sous-plan

À titre d'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 :

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" />

Dénomination et emplacement du test

La plupart des cas de test CTS ciblent une classe spécifique dans l'API Android. Ces tests ont des noms de packages Java avec un suffixe cts et des noms de classe avec un suffixe Test . Chaque scénario de test se compose de plusieurs tests, chaque test mettant généralement en œuvre une méthode spécifique de la classe testée. Ces tests sont organisés dans une structure de répertoires où les tests sont regroupés en différentes catégories telles que « widgets » ou « vues ».

Par exemple, le test CTS pour le package Java android.widget.TextView est android.widget.cts.TextViewTest avec son nom de package Java comme android.widget.cts et son nom de classe comme TextViewTest .

• Nom du package Java
  Le nom du package Java pour les tests CTS est le nom du package de la classe que le test teste, suivi de .cts . Pour notre exemple, le nom du package serait android.widget.cts .
• Nom du cours
  Le nom de 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 des répertoires et l'exemple de code dépendent de si vous utilisez CTS v1 ou CTS v2.

CTS v1

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

La structure des répertoires dans les tests CTS v1 ressemble à ceci :

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 plus de détails, consultez l’exemple de test dans Android Open Source Project (AOSP) .

La structure du répertoire CTS v2 ressemble à ceci :

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

Nouveaux packages d’échantillons

Lors de l'ajout de nouveaux tests, il se peut qu'il n'y ait pas de répertoire existant pour placer votre test. Dans ces cas, vous devez créer le répertoire et copier les exemples de fichiers appropriés.

CTS v1

Si vous utilisez CTS v1, reportez-vous à l'exemple sous cts/tests/tests/example et créez un nouveau répertoire. Assurez-vous également d'ajouter le nom du module de votre nouveau package depuis son Android.mk à CTS_COVERAGE_TEST_CASE_LIST dans cts/CtsTestCaseList.mk . build/core/tasks/cts.mk utilise ce makefile pour combiner tous les tests et créer le package CTS final.

CTS v2

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

1. Pour créer le répertoire de test et copier des exemples de fichiers, exécutez :

   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 « [Ss]ample » par la convention de dénomination recommandée ci-dessus.
3. Mettez à jour SampleDeviceActivity pour exercer la fonctionnalité que vous testez.
4. Mettez à jour SampleDeviceTest pour garantir que l’activité réussit ou enregistre ses erreurs.

Répertoires supplémentaires

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

Le 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 du projet pour construire 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 supprimer les tests annotés avec BrokenTest ou KnownFailure .

Soumettez vos 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, développez d'abord un correctif dans aosp/main , puis sélectionnez la branche de test la plus en amont . Autorisez la fusion automatique à fusionner les modifications en aval dans les branches de test AOSP. Voir Calendrier de publication et informations sur les branches pour obtenir la liste des branches et les informations sur le chemin de fusion automatique.
• Pour les modifications spécifiques à un niveau d'API spécifique, développez ou sélectionnez les modifications apportées à la branche de test appropriée avec DO NOT MERGE ou RESTRICT AUTOMERGE dans le message de validation.

Suivez le workflow Soumission de correctifs pour apporter des modifications à CTS. Un réviseur sera désigné pour examiner votre modification en conséquence.

Calendrier de publication et informations sur les succursales

Les versions CTS suivent ce calendrier.

Dates importantes lors de la sortie

• Fin de la première semaine : Gel du code. Les modifications fusionnées dans la branche jusqu'au gel du code sont prises en compte pour la prochaine version de CTS. Les soumissions à la branche après le gel du code ou après le choix d'un candidat à la publication sont prises en compte pour la version ultérieure.
• Deuxième ou troisième semaine : CTS est publié dans AOSP .

Flux de fusion automatique

Les branches de développement CTS ont été configurées de manière à ce que les modifications soumises à chaque branche fusionnent automatiquement vers les branches supérieures.

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

Pour les modifications apportées uniquement à la prochaine version d'Android, le chemin de fusion automatique est :
aosp/main > <Internal git/main> .

Si une liste de modifications (CL) ne parvient pas à fusionner correctement, l'auteur du correctif reçoit 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 ignorer la fusion automatique du CL en conflit.

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