CTS-Entwicklung

Repo-Client initialisieren

Folgen Sie der Anleitung unter Quellcode herunterladen, um den Android-Quellcode abzurufen und zu erstellen. Geben Sie beim Ausführen des Befehls repo init mit -b einen bestimmten CTS-Zweig an. Dadurch wird sichergestellt, dass Ihre CTS-Änderungen in nachfolgende CTS-Releases aufgenommen.

Der folgende Beispielcode zeigt, wie repo init verwendet werden muss.

CTS erstellen und ausführen

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

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:

CTS ausführen

Geben Sie in der CTS-Konsole Folgendes ein:

tf> run cts --plan CTS

CTS-Tests schreiben

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. Beachten Sie daher beim Schreiben von Tests Folgendes:

• 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 im Feld apis alle beteiligten APIs auf. Verwenden Sie das passende Format aus den folgenden Beispielen:

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 als Anmerkung versehen. Die Formate für Wertfelder ähneln den Formaten von Java-Annotationen in CTS. Geben Sie in der Commit-Nachricht an, welche CDD-Anforderung durchgesetzt 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 deutlich an, warum Ihr Test hinzugefügt werden muss, und fügen Sie relevante Links für den Support hinzu. Bei CTS-D-Tests fügen Sie einen Link zum Testvorschlag ein, den Sie im Rahmen des CTS-D-Einreichungsprozesses in Google Issue Tracker erstellt haben.

Teilplan erstellen

Eine SubPlan.xml-Datei können Sie beispielsweise so in android-cts/subplans 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 den Teilplan aus:

run cts --subplan aSubPlan

Der Teilplaneintrag hat das folgende Format:

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 Testlauf 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 CTS v1 für Android 6.0 oder niedriger. 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 CTS v2 für Android 7.0 oder höher. 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 Beispielpakete

Wenn Sie neue Tests hinzufügen, gibt es möglicherweise kein vorhandenes 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, 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 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. Führen Sie zum Erstellen des Testverzeichnisses und Kopieren der Beispieldateien folgenden Befehl aus:

   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“ unter Berücksichtigung der empfohlenen Namenskonvention oben.
3. Aktualisieren Sie SampleDeviceActivity, um die zu testende Funktion auszuführen.
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 als Letztes die Datei Android.mk im Stammverzeichnis des Projekts, um den nativen Code zu erstellen und entsprechende Abhängigkeiten festzulegen, 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 als Anmerkung versehen sind.

Änderungen senden

Wenn Sie Änderungen an CTS vornehmen, folgen Sie dem Workflow Codeänderungen senden.

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

Für CTS-Releases gilt der folgende Zeitplan.

Wichtige Termine während der Veröffentlichung

• Ende der ersten Woche: Code-Freeze. Änderungen, die bis zum Code-Freeze in den Zweig übernommen werden, werden für die nächste CTS-Version berücksichtigt. Beiträge zum Zweig nach dem Code-Freeze oder nach Auswahl eines Release-Kandidaten werden für das darauffolgende Release berücksichtigt.
• Zweite oder dritte Woche: CTS wird auf der Seite Compatibility Test Suite-Downloads veröffentlicht.

Automatische Übernahme (Automerge)

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

Bei Änderungen direkt an einem AOSP-Testentwicklungszweig sieht der Pfad für die automatische Übernahme so aus:
android13-tests-dev > android14-tests-dev > android15-tests-dev

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

Wenn eine Änderungsliste nicht richtig übernommen 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 Übernahme der in Konflikt stehenden Änderungsliste zu überspringen.

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

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