Sviluppo CTS

Inizializza il client Repo

Segui le istruzioni riportate in Download del codice sorgente per ottenere e creare il codice sorgente di Android. Quando esegui il comando repo init, specifica un ramo CTS specifico utilizzando -b. In questo modo, le modifiche al CTS vengono incluse nelle versioni successive del CTS.

Il seguente codice di esempio mostra come utilizzare 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

Crea ed esegui CTS

Esegui questi comandi per creare CTS e avviare la console CTS interattiva:

CTS della build (AOSP 14 o versioni precedenti)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

CTS della build (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

Per selezionare il valore di target-release, consulta la tabella seguente:

Branch Versione di destinazione
android15-tests-dev ap3a

Esegui CTS

Nella console CTS, inserisci:

tf> run cts --plan CTS

Scrivere test CTS

I test CTS utilizzano JUnit e le API di test Android. Consulta il tutorial Testa la tua app e i test esistenti nella directory cts/tests. I test CTS seguono per lo più le stesse convenzioni utilizzate in altri test Android.

CTS viene eseguito su molti dispositivi di produzione, pertanto i test devono seguire queste regole:

  • Tieni conto delle diverse dimensioni dello schermo, orientamenti e layout della tastiera.
  • Utilizza solo i metodi API pubblici. In altre parole, evita tutte le classi, i metodi e i campi con l'annotazione hide.
  • Evita di utilizzare layout di visualizzazione o di fare affidamento sulle dimensioni di asset che potrebbero non essere presenti su alcuni dispositivi.
  • Non fare affidamento sui privilegi di root.

Aggiungere un'annotazione Java

Se il test verifica il comportamento di un'API, annota il codice di test con @ApiTest ed elenca tutte le API coinvolte nel campo apis. Utilizza il formato appropriato tra i seguenti esempi:

Tipo di API Formato delle annotazioni Note
Metodo android.example.ClassA#methodA Il caso d'uso più comune.
Metodo con chiavi-valore android.example.ClassB#methodB(KeyA) Utilizza questa opzione solo quando il test utilizza un metodo API per convalidare un campo, come in questo esempio.
Campo android.example.ClassC#FieldA Utilizza questo valore solo quando il test convalida direttamente un campo API, come in questo esempio.

Se il test verifica un requisito CDD, annota l'ID requisito (inclusi ID sezione CDD e ID requisito) con @CddTest nel codice di test CTS come mostrato nell'esempio seguente. Nel messaggio di commit, indica quale requisito CDD viene testato dal tuo test facendo riferimento agli ID requisito CDD. Gli ID requisito CDD sono una combinazione di ID sezione e ID requisito, collegati da una barra (/) come in 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()));
    }

Per CTS Verifier, annota ogni attività nel tuo AndroidManifest.xml con l'ID CDD pertinente. I formati per i campi valore sono simili ai formati delle annotazioni Java in CTS. Nel messaggio di commit, indica quale requisito CDD viene applicato facendo riferimento all'ID requisito 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>

Nel messaggio di commit

Indica chiaramente il motivo per cui è necessario aggiungere il test e aggiungi link pertinenti per l'assistenza. Per i test CTS-D, includi un link alla proposta di test che hai creato in Google Issue Tracker nell'ambito del processo di invio di CTS-D.

Creare un subpiano

Ad esempio, puoi aggiungere un file SubPlan.xml in android-cts/subplans nel seguente modo:

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

Per eseguire il piano secondario:

run cts --subplan aSubPlan

Il formato della voce del piano secondario è:

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

Testare la denominazione e la posizione

La maggior parte degli scenari di test CTS ha come target una classe specifica nell'API Android. Questi test hanno nomi di pacchetti Java con un suffisso cts e nomi di classi con un suffisso Test. Ogni scenario di test è costituito da più test, ognuno dei quali in genere esercita un metodo specifico della classe in fase di test. Questi test sono organizzati in una struttura di directory in cui sono raggruppati in diverse categorie, ad esempio "widget" o "visualizzazioni".

Ad esempio, il test CTS per il pacchetto Java android.widget.TextView è android.widget.cts.TextViewTest con il nome del pacchetto Java android.widget.cts e il nome della classe TextViewTest.

  • Nome del pacchetto Java
    Il nome del pacchetto Java per i test CTS è il nome del pacchetto della classe che il test sta testando, seguito da .cts. Per il nostro esempio, il nome del pacchetto sarà android.widget.cts.
  • Nome classe
    Il nome della classe per i test CTS è il nome della classe in fase di test con l'aggiunta di "Test". Ad esempio, se un test ha come target TextView, il nome della classe deve essere TextViewTest.
  • Nome modulo (solo CTS v2)
    CTS v2 organizza i test per modulo. Il nome del modulo è in genere la seconda stringa del nome del pacchetto Java (nel nostro esempio, widget).

