Rozwój CTS

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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.

Tworzenie i uruchamianie CTS

Aby skompilować 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 tabeli poniżej:

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. Inaczej mówiąc, unikaj wszystkich klas, metod i pól z adnotacją 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:

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 następującym przykładzie. W wiadomości o zmianie wspomnij, który wymóg CDD jest testowany przez Twój test, podając identyfikatory wymagań CDD. Identyfikatory wymagań w CDD to kombinacja identyfikatora sekcji i identyfikatora wymagań połączone 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 w Javie w CTS. W wiadomości o zapisu 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 zaznacz, 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ć podplan:

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ą pogrupowane 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 nazwa pakietu to android.widget.cts.
• Nazwa klasy
  Nazwa klasy w przypadku testów CTS to nazwa testowanej klasy z dołączonym słowem „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 2. Więcej informacji znajdziesz w przykładowym teście w projekcie Android Open Source (AOSP).

Struktura katalogu CTS 2 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ąć korzystanie z nowego modułu testowego, wykonaj te czynności: /cts/tests/sample/

1. Aby utworzyć katalog testowy 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ło się powodzeniem lub że błędy zostały zapisane w logu.

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

Przesyłając zmiany do CTS, postępuj zgodnie z przepływem pracy Przesyłanie zmian w kodzie. Wybierz gałę rozwojową na podstawie poziomów interfejsu API, do których ma zastosowanie dana poprawka.

• W przypadku zmian, które mają zastosowanie do wielu poziomów interfejsu API, opracuj poprawkę w najbardziej upstreamowej gałęzi testowej. 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, które mają zastosowanie do określonego poziomu interfejsu API, opracuj lub wybierz zmiany, które mają zostać zastosowane do odpowiedniej gałęzi testowej, dodając w wiadomości o zmianie flagę DO NOT MERGE (nie łącz) lub RESTRICT AUTOMERGE (ogranicz automatyczne scalanie).

Do sprawdzania zmian i wprowadzania ich do Gerrit zostanie przypisany weryfikator.

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

Wersje CTS są publikowane zgodnie z tym harmonogramem.

Ważne daty podczas premiery

• 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 są rozpatrywane w ramach kolejnego wydania.
• 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 deweloperskiej testów AOSP ścieżka automatycznego scalania to:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev

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.

W przypadku zmian testowych, które mają zastosowanie do następnej wersji Androida, po przesłaniu proponowanych zmian Google je sprawdzi, a jeśli zostaną zaakceptowane, wprowadzi je do wewnętrznego Gerrita.