CTS-Entwicklung

Initialisieren Sie Ihren Repo-Client

Befolgen Sie die Anweisungen unter „Herunterladen der Quelle“ , um den Android-Quellcode abzurufen und zu erstellen. Geben Sie beim Ausgeben des repo init Befehls mit -b einen bestimmten CTS-Zweig an. Dadurch wird sichergestellt, dass Ihre CTS-Änderungen in nachfolgende CTS-Releases übernommen werden.

Der folgende Beispielcode zeigt, wie repo init verwendet wird.

CTS erstellen und ausführen

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

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Geben Sie in der CTS-Konsole Folgendes ein:

tf> run cts --plan CTS

Schreiben Sie CTS-Tests

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

CTS läuft auf vielen Produktionsgeräten, daher müssen die Tests diesen Regeln folgen:

• Berücksichtigen Sie unterschiedliche Bildschirmgrößen, Ausrichtungen und Tastaturlayouts.
• Verwenden Sie nur öffentliche API-Methoden. Mit anderen Worten: Vermeiden Sie alle Klassen, Methoden und Felder mit der Annotation hide .
• Vermeiden Sie die Verwendung von Ansichtslayouts oder verlassen Sie sich auf die Abmessungen von Assets, die auf manchen Geräten möglicherweise nicht vorhanden sind.
• Verlassen Sie sich nicht auf Root-Rechte.

Java-Anmerkung hinzufügen

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

Wenn Ihr Test eine CDD-Anforderung überprüft, kommentieren Sie die Anforderungs-ID (einschließlich CDD-Abschnitts-ID und Anforderungs-ID) mit @CddTest im CTS-Testcode, wie im folgenden Beispiel gezeigt. Erwähnen Sie in Ihrer Commit-Nachricht, welche CDD-Anforderung von Ihrem Test getestet wird, indem Sie auf die CDD-Anforderungs-IDs verweisen. CDD-Anforderungs-IDs sind eine Kombination aus Abschnitts-ID und Anforderungs-ID, verbunden durch einen Schrägstrich (/), wie in 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()));
    }

Kommentieren Sie für CTS Verifier jede Aktivität in Ihrer AndroidManifest.xml mit der entsprechenden CDD-ID. Die Formate für Wertfelder ähneln den Formaten von Java-Annotationen in CTS. Erwähnen Sie in der Commit-Nachricht, 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

Erwähnen Sie deutlich, 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 zu dem Testvorschlag hinzu, den Sie im Rahmen des CTS-D-Einreichungsprozesses in Google Issue Tracker erstellt haben.

Erstellen Sie einen Unterplan

Beispielsweise können Sie 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 den Unterplan aus:

run cts --subplan aSubPlan

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

Benennung und Standort testen

Die meisten CTS-Testfälle zielen auf eine bestimmte Klasse in der Android-API ab. Diese Tests haben Java-Paketnamen mit dem Suffix cts und Klassennamen mit dem Suffix Test . Jeder Testfall besteht aus mehreren Tests, wobei jeder Test typischerweise eine bestimmte Methode der getesteten Klasse ausführt. Diese Tests sind in einer Verzeichnisstruktur angeordnet, in der Tests in verschiedene Kategorien wie „Widgets“ oder „Ansichten“ gruppiert sind.

Beispielsweise lautet der CTS-Test für das Java-Paket android.widget.TextView android.widget.cts.TextViewTest mit dem Java-Paketnamen android.widget.cts und dem Klassennamen TextViewTest .

• Name des Java-Pakets
  Der Java-Paketname für die CTS-Tests ist der Paketname der Klasse, die der Test testet, gefolgt von .cts . In unserem Beispiel wäre der Paketname android.widget.cts .
• Klassenname
  Der Klassenname für CTS-Tests ist der Name der getesteten Klasse mit dem angehängten „Test“. Wenn ein Test beispielsweise auf TextView abzielt, sollte der Klassenname TextViewTest lauten.
• Modulname (nur CTS v2)
  CTS v2 organisiert Tests nach Modul. Der Modulname ist normalerweise die zweite Zeichenfolge 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

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

Die Verzeichnisstruktur in CTS v1-Tests sieht folgendermaßen aus:

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

CTS v2

Für Android 7.0 oder höher verwenden Sie CTS v2. Einzelheiten finden Sie im Beispieltest im Android Open Source Project (AOSP) .

