CTS-Entwicklung

Repo-Client initialisieren

Folgen Sie der Anleitung unter Quellcode herunterladen, um den Android-Quellcode zu erhalten und zu erstellen. Geben Sie beim Ausführen des Befehls repo init mit -b einen bestimmten CTS-Branch an. So werden Ihre CTS-Änderungen in nachfolgende CTS-Releases aufgenommen.

Der folgende Beispielcode zeigt, wie repo init verwendet wird.

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

CTS erstellen und ausführen

Führen Sie die folgenden Befehle aus, um CTS zu erstellen und die interaktive CTS-Konsole zu starten:

Hinweis:Sie können aosp_x86_64 als Alternative zu aosp_arm64 verwenden.

CTS erstellen (AOSP 14 oder früher)

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

CTS erstellen (AOSP 15)

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

Wählen Sie den target-release-Wert anhand der folgenden Tabelle aus:

Branch	Zielversion
android15-tests-dev	ap3a

CTS ausführen

Geben Sie in der CTS-Konsole Folgendes ein:

tf> run cts --plan CTS

CTS-Tests schreiben

Wenn Sie einen von Entwicklern entwickelten CTS-Test (CTS-D) schreiben möchten, müssen Sie zuerst einen Testvorschlag gemäß der Anleitung im CTS-Einreichungsprozess einreichen.

CTS-Tests verwenden JUnit und die Android-Test-APIs. Sehen Sie sich das Tutorial zum Testen Ihrer App und die vorhandenen Tests im Verzeichnis cts/tests an. CTS-Tests folgen größtenteils denselben Konventionen wie andere Android-Tests.

CTS wird auf vielen Produktionsgeräten ausgeführt. Die Tests müssen daher den folgenden Regeln entsprechen:

• Berücksichtigen Sie unterschiedliche Bildschirmgrößen, Ausrichtungen und Tastaturlayouts.
• Verwenden Sie nur öffentliche API-Methoden. Vermeiden Sie also alle Klassen, Methoden und Felder mit der Annotation hide.
• Vermeiden Sie die Verwendung von Ansichtslayouts oder die Abhängigkeit von den Abmessungen von Assets, die auf einigen Geräten möglicherweise nicht vorhanden sind.
• Verlassen Sie sich nicht auf Root-Berechtigungen.

Java-Annotation hinzufügen

Wenn Ihr Test ein API-Verhalten überprüft, versehen Sie Ihren Testcode mit @ApiTest und listen Sie alle beteiligten APIs im Feld apis auf. Verwenden Sie das passende Format aus den folgenden Beispielen:

API-Typ	Anmerkungsformat	Hinweise
Methode	android.example.ClassA#methodA	Der häufigste Anwendungsfall.
Methode mit Schlüssel/Wert-Paaren	android.example.ClassB#methodB(KeyA)	Nur verwenden, wenn in Ihrem Test eine API-Methode zum Validieren eines Felds verwendet wird, wie in diesem Beispiel.
Feld	android.example.ClassC#FieldA	Verwenden Sie diese Option nur, wenn Ihr Test ein API-Feld direkt validiert, wie in diesem Beispiel.

Wenn Ihr Test eine CDD-Anforderung überprüft, fügen Sie der Anforderungs-ID (einschließlich CDD-Abschnitts-ID und Anforderungs-ID) im CTS-Testcode die Anmerkung @CddTest hinzu, wie im folgenden Beispiel gezeigt. Geben Sie in Ihrer Commit-Nachricht an, welche CDD-Anforderung durch Ihren Test getestet wird, indem Sie auf CDD-Anforderungs-IDs verweisen. CDD-Anforderungs-IDs sind eine Kombination aus Abschnitts-ID und Anforderungs-ID, die durch einen Schrägstrich (/) verbunden sind, z. B. 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()));
    }

Für CTS Verifier müssen Sie jede Aktivität in Ihrem AndroidManifest.xml mit der entsprechenden CDD-ID versehen. Die Formate für Wertfelder ähneln den Formaten von Java-Annotationen in CTS. Geben Sie in der Commit-Nachricht an, welche CDD-Anforderung durch die Referenzierung der CDD-Anforderungs-ID erzwungen wird.

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

