CTS-Entwicklung

Repo-Client initialisieren

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

Das folgende Beispiel zeigt die Verwendung von repo init.

CTS erstellen und ausführen

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

CTS-Build (AOSP 14 oder niedriger)

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

CTS erstellen (AOSP 15 oder höher)

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 in der folgenden Tabelle aus:

Geben Sie in der CTS-Konsole Folgendes ein:

tf> run cts --plan CTS

CTS-Tests schreiben

Für CTS-Tests werden JUnit und die Android-Test-APIs verwendet. 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. Daher müssen die Tests 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 Anmerkung hide.
• Verwenden Sie keine Ansichtslayouts und verlassen Sie sich nicht auf die Abmessungen von Assets, die auf einigen Geräten möglicherweise nicht vorhanden sind.
• Verlassen Sie sich nicht auf Root-Berechtigungen.

Java-Anmerkung hinzufügen

Wenn Sie mit Ihrem Test das Verhalten einer API prüfen, kennzeichnen Sie Ihren Testcode mit @ApiTest und listen Sie alle beteiligten APIs im Feld apis auf. Verwenden Sie eines der folgenden Formate:

Wenn Ihr Test eine CDD-Anforderung überprüft, kennzeichnen Sie die Anforderungs-ID (einschließlich der CDD-Abschnitts-ID und der Anforderungs-ID) im CTS-Testcode mit @CddTest, wie im folgenden Beispiel gezeigt. Geben Sie in Ihrer Commit-Nachricht an, welche CDD-Anforderung mit Ihrem Test geprüft wird. Geben Sie dazu die IDs der CDD-Anforderungen an. Die CDD-Anforderungen-IDs sind eine Kombination aus Abschnitts-ID und Anforderungs-ID, die durch einen Schrägstrich (/) getrennt 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 den CTS-Verifier müssen Sie jede Aktivität in Ihrer AndroidManifest.xml mit der entsprechenden CDD-ID versehen. Die Formate für Wertefelder ähneln den Formaten von Java-Anmerkungen in CTS. Geben Sie in der Commit-Nachricht an, welche CDD-Anforderung erzwungen wird, indem Sie auf die CDD-Anforderungs-ID verweisen.

  <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 klar an, warum Ihr Test hinzugefügt werden muss, und fügen Sie relevante Links zur Unterstützung hinzu. Fügen Sie für CTS-D-Tests einen Link zum Testvorschlag hinzu, den Sie im Rahmen des CTS-D-Einreichungsprozesses im Google Issue Tracker erstellt haben.

Unterplan erstellen

So fügen Sie beispielsweise eine SubPlan.xml-Datei in android-cts/subplans hinzu:

<?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 den untergeordneten Plan aus:

run cts --subplan aSubPlan

Das Format für den Unterplanseintrag ist:

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

Testbenennung und -standort

Die meisten CTS-Testfälle 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, bei denen in der Regel eine bestimmte Methode der zu testenden Klasse ausgeführt wird. Diese Tests sind in einer Verzeichnisstruktur angeordnet, in der sie in verschiedene Kategorien wie „Widgets“ oder „Ansichten“ gruppiert sind.

Der CTS-Test für das Java-Paket android.widget.TextView lautet beispielsweise android.widget.cts.TextViewTest. Der Name des Java-Pakets ist android.widget.cts und der Klassenname 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 getesteten Klasse mit dem Zusatz „Test“. Wenn ein Test beispielsweise auf TextView ausgerichtet ist, sollte der Klassenname TextViewTest lauten.
• Modulname (nur CTS v2)
  Bei 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 Android Open Source Project (AOSP).

Die Verzeichnisstruktur von CTS v2 sieht so aus:

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

Neue Beispielpakete

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

CTS v1

Wenn Sie CTS v1 verwenden, lesen Sie das Beispiel unter cts/tests/tests/example und erstellen Sie ein neues Verzeichnis. Fügen Sie außerdem den Modulnamen Ihres neuen Pakets von Android.mk bis CTS_COVERAGE_TEST_CASE_LIST in cts/CtsTestCaseList.mk hinzu. 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. Führen Sie Folgendes aus, um das Testverzeichnis zu erstellen und Beispieldateien zu kopieren:

   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 Benennungskonvention oben.
3. Aktualisieren Sie SampleDeviceActivity, um die getestete Funktion zu verwenden.
4. Aktualisieren Sie SampleDeviceTest, damit die Aktivität erfolgreich abgeschlossen wird oder Fehler protokolliert werden.

Zusätzliche Verzeichnisse

Andere Android-Verzeichnisse wie assets, jni, libs und res können ebenfalls 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.

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)

Datei „Android.mk“

Ändern Sie abschließend die Android.mk-Datei im Stammverzeichnis des Projekts, um den nativen Code zu erstellen und darauf zu verweisen, 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 gekennzeichnet sind.

Änderungen senden

Wählen Sie beim Einreichen von CTS- oder VTS-Patches in AOSP den Entwicklungszweig entsprechend den API-Ebenen aus, auf die der Patch angewendet werden soll.

• Für Änderungen, die auf mehrere API-Ebenen angewendet werden, entwickeln Sie zuerst einen Patch in aosp/main und übernehmen Sie ihn dann selektiv in den obersten Upstream-Test-Branch. Erlauben Sie der automatischen Zusammenführung, die Änderungen in den AOSP-Testzweigen weiter unten zusammenzuführen. Eine Liste der Branches und Informationen zum Pfad für die automatische Zusammenführung finden Sie unter Release-Zeitplan und Informationen zu Branches.
• Entwickeln oder übernehmen Sie Änderungen, die für eine bestimmte API-Ebene spezifisch sind, in den richtigen Testzweig mit DO NOT MERGE oder RESTRICT AUTOMERGE in der Commit-Nachricht.

Folgen Sie dem Workflow zum Einreichen von Patches, um Änderungen an CTS vorzunehmen. Ein Prüfer wird entsprechend mit der Überprüfung Ihrer Änderung beauftragt.

Veröffentlichungszeitplan und Informationen zur Branche

CTS-Releases folgen diesem Zeitplan.

Wichtige Termine während der Veröffentlichung

• Ende der ersten Woche:Code-Freeze. Änderungen, die bis zum Code-Freeze in den Branch zusammengeführt wurden, werden für die nächste Version von CTS berücksichtigt. Einreichungen in den Branch nach dem Code Freeze oder nach der Auswahl eines Release-Kandidaten werden für den nächsten Release berücksichtigt.
• Zweite oder dritte Woche:CTS wird in AOSP veröffentlicht.

Ablauf der automatischen Zusammenführung

CTS-Entwicklungszweige wurden so eingerichtet, dass Änderungen, die für jeden Zweig eingereicht werden, automatisch in höhere Zweige zusammengeführt werden.

Für Änderungen direkt an einem AOSP-Test-Entwicklungszweig lautet der Pfad für die automatische Zusammenführung:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Wenn nur Änderungen an der nächsten Android-Version vorgenommen werden, lautet der Pfad für die automatische Zusammenführung:
aosp-main > <Internal git_main>.

Wenn eine Änderungsliste (CL) 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 die automatische Zusammenführung der konfliktierenden CL zu überspringen.

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