Die CTS v2-Verzeichnisstruktur sieht folgendermaßen aus:

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

Neue Musterpakete

Beim Hinzufügen neuer Tests ist möglicherweise kein Verzeichnis zum Platzieren Ihres Tests vorhanden. 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. Stellen Sie außerdem sicher, dass Sie den Modulnamen Ihres neuen Pakets aus Android.mk zu CTS_COVERAGE_TEST_CASE_LIST in cts/CtsTestCaseList.mk hinzufü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 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. Navigieren Sie zu cts/tests/ module-name und ersetzen Sie alle Instanzen von „[Ss]ample“ durch die oben empfohlene Namenskonvention .
3. Aktualisieren Sie SampleDeviceActivity , um die Funktion auszuführen, die Sie testen.
4. Aktualisieren Sie SampleDeviceTest um sicherzustellen, dass die Aktivität erfolgreich ist oder ihre Fehler protokolliert.

Zusätzliche Verzeichnisse

Andere Android-Verzeichnisse wie assets , jni , „ libs “ und „ res können ebenfalls hinzugefügt werden. Um JNI-Code hinzuzufügen, erstellen Sie im Stammverzeichnis des Projekts neben src ein Verzeichnis mit dem nativen Code und einem Android.mk Makefile.

Das Makefile enthält normalerweise 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 abschließend die Datei Android.mk im Stammverzeichnis des Projekts, um den nativen Code zu erstellen und von ihm 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 reparieren oder entfernen

Zusätzlich zum Hinzufügen neuer Tests können Sie mit BrokenTest oder KnownFailure annotierte Tests reparieren oder entfernen.

Senden Sie Ihre Änderungen

Wenn Sie CTS- oder VTS-Patches in AOSP einreichen, wählen Sie Ihren Entwicklungszweig basierend auf den API-Ebenen aus, für die der Patch gilt.

• Für Änderungen, die sich auf mehrere API-Ebenen auswirken, entwickeln Sie zunächst einen Patch in aosp/main und wählen Sie dann den am weitesten vorgelagerten Testzweig aus. Ermöglichen Sie dem Automerger, die Änderungen nachgelagert in AOSP-Testzweigen zusammenzuführen. Die Liste der Zweige und Informationen zum Automerge-Pfad finden Sie unter Veröffentlichungszeitplan und Zweiginformationen.
• Für Änderungen, die spezifisch für eine bestimmte API-Ebene sind, entwickeln Sie die Änderungen am richtigen Testzweig oder wählen Sie sie aus, indem Sie in der Commit-Nachricht die Option „DO NOT MERGE“ oder „RESTRICT AUTOMERGE“ verwenden.

Befolgen Sie den Workflow zum Einreichen von Patches , um Änderungen an CTS beizutragen. Ein Prüfer wird damit beauftragt, Ihre Änderung entsprechend zu überprüfen.

Veröffentlichungsplan und Brancheninformationen

CTS-Veröffentlichungen folgen diesem Zeitplan.

Wichtige Termine während der Veröffentlichung

• Ende der ersten Woche: Code-Freeze. Änderungen, die bis zum Code-Freeze im Zweig zusammengeführt wurden, werden für die kommende Version von CTS berücksichtigt. Übermittlungen an die Zweigstelle nach dem Einfrieren des Codes oder nachdem ein Kandidat für die Veröffentlichung ausgewählt wurde, werden für die nachfolgende Veröffentlichung berücksichtigt.
• Zweite oder dritte Woche: CTS wird in AOSP veröffentlicht.

Automatischer Zusammenführungsfluss

CTS-Entwicklungszweige wurden so eingerichtet, dass an jeden Zweig übermittelte Änderungen automatisch in höheren Zweigen zusammengeführt werden.

Für Änderungen direkt an einem AOSP-Testentwicklungszweig lautet der Automerge-Pfad:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

Für Änderungen nur an der nächsten Android-Version lautet der Automerge-Pfad:
aosp/main > <Internal git/main> .

Wenn eine Änderungsliste (CL) nicht korrekt zusammengeführt werden kann, erhält der Autor des Patches eine E-Mail mit Anweisungen zur Lösung des Konflikts. In den meisten Fällen kann der Autor des Patches die Anweisungen verwenden, um die automatische Zusammenführung der in Konflikt stehenden CL zu überspringen.

Wenn ein älterer Zweig die Änderung erfordert, muss der Patch aus dem neueren Zweig ausgewählt werden.