Programowanie CTS

Inicjowanie klienta repozytorium

Aby pobrać i skompilować kod źródłowy Androida, postępuj zgodnie z instrukcjami podanymi w sekcji Pobieranie kodu źródłowego. Podczas wydawania polecenia repo init określ konkretną gałąź CTS za pomocą parametru -b. Dzięki temu zmiany w CTS będą uwzględniane w kolejnych wersjach CTS.

Poniższy przykładowy kod pokazuje, jak używać funkcji 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

Tworzenie i uruchamianie CTS

Aby utworzyć CTS i uruchomić interaktywną konsolę CTS, wykonaj te polecenia:

Budowanie pakietu CTS (AOSP 14 lub wcześniejsza wersja)

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

Budowanie CTS (AOSP 15 lub nowsza wersja)

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

Aby wybrać wartość target-release, użyj tej tabeli:

Oddział Docelowa wersja
android15-tests-dev ap3a

W konsoli CTS wpisz:

tf> run cts --plan CTS

Pisanie testów CTS

Testy CTS korzystają z JUnit i interfejsów API do testowania Androida. Zapoznaj się z samouczkiem Testowanie aplikacji i dotychczasowymi testami w katalogu cts/tests. Testy CTS są w większości zgodne z tymi samymi konwencjami, które są używane w innych testach Androida.

Testy CTS są przeprowadzane na wielu urządzeniach produkcyjnych, dlatego muszą być zgodne z tymi zasadami:

  • Weź pod uwagę różne rozmiary ekranu, orientacje i układy klawiatury.
  • Używaj tylko publicznych metod interfejsu API. Innymi słowy, unikaj wszystkich klas, metod i pól z annotacjami hide.
  • Unikaj korzystania z widoków i nie polegaj na wymiarach komponentów, które mogą nie być dostępne na niektórych urządzeniach.
  • Nie polegaj na uprawnieniach roota.

Dodawanie adnotacji w Javie

Jeśli test weryfikuje działanie interfejsu API, dodaj do kodu testowego adnotację @ApiTest i wymień wszystkie interfejsy API w polu apis. Użyj odpowiedniego formatu spośród tych przykładów:

Typ interfejsu API Format adnotacji Uwagi
Metoda android.example.ClassA#methodA Najczęstszy przypadek użycia.
Metoda z kluczami i wartościami android.example.ClassB#methodB(KeyA) Używaj tylko wtedy, gdy test używa metody interfejsu API do sprawdzania pola, jak w tym przykładzie.
Pole android.example.ClassC#FieldA Używaj tylko wtedy, gdy test weryfikuje bezpośrednio pole interfejsu API, jak w tym przykładzie.

Jeśli test weryfikuje wymóg CDD, dodaj adnotację z identyfikatorem wymagania (w tym identyfikatorem sekcji CDD i identyfikatorem wymagania) za pomocą @CddTest w kodzie testu CTS, jak pokazano w tym przykładzie. W wiadomości o zgłoszeniu wspomnij, który wymóg CDD jest testowany przez Twój test, odwołując się do identyfikatorów wymagań CDD. Identyfikatory wymagań w CDD to kombinacja identyfikatora sekcji i identyfikatora wymagań połączonych znakiem ukośnika (/), np. 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 każdą aktywność w AndroidManifest.xml należy opatrzyć odpowiednim identyfikatorem CDD. Formaty pól wartości są podobne do formatów adnotacji Java w CTS. W wiadomości o zmianie wspomnij, które wymagania dotyczące weryfikacji tożsamości są egzekwowane, odwołując się do identyfikatora tych wymagań. 


  <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 wyjaśnij, dlaczego test musi zostać dodany, i dodaj odpowiednie linki do pomocy. W przypadku testów CTS-D dołącz link do propozycji testu utworzonej w Google Issue Tracker w ramach procesu przesyłania CTS-D.

Tworzenie podplanu

Na przykład możesz dodać plik SubPlan.xml w folderze android-cts/subplans w ten 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ć subplan:

run cts --subplan aSubPlan

Format wpisu w subplanie:

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

Testowanie nazwy i lokalizacji

Większość przypadków testów CTS dotyczy konkretnej klasy w interfejsie API Androida. Te testy mają nazwy pakietów Java z sufiksem cts i nazwy klas z sufiksem Test. Każdy przypadek testowy składa się z kilku testów, z których każdy zwykle sprawdza określoną metodę testowanej klasy. Testy są uporządkowane w strukturze katalogu, w której są grupowane według różnych kategorii, np. „widżety” lub „widoki”.

Na przykład test CTS dla pakietu Javaandroid.widget.TextView toandroid.widget.cts.TextViewTest, gdzie nazwa pakietu Java toandroid.widget.cts, a nazwa klasy toTextViewTest.

  • Nazwa pakietu Java
    Nazwa pakietu Java dla testów CTS to nazwa pakietu klasy, którą testuje, a następnie .cts. W naszym przykładzie jest to android.widget.cts.
  • Nazwa klasy
    Nazwa klasy w przypadku testów CTS to nazwa testowanej klasy z dodaną końcówką „Test”. Jeśli na przykład test jest kierowany na TextView, nazwa klasy powinna brzmieć TextViewTest.
  • Nazwa modułu (tylko CTS v2)
    CTS v2 porządkuje testy według modułów. Nazwa modułu to zwykle drugi ciąg znaków w nazwie pakietu Java (w naszym przykładzie widget).