In der Commit-Nachricht

Geben Sie deutlich an, warum Ihr Test hinzugefügt werden muss, und fügen Sie relevante Links für den Support hinzu. Fügen Sie für CTS-D-Tests einen Link zum Testvorschlag ein, den Sie im Rahmen des CTS-D-Einreichungsprozesses in Google Issue Tracker erstellt haben.

Unterplan erstellen

Sie können beispielsweise eine SubPlan.xml-Datei in android-cts/subplans wie folgt hinzufügen:

<?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>

So führen Sie das Unterabo aus:

run cts --subplan aSubPlan

Das Format für den Unterplan-Eintrag lautet:

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

Name und Speicherort des Tests

Die meisten CTS-Testläufe sind auf eine bestimmte Klasse in der Android API ausgerichtet. Diese Tests haben Java-Paketnamen mit dem Suffix cts und Klassennamen mit dem Suffix Test. Jeder Testfall besteht aus mehreren Tests, wobei jeder Test in der Regel eine bestimmte Methode der zu testenden Klasse ausführt. Diese Tests sind in einer Verzeichnisstruktur angeordnet, in der Tests in verschiedene Kategorien wie „Widgets“ oder „Views“ gruppiert sind.

Der CTS-Test für das Java-Paket android.widget.TextView ist beispielsweise android.widget.cts.TextViewTest mit dem Java-Paketnamen android.widget.cts und dem Klassennamen TextViewTest.

• Java-Paketname
  Der Java-Paketname für die CTS-Tests ist der Paketname der Klasse, die getestet wird, gefolgt von .cts. In unserem Beispiel lautet der Paketname android.widget.cts.
• Klassenname
  Der Klassenname für CTS-Tests ist der Name der Klasse, die getestet wird, mit dem Zusatz „Test“. Wenn ein Test beispielsweise auf TextView ausgerichtet ist, sollte der Klassenname TextViewTest lauten.
• Modulname (nur CTS v2)
  In CTS v2 werden Tests nach Modul organisiert. Der Modulname ist in der Regel der zweite String des Java-Paketnamens (in unserem Beispiel widget).

Die Verzeichnisstruktur und der Beispielcode hängen davon ab, ob Sie CTS v1 oder CTS v2 verwenden.

CTS v1

Verwenden Sie für Android 6.0 oder niedriger CTS v1. Für CTS v1 befindet sich der Beispielcode unter cts/tests/tests/example.

Die Verzeichnisstruktur in CTS v1-Tests sieht so aus:

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

CTS v2

Verwenden Sie für Android 7.0 oder höher CTS v2. Weitere Informationen finden Sie im Beispieltest im Open-Source-Projekt für Android (AOSP).

Die CTS v2-Verzeichnisstruktur sieht so aus:

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

Neue Musterpakete

Wenn Sie neue Tests hinzufügen, gibt es möglicherweise kein vorhandenes Verzeichnis, in dem Sie den Test platzieren können. In diesen Fällen müssen Sie das Verzeichnis erstellen und die entsprechenden Beispieldateien kopieren.

CTS v1

Wenn Sie CTS v1 verwenden, sehen Sie sich das Beispiel unter cts/tests/tests/example an und erstellen Sie ein neues Verzeichnis. Achten Sie außerdem darauf, dass Sie den Modulnamen des neuen Pakets aus der Datei Android.mk in CTS_COVERAGE_TEST_CASE_LIST in cts/CtsTestCaseList.mk einfügen. build/core/tasks/cts.mk verwendet dieses Makefile, um alle Tests zu kombinieren und das endgültige CTS-Paket zu erstellen.

CTS v2

Verwenden Sie den Beispieltest  /cts/tests/sample/ , um Ihr neues Testmodul mit den folgenden Schritten schnell zu starten:

