Rozwój 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.

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

CTS (AOSP 15)

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:

Uruchamianie CTS

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 zachowanie 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łą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 w Javie 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 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ć subplan:

run cts --subplan aSubPlan

Format wpisu w planie podrzędnym:

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 Javy
  Nazwa pakietu Javy dla testów CTS to nazwa pakietu klasy, którą testuje, poprzedzona przez .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 w wersji 2)
  CTS w wersji 2 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 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 pliki przykładowe.

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 make, aby połączyć wszystkie testy i utworzyć ostateczny pakiet CTS.

CTS v2

Aby szybko rozpocząć korzystanie z nowego modułu testowego, 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 sprawdzić, czy działanie zakończyło się powodzeniem lub czy zostały zarejestrowane błędy.

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 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 łatka.
• Opracuj lub wybierz zmiany do odpowiedniej gałęzi testowej, używając w wiadomości o zmianie słów DO NOT MERGE (nie łącz) lub RESTRICT AUTOMERGE (ogranicz automatyczne scalanie).

Do sprawdzania zmian i wprowadzania ich do wewnętrznego Gerrita 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 zgłoszenia po zamrożeniu kodu lub po wybraniu kandydata do wydania są brane pod uwagę w przyszłych wydaniach.
• Drugi lub trzeci tydzień: CTS jest publikowany na stronie Pobieranie pakietu Compatibility Test Suite.

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.

Aby wprowadzić zmiany bezpośrednio w gałęzi testowej w gałęzi deweloperskiej AOSP, wykonaj te czynności:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• W przypadku wersji CTS 16+ sprawdzający wprowadzi zmiany do wewnętrznego Gerrita.

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 proponowanej zmiany Google ją sprawdzi i jeśli zostanie ona zaakceptowana, wprowadzi ją do wewnętrznego Gerrita.