CTS-Entwicklung

Repository-Client initialisieren

Folgen Sie der Anleitung unter Quelle herunterladen, um und den Android-Quellcode erstellen. Wenn Sie den Befehl repo init ausführen, geben Sie eine bestimmten CTS-Zweig mithilfe von -b. Dadurch wird sichergestellt, dass Ihre CTS-Änderungen in nachfolgenden CTS-Versionen.

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:

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

CTS-Tests schreiben

CTS-Tests verwenden JUnit und die Android-Test-APIs. Lesen Sie die Testen Ihre App und vorhandene Tests im Verzeichnis cts/tests. CTS-Tests folgen größtenteils denselben Konventionen wie bei anderen Android-Tests.

CTS kann auf vielen Produktionsgeräten ausgeführt werden, daher müssen die Tests diese Regeln:

• Berücksichtigen Sie unterschiedliche Bildschirmgrößen, -ausrichtungen und -tastaturlayouts.
• Verwenden Sie nur öffentliche API-Methoden. Vermeiden Sie also alle Klassen, Methoden und Felder. durch die Annotation hide.
• Vermeiden Sie es, Ansichtslayouts zu verwenden oder sich auf die Abmessungen von Assets zu verlassen, die in einigen Geräte.
• Verlassen Sie sich nicht auf Root-Berechtigungen.

Java-Annotation hinzufügen

Wenn Ihr Test ein API-Verhalten bestätigt, annotieren Sie den Testcode mit @ApiTest und listen Sie allen APIs, die im Feld apis beteiligt sind. Verwenden Sie das entsprechende Format aus den folgende Beispiele:

Wenn Ihr Test eine CDD-Anforderung bestätigt, geben Sie die Anforderungs-ID (einschließlich CDD-Abschnitt) an ID und Anforderungs-ID) mit @CddTest im CTS-Testcode, wie in der folgenden Beispiel. Geben Sie in der Commit-Nachricht an, welche CDD-Anforderung von Ihrem indem Sie sich auf die CDD-Anforderungs-IDs beziehen. CDD-Anforderungs-IDs sind eine Kombination aus Abschnitts-IDs 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()));
    }

Vermerken Sie für CTS Verifier jede Aktivität in Ihrer AndroidManifest.xml mit dem relevante CDD-ID. Die Formate für Wertfelder ähneln den Formaten von Java-Annotationen in CTS Geben Sie in der Commit-Nachricht an, welche CDD-Anforderung durch Verweis auf die CDD erzwungen wird. Anforderungs-ID.

  <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

Erläutern Sie deutlich, warum Ihr Test hinzugefügt werden muss, und fügen Sie relevante Links für den Support hinzu. Für CTS-D Tests einen Link zum Testvorschlag, den Sie im Rahmen des das CTS-D-Übermittlungsverfahren.

Teilplan erstellen

Sie können beispielsweise eine SubPlan.xml-Datei in android-cts/subplans so:

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

Für den Teilplaneintrag gilt folgendes 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" />

Namen 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 einem Test-Suffix. Jeder Testfall besteht aus mehreren Tests, wobei jeder Testlauf test führt in der Regel eine bestimmte Methode der zu testenden Klasse aus. Diese Tests sind in einer Verzeichnisstruktur angeordnet, in der verschiedene Kategorien wie "Widgets" oder „Aufrufe“.

Der CTS-Test für das Java-Paket android.widget.TextView ist android.widget.cts.TextViewTest mit dem entsprechenden Java-Paketnamen als android.widget.cts und der zugehörige Klassenname als TextViewTest.

• Name des Java-Pakets
  Der Name des Java-Pakets 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 Klasse, die mit „Test“ getestet wird angehängt wird. Für Wenn ein Test beispielsweise auf TextView abzielt, sollte der Klassenname so lauten: TextViewTest.
• Modulname (nur CTS v2)
  CTS v2 organisiert die Tests nach Modulen. 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 verwenden. oder CTS v2.

CTS Version 1

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

