Inizializza il client repository
Segui le istruzioni di download del codice sorgente per ricevere
e creare il codice sorgente di Android. Quando invii il comando repo init
, specifica
ramo CTS specifico utilizzando -b
. In questo modo, le modifiche al CTS saranno incluse
nelle successive uscite di 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
Creare ed eseguire CTS
Esegui questi comandi per creare CTS e avviare il report interattivo Console CTS:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
Nella console CTS, inserisci:
tf> run cts --plan CTS
Scrittura dei test CTS
.I test CTS utilizzano JUnit e le API di test di Android. Esamina il
Prova
la tua app
il tutorial e i test esistenti nella directory cts/tests
.
I test CTS seguono principalmente le stesse convenzioni utilizzate in altri test Android.
Il CTS viene eseguito su molti dispositivi di produzione, quindi i test devono seguire queste regole:
- Tieni conto delle dimensioni dello schermo, degli orientamenti e dei layout di tastiera diversi.
- Utilizza solo metodi API pubblici. In altre parole, evita tutte le classi, i metodi e i campi
con l'annotazione
hide
. - Evita di utilizzare i layout di visualizzazione o di fare affidamento su dimensioni di asset che potrebbero non corrispondere a dispositivi mobili.
- Non fare affidamento sui privilegi root.
Aggiungi annotazione Java
Se il test verifica il comportamento di un'API, annota il codice del test con @ApiTest
ed elenca
tutte le API coinvolte nel campo apis
. Utilizza il formato appropriato tra
i seguenti esempi:
Tipo di API | Formato annotazione | Note |
---|---|---|
Metodo | android.example.ClassA#methodA |
Il caso d'uso più comune. |
Metodo con coppie chiave-valore | android.example.ClassB#methodB(KeyA) |
Da utilizzare solo se il test utilizza un metodo API per convalidare un campo, ad esempio questo esempio. |
Campo | android.example.ClassC#FieldA | Da utilizzare solo quando il test convalida direttamente un campo API, come in questo esempio. |
Se il test verifica un requisito CDD, annota l'ID requisito (inclusa la Sezione CDD
ID e ID requisito) con @CddTest
nel codice di test CTS, come mostrato in
dall'esempio seguente. Nel messaggio di commit, indica quale requisito CDD viene testato dal tuo
facendo riferimento agli ID dei requisiti CDD. Gli ID requisito CDD sono una combinazione di ID sezione
e l'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à in AndroidManifest.xml
con il
l'ID CDD pertinente. I formati per i campi valore sono simili a quelli delle annotazioni Java in
CTS Nel messaggio di commit, indicare quale requisito CDD viene applicato facendo riferimento al CDD
dell'ID requisito.
<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 perché è necessario aggiungere il test e aggiungi link pertinenti per l'assistenza. Per CTS-D test, includi un link alla proposta di test che hai creato in Issue Tracker di Google come parte la procedura di invio CTS-D.
Crea 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 inserimento 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" />
Denominazione e località di test
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
Test
. Ogni scenario di test è costituito da più test, in cui
il test in genere esercita un metodo specifico della classe che viene sottoposta a test.
Questi test sono organizzati in una struttura di directory in cui vengono raggruppati
diverse categorie come "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 relativa classe come
TextViewTest
.
- Nome 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
. Nel nostro esempio, il nome del pacchetto sarebbeandroid.widget.cts
. - Nome del corso
Il nome del corso per i test CTS è nome della classe che viene testata con "Test" aggiunto. Per Ad esempio, se un test ha come targetTextView
, il nome della classe deve essereTextViewTest
. - Nome 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 ad esempiowidget
).
La struttura della directory e il codice campione dipendono dall'utilizzo o meno di CTS v1 o CTS v2.
CTS versione 1
Per Android 6.0 o versioni precedenti, utilizza CTS v1. Per CTS v1, il codice campione si trova
cts/tests/tests/example
.
La struttura delle directory nei test CTS v1 ha il seguente aspetto:
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
CTS versione 2
Per Android 7.0 o versioni successive, utilizza CTS v2. Per maggiori dettagli, consulta test di esempio in Android Open Source Project (AOSP).
La struttura della directory 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 esistente in cui inserire i tuoi test. In questi casi, devi creare la directory e copiare i file di esempio appropriati.
CTS versione 1
Se utilizzi CTS v1, fai riferimento all'esempio riportato
cts/tests/tests/example
e crea una nuova directory. Inoltre,
assicurati di aggiungere il nome del modulo del nuovo pacchetto dal relativo 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 versione 2
Utilizzare il test di esempio
/cts/tests/sample/
per iniziare rapidamente il tuo nuovo modulo di test con i seguenti passaggi:
- 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
- Vai a
cts/tests/module-name
e sostituisci tutte le istanze di "[Grande]ampio" con convenzione di denominazione consigliata sopra. - Aggiorna
SampleDeviceActivity
per esercitarti con la funzionalità che stai testando. - Aggiorna
SampleDeviceTest
per assicurarti che l'attività abbia esito positivo o venga registrata i suoi errori.
Directory aggiuntive
Altre directory Android, ad esempio assets
, jni
,
Puoi aggiungere anche libs
e res
.
Per aggiungere il codice JNI,
crea una directory nella directory principale del progetto accanto a src
con lo stato nativo
e un makefile Android.mk
al suo interno.
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 radice del
per creare il codice nativo e dipendere da quest'ultimo, 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
rimuovi i test annotati con BrokenTest
o KnownFailure
.
Invia le 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, prima
sviluppare una patch in
aosp/main
e poi scegliere la versione Ramo di test upstream. Consenti all'unione automatica di unire le modifiche a valle Rami del test AOSP. Consulta Programma delle release e informazioni sulle filiali per l'elenco delle rami e unione automatica delle informazioni sui percorsi. - Per le modifiche specifiche di un livello API specifico, sviluppa o scegli le modifiche al ramo di test corretto con DO NOT MERGE oppure LIMITA L'AUTOMERGIA nel messaggio di commit.
Segui il flusso di lavoro per l'invio di patch. per apportare modifiche a CTS. Verrà assegnato un revisore che esaminerà la tua modifica di conseguenza.
Pianificazione delle release e informazioni sui rami
Le release CTS seguono questo programma.
Versione | Livello API | Branch | Frequenza |
---|---|---|---|
14 | 34 | test-android14 | Trimestrale |
13 | 33 | test-android13 | Trimestrale |
12 litri | 32 | test-sviluppo-android12L | Trimestrale |
12 | 31 | test-android12 | Trimestrale |
11 | 30 | test-android11 | Trimestrale |
Non sono previste ulteriori release 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 lancio
- Fine della prima settimana: blocco del codice. Modifiche unite nel ramo fino a quando non verrà preso in considerazione il blocco del codice per la prossima versione di CTS. Contenuti inviati al ramo dopo il blocco del codice o dopo un candidato per viene scelta l'uscita e vengono prese in considerazione per quella successiva.
- Seconda o terza settimana: CTS viene pubblicato in AOSP.
Flusso di unione automatica
I rami di sviluppo CTS sono stati configurati in modo che le modifiche inviate a ramo vengono uniti automaticamente ai rami superiori.
Per le modifiche apportate direttamente a un ramo di sviluppo di test AOSP, il percorso di unione automatica è:
android11-tests-dev
>
android12-tests-dev
>
android12L-tests-dev
>
android13-tests-dev
>
android14-tests-dev
>
aosp/main
Solo per le modifiche apportate soltanto alla versione successiva di Android, il percorso di unione automatica è:
aosp/main
>
<Internal git/main>
.
Se un elenco modifiche (CL) non viene unito correttamente, viene inviato l'autore della patch un'email con le istruzioni per risolvere il conflitto. Nella maggior parte dei casi, l'autore della patch può usare le istruzioni per saltare l'unione automatica il CL in conflitto.
Se un ramo meno recente richiede la modifica, la patch deve essere scelto dal ramo più recente.