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.
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:
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:
API-Typ | Anmerkungsformat | Anmerkungen |
---|---|---|
Methode | android.example.ClassA#methodA | Der häufigste Anwendungsfall. |
Methode mit Schlüsselwerten | android.example.ClassB#methodB(KeyA) | Verwenden Sie dies nur, wenn Ihr Test eine API-Methode zum Validieren eines Felds verwendet, wie in diesem Beispiel. |
Feld | android.example.ClassC#FieldA | Verwenden Sie dies nur, wenn Ihr Test ein API-Feld direkt validiert, wie in diesem Beispiel. |
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 Paketnameandroid.widget.cts
. - Klassenname
Der Klassenname für CTS-Tests ist der Name der getesteten Klasse mit dem angehängten „Test“. Wenn ein Test beispielsweise aufTextView
abzielt, sollte der KlassennameTextViewTest
lauten. - Modulname (nur CTS v2)
CTS v2 organisiert Tests nach Modul. Der Modulname ist normalerweise die zweite Zeichenfolge des Java-Paketnamens (in unserem Beispielwidget
).
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:
- 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
- Navigieren Sie zu
cts/tests/ module-name
und ersetzen Sie alle Instanzen von „[Ss]ample“ durch die oben empfohlene Namenskonvention . - Aktualisieren Sie
SampleDeviceActivity
, um die Funktion auszuführen, die Sie testen. - 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.
Ausführung | API-Ebene | Zweig | Frequenz |
---|---|---|---|
14 | 34 | android14-tests-dev | Vierteljährlich |
13 | 33 | android13-tests-dev | Vierteljährlich |
12L | 32 | android12L-tests-dev | Vierteljährlich |
12 | 31 | android12-tests-dev | Vierteljährlich |
11 | 30 | android11-tests-dev | Vierteljährlich |
Für die Versionen 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 und 4.2 sind keine weiteren Veröffentlichungen geplant. |
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.