Verwenden Sie für Android 7.0 oder höher CTS v2. Weitere Informationen finden Sie auf der 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, ist möglicherweise kein Verzeichnis vorhanden, in dem sich Ihr testen. In diesen Fällen müssen Sie das Verzeichnis erstellen und die Datei entsprechenden Beispieldateien.

CTS Version 1

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

CTS Version 2

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

1. Führen Sie folgenden Befehl 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 „[Beispiel]“ mit dem empfohlene Namenskonvention oben.
3. Aktualisiere SampleDeviceActivity, um die Funktion zu nutzen, die du testest.
4. Aktualisieren Sie SampleDeviceTest, um sicherzustellen, dass die Aktivität erfolgreich ist oder protokolliert wird Fehler beheben.

Zusätzliche Verzeichnisse

Andere Android-Verzeichnisse wie assets, jni, Es können auch libs und res hinzugefügt werden. Um JNI-Code hinzuzufügen, Erstellen Sie im Stammverzeichnis des Projekts neben src ein Verzeichnis mit der nativen Code und ein 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 schließlich die Datei Android.mk im Stammverzeichnis des um den nativen Code zu erstellen, und hängen Sie davon ab:

# 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, Entfernen Sie Tests, die mit BrokenTest oder KnownFailure gekennzeichnet sind.

Änderungen senden

Wählen Sie beim Einreichen von CTS- oder VTS-Patches in AOSP Ihren Entwicklungszweig aus je nachdem, auf welche API-Ebenen der Patch angewendet wird.

• Bei Änderungen, die sich auf mehrere API-Ebenen beziehen, zuerst Entwickeln Sie ein Patch in aosp/main und wählen Sie dann die besten Upstream-Testzweig. Zulassen, dass die automatische Zusammenführung die Änderungen nachgelagert in AOSP-Testzweige. Weitere Informationen finden Sie unter Veröffentlichungszeitplan und -zweiginformationen für die Liste der und automatisch zusammengeführte Pfadinformationen.
• Für Änderungen, die für ein bestimmtes API-Level spezifisch sind, musst du eine Entwicklung oder eine gezielte Auswahl übernehmen. die Änderungen zum richtigen Testzweig mit DO NOT MERGE oder RESTRICT AUTOMERGE in der Commit-Nachricht ein.

Folgen Sie dem Workflow zum Senden von Patches. um Änderungen an CTS beizutragen. Ein Prüfer wird Ihre Änderung entsprechend prüfen.

Releasezeitplan und Zweiginformationen

CTS-Releases folgen diesem Zeitplan.

Wichtige Termine während der Veröffentlichung

• Ende der ersten Woche:Code Freeze. Änderungen im Zweig zusammengeführt bis die Code-Freeze für die neue Version von CTS in Betracht gezogen wird. Einreichungen beim Branch nach dem Code-Freeze oder nach einem Kandidaten für Release ausgewählt wurde, werden für den nachfolgenden Release berücksichtigt.
• Zweite oder dritte Woche: CTS wird veröffentlicht in AOSP:

Ablauf automatisch zusammenführen

Die CTS-Entwicklungszweige wurden so eingerichtet, dass Änderungen an jedem automatisch mit höheren Zweigen verbunden.

Für Änderungen, die direkt an einem AOSP-Testentwicklungszweig vorgenommen werden, lautet der Pfad für die automatische Zusammenführung:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

Nur für Änderungen an der nächsten Android-Version lautet der Pfad für die automatische Zusammenführung
. aosp/main > <Internal git/main>

Wenn eine Änderungsliste (CL) nicht korrekt zusammengeführt wird, wird der Patch-Autor gesendet. eine E-Mail mit Anweisungen zur Lösung des Konflikts. In den meisten kann der Ersteller des Patches mithilfe der Anleitung die automatische Zusammenführung das in Konflikt stehende CL.

Wenn ein älterer Zweig die Änderung erfordert, muss der Patch aus dem neueren Zweig gepflückt.