Struktura katalogów i przykładowy kod zależą od tego, czy używasz CTS w wersji 1 czy 2.

CTS w wersji 1

W przypadku Androida 6.0 lub starszego użyj CTS 1. Przykładowy kod CTS w wersji 1 znajdziesz tutaj: cts/tests/tests/example.

Struktura katalogów w testach CTS w wersji 1 wygląda tak: 

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

CTS v2

W przypadku Androida 7.0 lub nowszego użyj CTS w wersji 2. Więcej informacji znajdziesz w przykładowym teście w projekcie Android Open Source (AOSP).

Struktura katalogu CTS v2 wygląda tak: 

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

Nowe pakiety próbek

Podczas dodawania nowych testów może się okazać, że nie ma katalogu, w którym można umieścić test. W takich przypadkach musisz utworzyć katalog i skopiować do niego odpowiednie przykładowe pliki.

CTS w wersji 1

Jeśli używasz CTS w wersji 1, zapoznaj się z przykładem w sekcji cts/tests/tests/example i utwórz nowy katalog. Pamiętaj też, aby dodać nazwę modułu nowego pakietu z Android.mk do CTS_COVERAGE_TEST_CASE_LIST w cts/CtsTestCaseList.mk. build/core/tasks/cts.mk używa tego pliku makefile do łączenia wszystkich testów i tworzenia ostatecznego pakietu CTS.

CTS v2

Aby szybko rozpocząć nowy moduł testu, wykonaj te czynności: /cts/tests/sample/

  1. Aby utworzyć katalog testów i skopiować przykładowe pliki, uruchom: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Otwórz plik cts/tests/module-name i zastąp wszystkie wystąpienia ciągu „[Ss]ample” zalecaną konwencją nazewnictwa podaną powyżej.
  3. Zaktualizuj SampleDeviceActivity, aby przetestować funkcję, którą testujesz.
  4. Zaktualizuj SampleDeviceTest, aby upewnić się, że działanie zakończy się powodzeniem lub zostanie zapisane.

Dodatkowe katalogi

Można też dodać inne katalogi Androida, takie jak assets, jni, libs i res. Aby dodać kod JNI, utwórz katalog w korzeniach projektu obok src z kodem natywnym i z plikiem make o nazwie Android.mk.

Plik makefile zawiera zwykle te 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 utworzyć kod natywny i od niego zależny, 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))

Naprawianie i usuwanie testów

Oprócz dodawania nowych testów możesz poprawiać i usuwać testy oznaczone etykietami BrokenTest lub KnownFailure.

Przesyłanie zmian

Podczas przesyłania poprawek CTS lub VTS w AOSP wybierz gałąź rozwoju na podstawie tego, do których poziomów interfejsu API mają zastosowanie.

  • W przypadku zmian, które mają zastosowanie do wielu poziomów interfejsu API, najpierw opracuj poprawkę w aosp/main, a potem wybierz najbardziej aktualną gałęź testową. Zezwól na automatyczne scalanie zmian w dalszych gałęziach testowych AOSP. Informacje o gałęziach i ścieżkach automatycznego scalania znajdziesz w sekcji Harmonogram wydania i informacje o gałęziach.
  • W przypadku zmian związanych z określonym poziomem interfejsu API opracuj lub wybierz zmiany do odpowiedniej gałęzi testowej, używając w wiadomości o zmianie flagi DO NOT MERGE (nie scalaj) lub RESTRICT AUTOMERGE (ogranicz automatyczne scalanie).

Aby przesłać zmiany do CTS, wykonaj przepływ pracy przesyłania poprawek. W związku z tym zostanie przypisany weryfikator, który sprawdzi Twoją zmianę.

harmonogram udostępniania i informacje o gałęzi.

Wersje CTS są publikowane zgodnie z tym harmonogramem.

Wersja Poziom interfejsu API Oddział Częstotliwość
15 35 android15-tests-dev Co kwartał
14 34 android14-tests-dev Co kwartał
13 33 android13-tests-dev Co kwartał
12 L 32 android12L-tests-dev Co kwartał
12 31 android12-tests-dev Co kwartał

Ważne daty w ramach wydania

  • Koniec pierwszego tygodnia: zamrożenie kodu. Zmiany scalone w gałęzi do momentu zamrożenia kodu są uwzględniane w przyszłej wersji CTS. Przesłane do gałęzi po zamrożeniu kodu lub po wybraniu kandydata do wydania zostaną uwzględnione w kolejnych wydaniach.
  • Drugi lub trzeci tydzień: CTS jest publikowany w AOSP.

Procedura automatycznego łączenia

Gałęzie rozwoju CTS zostały skonfigurowane tak, aby zmiany przesłane do każdej gałęzi były automatycznie scalane z gałęziami o wyższym priorytecie.

W przypadku zmian wprowadzanych bezpośrednio do gałęzi testowej w gałęzi deweloperskiej AOSP ścieżka automatycznego scalania to:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Aby zautomatyzować proces łączenia, gdy zmiany dotyczą tylko następnej wersji Androida, wykonaj te czynności:
aosp-main ><Internal git_main>.

Jeśli nie uda się poprawnie scalić listy zmian, autorowi poprawki zostanie wysłany e-mail z instrukcjami rozwiązywania konfliktu. W większości przypadków autor poprawki może użyć instrukcji, aby pominąć automatyczne scalanie konfliktującego CL.

Jeśli zmiana jest wymagana w starszej gałęzi, należy wybrać odpowiednią łatkę z novej gałęzi.