Rozwój CTS

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 .

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:

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 to android.widget.cts .
• Nazwa klasy
  Nazwa klasy dla testów CTS to nazwa testowanej klasy z dodatkiem „Test”. Na przykład, jeśli celem testu jest TextView , 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ładzie widget ).

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:

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. Przejdź do cts/tests/ module-name i zamień wszystkie wystąpienia „[Ss]ample” na zalecaną konwencję nazewnictwa z góry.
3. Zaktualizuj SampleDeviceActivity , aby skorzystać z testowanej funkcji.
4. 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.

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.