1. So erstellen Sie das Testverzeichnis und kopieren die Beispieldateien:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. Rufen Sie cts/tests/module-name auf und ersetzen Sie alle Instanzen von „[Ss]ample“ durch die empfohlene Namenskonvention oben.
3. Aktualisieren Sie SampleDeviceActivity, um die Funktion zu testen.
4. Aktualisieren Sie SampleDeviceTest, damit die Aktivität erfolgreich ausgeführt wird oder Fehler protokolliert werden.

Zusätzliche Verzeichnisse

Es können auch andere Android-Verzeichnisse wie assets, jni, libs und res hinzugefügt werden. Wenn Sie JNI-Code hinzufügen möchten, erstellen Sie im Stammverzeichnis des Projekts neben src ein Verzeichnis mit dem nativen Code und einer Android.mk-Makefile-Datei.

Das Makefile enthält in der Regel die folgenden Einstellungen:

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)

Android.mk-Datei

Ändern Sie schließlich die Datei Android.mk im Stammverzeichnis des Projekts, um den nativen Code zu erstellen und davon abhängig zu sein, wie unten gezeigt:

# 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))

Tests korrigieren oder entfernen

Sie können nicht nur neue Tests hinzufügen, sondern auch Tests korrigieren oder entfernen, die mit BrokenTest oder KnownFailure annotiert sind.

Änderungen senden

Folgen Sie dem Workflow Codeänderungen einreichen, wenn Sie Änderungen am CTS vornehmen.

• Wählen Sie den Entwicklungszweig basierend auf den API-Levels aus, für die der Patch gilt.
• Entwickeln Sie die Änderungen oder wählen Sie sie für den richtigen Testzweig aus. Verwenden Sie dazu DO NOT MERGE oder RESTRICT AUTOMERGE in der Commit-Nachricht.

Ein Prüfer wird zugewiesen, um Ihre Änderung zu überprüfen und sie entsprechend in das interne Gerrit zu übernehmen.

Veröffentlichungszeitplan und Informationen zu Branches

CTS-Releases folgen diesem Zeitplan.

Hinweis:Dieser Zeitplan ist vorläufig und wird aktualisiert, sobald das CTS für die jeweilige Android-Version ausgereift ist.

Version	API-Ebene	Entwicklungs-Branch	Erscheinungsfrequenz
16+	36+	Internes Gerrit	Vierteljährlich
15	35	android15-tests-dev	Vierteljährlich
14	34	android14-tests-dev	Vierteljährlich
13	33	android13-tests-dev	Vierteljährlich

Hinweis:Für die Versionen 4.2 bis 12.1 sind keine weiteren Releases geplant.

Wichtige Termine während der Veröffentlichung

• Ende der ersten Woche:Code-Freeze. Änderungen, die bis zum Code-Freeze in den Branch zusammengeführt werden, werden für die nächste CTS-Version berücksichtigt. Beiträge zum Branch nach dem Code-Freeze oder nachdem ein Release-Kandidat ausgewählt wurde, werden für das nachfolgende Release berücksichtigt.
• Zweite oder dritte Woche:CTS wird auf der Seite Compatibility Test Suite-Downloads veröffentlicht.

Automerge-Ablauf

Für CTS-Entwicklungszweige wurde festgelegt, dass Änderungen, die für einen Zweig eingereicht werden, automatisch in höhere Zweige zusammengeführt werden.

Bei Änderungen direkt an einem AOSP-Testentwicklungszweig ist der automatische Merge-Pfad:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• Bei CTS-Versionen 16 und höher wählt ein Prüfer die Änderung entsprechend für das interne Gerrit aus.

Wenn eine Änderungsliste nicht richtig zusammengeführt werden kann, erhält der Autor des Patches eine E‑Mail mit einer Anleitung zur Behebung des Konflikts. In den meisten Fällen kann der Autor des Patches die Anleitung verwenden, um das automatische Zusammenführen des in Konflikt stehenden CL zu überspringen.

Wenn die Änderung für einen älteren Branch erforderlich ist, muss der Patch aus dem neueren Branch übernommen werden.

Bei Teständerungen, die für die nächste Android-Version gelten, wird eine vorgeschlagene Änderung nach dem Hochladen von Google überprüft. Wenn sie akzeptiert wird, wird sie in das interne Gerrit übernommen.