Zainicjuj klienta Repo
Postępuj zgodnie z instrukcjami z Pobieranie źródła , aby uzyskać i skompilować kod źródłowy Androida. Wydając polecenie repo init
, określ konkretną gałąź CTS za pomocą -b
. Dzięki temu zmiany CTS zostaną uwzględnione w kolejnych wersjach CTS.
Poniższy przykładowy kod pokazuje, jak używać 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
Zbuduj i uruchom CTS
Wykonaj następujące polecenia, aby zbudować CTS i uruchomić interaktywną konsolę CTS:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
W konsoli CTS wpisz:
tf> run cts --plan CTS
Napisz testy CTS
Testy CTS korzystają z interfejsów API JUnit i testowania systemu Android. Przejrzyj samouczek Testuj aplikację i istniejące testy w katalogu cts/tests
. Testy CTS w większości opierają się na tych samych konwencjach, co w innych testach Androida.
CTS działa na wielu urządzeniach produkcyjnych, dlatego testy muszą spełniać następujące zasady:
- Weź pod uwagę różne rozmiary, orientacje i układy klawiatury.
- Używaj wyłącznie publicznych metod API. Innymi słowy, unikaj wszystkich klas, metod i pól z adnotacją
hide
. - Unikaj używania układów widoków lub polegania na wymiarach zasobów, których nie można znaleźć na niektórych urządzeniach.
- Nie polegaj na uprawnieniach roota.
Dodaj adnotację Java
Jeśli test weryfikuje zachowanie interfejsu API, dodaj adnotację do kodu testowego za pomocą @ApiTest
i wymień wszystkie interfejsy API zaangażowane w pole apis
. Użyj odpowiedniego formatu spośród poniższych przykładów:
Typ interfejsu API | Format adnotacji | Notatki |
---|---|---|
metoda | android.example.ClassA#methodA | Najczęstszy przypadek użycia. |
Metoda z wartościami kluczy | android.example.ClassB#methodB(KeyA) | Używaj tylko wtedy, gdy test wykorzystuje metodę API do sprawdzania poprawności pola, jak w tym przykładzie. |
Pole | android.example.ClassC#FieldA | Używaj tylko wtedy, gdy test bezpośrednio sprawdza poprawność pola API, jak w tym przykładzie. |
Jeśli Twój test weryfikuje wymaganie CDD, dodaj adnotację do identyfikatora wymagania (w tym identyfikatora sekcji CDD i identyfikatora wymagania) za pomocą @CddTest
w kodzie testu CTS, jak pokazano w poniższym przykładzie. W komunikacie zatwierdzenia wspomnij, które wymagania CDD są testowane w Twoim teście, odwołując się do identyfikatorów wymagań CDD. Identyfikatory wymagań CDD są kombinacją identyfikatora sekcji i identyfikatora wymagania, połączonych ukośnikiem (/), jak w wersji 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()));
}
W przypadku weryfikatora CTS opisz każde działanie w pliku AndroidManifest.xml
odpowiednim identyfikatorem CDD. Formaty pól wartości są podobne do formatów adnotacji Java w CTS. W komunikacie zatwierdzenia wskaż, które wymaganie CDD jest egzekwowane, odwołując się do identyfikatora wymagania 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>
W komunikacie zatwierdzenia
Wyraźnie wspomnij, dlaczego należy dodać Twój test, i dodaj odpowiednie linki do pomocy. W przypadku testów CTS-D dołącz link do propozycji testu utworzonej w narzędziu Google Issue Tracker w ramach procesu przesyłania CTS-D .
Utwórz podplan
Jako przykład możesz dodać plik SubPlan.xml w android-cts/subplans
w następujący sposób:
<?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>
Aby uruchomić podplan:
run cts --subplan aSubPlan
Format wpisu planu podrzędnego to:
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" />
Nazewnictwo i lokalizacja testu
Większość przypadków testowych CTS jest ukierunkowana na określoną klasę w interfejsie API systemu Android. Testy te mają nazwy pakietów Java z przyrostkiem cts
i nazwy klas z przyrostkiem Test
. Każdy przypadek testowy składa się z wielu testów, przy czym każdy test zazwyczaj wykorzystuje określoną metodę testowanej klasy. Testy te są zorganizowane w strukturę katalogów, w której testy są pogrupowane w różne kategorie, takie jak „widżety” lub „widoki”.
Na przykład test CTS dla pakietu Java android.widget.TextView
to android.widget.cts.TextViewTest
z nazwą pakietu Java jako android.widget.cts
i nazwą klasy jako TextViewTest
.
- Nazwa pakietu Java
Nazwa pakietu Java dla testów CTS to nazwa pakietu klasy testowanej przez test, po której następuje.cts
. W naszym przykładzie nazwa pakietu toandroid.widget.cts
. - Nazwa klasy
Nazwa klasy dla testów CTS to nazwa testowanej klasy z dodatkiem „Test”. Na przykład, jeśli celem testu jestTextView
, nazwa klasy powinna brzmiećTextViewTest
. - Nazwa modułu (tylko CTS v2)
CTS v2 organizuje testy według modułów. Nazwa modułu to zwykle drugi ciąg nazwy pakietu Java (w naszym przykładziewidget
).
Struktura katalogów i przykładowy kod zależą od tego, czy używasz CTS v1, czy CTS v2.
CTS wersja 1
W przypadku Androida 6.0 lub starszego użyj CTS v1. W przypadku CTS v1 przykładowy kod znajduje się pod cts/tests/tests/example
.
Struktura katalogów w testach CTS v1 wygląda następująco:
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
CTS wersja 2
W przypadku Androida 7.0 lub nowszego użyj CTS v2. Aby uzyskać szczegółowe informacje, zobacz przykładowy test w projekcie Android Open Source Project (AOSP) .
Struktura katalogów CTS v2 wygląda następująco:
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
Nowe przykładowe pakiety
Podczas dodawania nowych testów może nie być istniejącego katalogu, w którym można umieścić test. W takich przypadkach należy utworzyć katalog i skopiować odpowiednie przykładowe pliki.
CTS wersja 1
Jeśli używasz CTS v1, zapoznaj się z przykładem w cts/tests/tests/example
i utwórz nowy katalog. Pamiętaj także, aby dodać nazwę modułu nowego pakietu z pliku Android.mk
do CTS_COVERAGE_TEST_CASE_LIST
w cts/CtsTestCaseList.mk
. build/core/tasks/cts.mk
używa tego pliku makefile do połączenia wszystkich testów i utworzenia ostatecznego pakietu CTS.
CTS wersja 2
Użyj przykładowego testu /cts/tests/sample/
aby szybko uruchomić nowy moduł testowy, wykonując następujące kroki:
- Aby utworzyć katalog testowy i skopiować przykładowe pliki, uruchom:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- Przejdź do
cts/tests/ module-name
i zamień wszystkie wystąpienia „[Ss]ample” na zalecaną konwencję nazewnictwa z góry. - Zaktualizuj
SampleDeviceActivity
, aby skorzystać z testowanej funkcji. - Zaktualizuj
SampleDeviceTest
, aby upewnić się, że działanie zakończy się pomyślnie lub zarejestruje błędy.
Dodatkowe katalogi
Można również dodać inne katalogi Androida, takie jak assets
, jni
, libs
i res
. Aby dodać kod JNI, utwórz katalog w katalogu głównym projektu obok src
z kodem natywnym i plikiem makefile Android.mk
.
Plik makefile zazwyczaj zawiera następujące ustawienia:
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)
Plik Android.mk
Na koniec zmodyfikuj plik Android.mk
w katalogu głównym projektu, aby zbudować natywny kod i na nim polegać, jak pokazano poniżej:
# 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))
Napraw lub usuń testy
Oprócz dodawania nowych testów możesz naprawiać lub usuwać testy z adnotacją BrokenTest
lub KnownFailure
.
Prześlij swoje zmiany
Przesyłając łatki CTS lub VTS w AOSP, wybierz gałąź programistyczną w oparciu o poziomy API, których dotyczy łatka.
- W przypadku zmian, które dotyczą wielu poziomów API, najpierw opracuj łatkę w
aosp/main
, a następnie wybierz najbardziej upstreamową gałąź testową . Zezwól automergerowi na połączenie zmian w dalszych gałęziach testowych AOSP. Zobacz Harmonogram wydań i informacje o gałęziach , aby uzyskać listę gałęzi i informacje o ścieżce automatycznego scalania. - W przypadku zmian specyficznych dla określonego poziomu interfejsu API opracuj lub wybierz zmiany w odpowiedniej gałęzi testowej za pomocą komunikatu zatwierdzenia DO NOT MERGE lub RESTRICT AUTOMERGE .
Postępuj zgodnie z procedurą przesyłania poprawek , aby wprowadzić zmiany do CTS. Zostanie wyznaczony recenzent, który odpowiednio sprawdzi Twoją zmianę.
Harmonogram wydań i informacje o oddziałach
Wydania CTS są zgodne z tym harmonogramem.
Wersja | Poziom API | Oddział | Częstotliwość |
---|---|---|---|
14 | 34 | android14-testy-dev | Kwartalny |
13 | 33 | android13-testy-dev | Kwartalny |
12L | 32 | android12L-testy-dev | Kwartalny |
12 | 31 | android12-testy-dev | Kwartalny |
11 | 30 | android11-testy-dev | Kwartalny |
Nie są planowane żadne dalsze wydania wersji 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 i 4.2. |
Ważne daty w wydaniu
- Koniec pierwszego tygodnia: Zamrożenie kodu. Zmiany scalone w gałęzi do czasu zamrożenia kodu są uwzględniane w nadchodzącej wersji CTS. Zgłoszenia do oddziału po zamrożeniu kodu lub po wybraniu kandydata do wydania są brane pod uwagę przy kolejnym wydaniu.
- Drugi lub trzeci tydzień: CTS jest publikowany w AOSP .
Przepływ automatycznego scalania
Oddziały rozwojowe CTS zostały skonfigurowane tak, aby zmiany wprowadzane do każdego oddziału automatycznie łączyły się z oddziałami wyższymi.
W przypadku zmian bezpośrednio w gałęzi dewelopera testowego AOSP ścieżka automatycznego scalania to:
android11-tests-dev
> android12-tests-dev
> android12L-tests-dev
> android13-tests-dev
> android14-tests-dev
> aosp/main
W przypadku zmian tylko w następnej wersji Androida ścieżka automatycznego scalania to:
aosp/main
> <Internal git/main>
.
Jeśli lista zmian (CL) nie zostanie poprawnie scalona, do autora łatki zostanie wysłana wiadomość e-mail z instrukcjami, jak rozwiązać konflikt. W większości przypadków autor łatki może skorzystać z instrukcji, aby pominąć automatyczne połączenie CL będącej w konflikcie.
Jeśli starsza gałąź wymaga zmiany, wówczas łatkę należy pobrać z nowszej gałęzi.