La struttura delle directory e il codice di esempio dipendono dall'utilizzo di CTS v1 o CTS v2.

CTS v1

Per Android 6.0 o versioni precedenti, utilizza CTS v1. Per CTS v1, il codice di esempio si trova in cts/tests/tests/example.

La struttura delle directory nei test CTS v1 è la seguente: 

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

CTS v2

Per Android 7.0 o versioni successive, utilizza CTS v2. Per maggiori dettagli, vedi il test di esempio in Android Open Source Project (AOSP).

La struttura di directory di CTS v2 ha il seguente aspetto: 

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

Nuovi pacchetti di esempio

Quando aggiungi nuovi test, potrebbe non esistere una directory in cui inserire il test. In questi casi, devi creare la directory e copiare i file di esempio appropriati.

CTS v1

Se utilizzi CTS v1, fai riferimento all'esempio riportato in cts/tests/tests/example e crea una nuova directory. Inoltre, assicurati di aggiungere il nome del modulo del nuovo pacchetto da Android.mk a CTS_COVERAGE_TEST_CASE_LIST in cts/CtsTestCaseList.mk. build/core/tasks/cts.mk utilizza questo makefile per combinare tutti i test e creare il pacchetto CTS finale.

CTS v2

Utilizza il test di esempio /cts/tests/sample/ per avviare rapidamente il nuovo modulo di test con i seguenti passaggi:

  1. Per creare la directory di test e copiare i file di esempio, esegui: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Vai a cts/tests/module-name e sostituisci tutte le istanze di "[Ss]ample" con la convenzione di denominazione consigliata riportata sopra.
  3. Aggiorna SampleDeviceActivity per utilizzare la funzionalità che stai testando.
  4. Aggiorna SampleDeviceTest per assicurarti che l'attività vada a buon fine o registri i suoi errori.

Directory aggiuntive

È possibile aggiungere anche altre directory Android come assets, jni, libs e res. Per aggiungere codice JNI, crea una directory nella radice del progetto accanto a src con il codice nativo e un makefile Android.mk.

Il makefile in genere contiene le seguenti impostazioni: 

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)

File Android.mk

Infine, modifica il file Android.mk nella root del progetto per creare il codice nativo e dipendere da esso, come mostrato di seguito:

# 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))

Correggere o rimuovere i test

Oltre ad aggiungere nuovi test, puoi correggere o rimuovere i test annotati con BrokenTest o KnownFailure.

Invia le modifiche

Segui il flusso di lavoro Invio delle modifiche al codice quando contribuisci con modifiche a CTS.

  • Scegli il ramo di sviluppo in base ai livelli API a cui si applica la patch.
  • Sviluppa o seleziona le modifiche al ramo di test corretto con DO NOT MERGE o RESTRICT AUTOMERGE nel messaggio di commit.

Un revisore viene assegnato per esaminare la modifica e selezionarla nel Gerrit interno di conseguenza.

Pianificazione delle release e informazioni sui rami

I rilasci di CTS seguono questa pianificazione.

Versione Livello API Branch di sviluppo Frequenza di rilascio
16+ 36+ Internal gerrit Trimestrale
15 35 android15-tests-dev Trimestrale
14 34 android14-tests-dev Trimestrale
13 33 android13-tests-dev Trimestrale

Date importanti durante il lancio

  • Fine della prima settimana:blocco del codice. Le modifiche unite nel ramo fino al blocco del codice vengono prese in considerazione per la prossima versione di CTS. Gli invii al ramo dopo il blocco del codice o dopo la scelta di un candidato per il rilascio vengono presi in considerazione per la release successiva.
  • Seconda o terza settimana: la CTS viene pubblicata nella pagina Download della suite di test di compatibilità.

Flusso di unione automatica

Sono stati configurati rami di sviluppo CTS in modo che le modifiche inviate a ogni ramo vengano unite automaticamente ai rami di livello superiore.

Per le modifiche direttamente a un ramo di sviluppo dei test AOSP, il percorso di unione automatica è:
android13-tests-dev > android14-tests-dev > android15-tests-dev

  • Per le versioni CTS 16 e successive, un revisore selezionerà la modifica nel Gerrit interno di conseguenza.

Se un elenco modifiche (CL) non viene unito correttamente, all'autore della patch viene inviata un'email con le istruzioni su come risolvere il conflitto. Nella maggior parte dei casi, l'autore della patch può utilizzare le istruzioni per ignorare l'unione automatica della CL in conflitto.

Se un ramo precedente richiede la modifica, la patch deve essere estratta dal ramo più recente.

Per le modifiche di test applicabili alla prossima versione di Android, dopo aver caricato una modifica proposta, Google la esamina e, se accettata, la seleziona in Gerrit interno.