Inizializza il tuo client Repo
Segui le istruzioni in Download del codice sorgente per ottenere e creare il codice sorgente Android. Quando si esegue il comando repo init
, specificare un ramo CTS specifico utilizzando -b
. Ciò garantisce che le modifiche CTS siano incluse nelle successive versioni CTS.
Il codice di esempio seguente 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
Costruisci ed esegui CTS
Esegui i seguenti comandi per creare CTS e avviare la console CTS interattiva:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
Nella console CTS, inserisci:
tf> run cts --plan CTS
Scrivi test CTS
I test CTS utilizzano JUnit e le API di test Android. Consulta l'esercitazione 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, quindi i test devono seguire queste regole:
- Prendi in considerazione le diverse dimensioni dello schermo, gli orientamenti e i layout della tastiera.
- Utilizza solo 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 delle risorse che potrebbero non essere presenti su alcuni dispositivi.
- Non fare affidamento sui privilegi di root.
Aggiungi annotazione Java
Se il tuo test verifica il comportamento di un'API, annota il codice del test con @ApiTest
ed elenca tutte le API coinvolte nel campo apis
. Utilizzare il formato appropriato tra i seguenti esempi:
Tipo di API | Formato dell'annotazione | Appunti |
---|---|---|
Metodo | android.example.ClassA#methodA | Il caso d'uso più comune. |
Metodo con valori chiave | android.example.ClassB#methodB(KeyA) | Utilizzalo solo quando il test utilizza un metodo API per convalidare un campo, come in questo esempio. |
Campo | android.esempio.ClassC#FieldA | Utilizzalo 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 l'ID sezione CDD e l'ID requisito) con @CddTest
nel codice del test CTS come mostrato nell'esempio seguente. Nel messaggio di commit, menziona quale requisito CDD viene testato dal test facendo riferimento agli ID dei requisiti CDD. Gli ID dei requisiti CDD sono una combinazione dell'ID della sezione e dell'ID del 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 il relativo ID CDD. I formati per i campi valore sono simili ai formati delle annotazioni Java in CTS. Nel messaggio di commit, menziona quale requisito CDD viene applicato facendo riferimento all'ID del 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 collegamenti pertinenti per il supporto. Per i test CTS-D, includi un link alla proposta di test che hai creato in Google Issue Tracker come parte del processo di invio CTS-D .
Creare un sottopiano
Ad esempio, puoi aggiungere un file SubPlan.xml in android-cts/subplans
come segue:
<?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 sottopiano:
run cts --subplan aSubPlan
Il formato di immissione del sottopiano è:
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" />
Prova la denominazione e la posizione
La maggior parte dei casi di test CTS hanno come target una classe specifica nell'API Android. Questi test hanno nomi di pacchetti Java con suffisso cts
e nomi di classi con suffisso Test
. Ogni caso di test è costituito da più test, dove ogni test tipicamente esercita un metodo specifico della classe da testare. Questi test sono organizzati in una struttura di directory in cui i test sono raggruppati in diverse categorie come "widget" o "viste".
Ad esempio, il test CTS per il pacchetto Java android.widget.TextView
è android.widget.cts.TextViewTest
con il nome del pacchetto Java come android.widget.cts
e il nome della classe come 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 sarebbeandroid.widget.cts
. - Nome della classe
Il nome della classe per i test CTS è il nome della classe da testare con l'aggiunta di "Test". Ad esempio, se un test ha come targetTextView
, il nome della classe dovrebbe essereTextViewTest
. - Nome del modulo (solo CTS v2)
CTS v2 organizza i test per modulo. Il nome del modulo è solitamente la seconda stringa del nome del pacchetto Java (nel nostro esempio,widget
).
La struttura della directory e il codice di esempio dipendono da se si utilizza CTS v1 o CTS v2.
CTS v1
Per Android 6.0 o versioni precedenti, utilizzare CTS v1. Per CTS v1, il codice di esempio si trova in cts/tests/tests/example
.
La struttura delle directory nei test CTS v1 è simile alla 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, utilizzare CTS v2. Per maggiori dettagli, consulta il test di esempio in Android Open Source Project (AOSP) .
La struttura della directory CTS v2 è simile alla seguente:
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
Nuovi pacchetti campione
Quando aggiungi nuovi test, potrebbe non esserci una directory esistente in cui posizionare il test. In questi casi, è necessario creare la directory e copiare i file di esempio appropriati.
CTS v1
Se utilizzi CTS v1, fai riferimento all'esempio in cts/tests/tests/example
e crea una nuova directory. Inoltre, assicurati di aggiungere il nome del modulo del tuo 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 tuo nuovo modulo di test con i seguenti passaggi:
- Per creare la directory di test e copiare i file di esempio, eseguire:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- Passare a
cts/tests/ module-name
e sostituire tutte le istanze di "[Ss]ample" con la convenzione di denominazione consigliata sopra. - Aggiorna
SampleDeviceActivity
per esercitare la funzionalità che stai testando. - Aggiorna
SampleDeviceTest
per garantire che l'attività abbia esito positivo o registri gli 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
al suo interno.
Il makefile contiene in genere 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))
Correggi o rimuovi i test
Oltre ad aggiungere nuovi test, puoi correggere o rimuovere test annotati con BrokenTest
o KnownFailure
.
Invia le tue modifiche
Quando invii patch CTS o VTS in AOSP, scegli il ramo di sviluppo in base ai livelli API a cui si applica la patch.
- Per le modifiche che si applicano a più livelli API, sviluppa prima una patch in
aosp/main
e poi seleziona il ramo di test più a monte . Consentire alla fusione automatica di unire le modifiche a valle nei rami di test AOSP. Vedere Pianificazione del rilascio e informazioni sui rami per l'elenco dei rami e le informazioni sul percorso di unione automatica. - Per modifiche specifiche a un livello API specifico, sviluppa o seleziona le modifiche al ramo di test corretto con DO NOT MERGE o RESTRICT AUTOMERGE nel messaggio di commit.
Segui il flusso di lavoro di invio delle patch per apportare modifiche a CTS. Verrà assegnato un revisore per esaminare la modifica di conseguenza.
Programma di rilascio e informazioni sulle filiali
I rilasci CTS seguono questo programma.
Versione | Livello API | Ramo | Frequenza |
---|---|---|---|
14 | 34 | android14-test-dev | Trimestrale |
13 | 33 | android13-test-dev | Trimestrale |
12 litri | 32 | android12L-test-dev | Trimestrale |
12 | 31 | android12-test-dev | Trimestrale |
11 | 30 | android11-test-dev | Trimestrale |
Non sono previste ulteriori versioni per le versioni 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 e 4.2. |
Date importanti durante il rilascio
- Fine della prima settimana: congelamento del codice. Le modifiche unite nel ramo fino al congelamento del codice verranno prese in considerazione per la prossima versione di CTS. Gli invii alla filiale dopo il congelamento del codice, o dopo la scelta di un candidato per il rilascio, vengono presi in considerazione per il rilascio successivo.
- Seconda o terza settimana: pubblicazione del CTS in AOSP .
Flusso di unione automatica
I rami di sviluppo CTS sono stati impostati in modo tale che le modifiche inviate a ciascun ramo si uniscano automaticamente ai rami superiori.
Per le modifiche direttamente a un ramo di sviluppo test AOSP, il percorso di unione automatica è:
android11-tests-dev
> android12-tests-dev
android12L-tests-dev
> android13-tests-dev
> android14-tests-dev
> aosp/main
Per le modifiche solo alla successiva versione di Android, il percorso di automerge è:
aosp/main
> <Internal git/main>
.
Se un elenco di modifiche (CL) non viene unito correttamente, all'autore della patch viene inviata un'e-mail con le istruzioni su come risolvere il conflitto. Nella maggior parte dei casi, l'autore della patch può utilizzare le istruzioni per saltare l'unione automatica della CL in conflitto.
Se un ramo più vecchio richiede la modifica, è necessario scegliere la patch dal ramo più recente.