Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

CTS-Hilfemodul für die Geräteinteraktion

Unter Android 11 oder höher können Sie mit den CTS-Helfermodulen (Compatibility Test Suite) für die Geräteinteraktion anpassen, wie bestimmte CTS-Tests mit der Benutzeroberfläche auf einem bestimmten Gerät interagieren. Das bedeutet, dass Aktionen wie das Ersetzen eines UI-Elements, das nicht im Android Compatibility Definition Document (CDD) oder in der API-Dokumentation enthalten ist, ausgeführt werden können, ohne dass der CTS fehlschlägt.

OEMs, die die Android-Benutzeroberfläche während der Produktentwicklung anpassen und den CTS bestehen müssen, können möglicherweise Hilfsmodule implementieren. Wenn Sie die Standardimplementierung für Android verwenden, ist keine zusätzliche Arbeit erforderlich.

Hilfsmodule implementieren

Voraussetzungen für die Anpassung der Benutzeroberfläche

Prüfen Sie das CDD oder die Mainline-Module auf UI-Anforderungen. Wenn die gewünschte Benutzeroberfläche durch das CDD oder Mainline-Module abgedeckt wird, kann sie nicht angepasst werden.

Wenn die CTS-Tests, die mit der gewünschten Benutzeroberfläche interagieren, das Hilfsframework nicht verwenden, kann diese Benutzeroberfläche nicht angepasst werden. Arbeiten Sie mit dem Testinhaber zusammen, um das Testmodul zu konvertieren, bevor die Benutzeroberfläche geändert werden kann.

Andernfalls können Sie die Benutzeroberfläche anpassen.

Implementierungsworkflow

Passen Sie die Benutzeroberfläche nach Bedarf an Ihr Produkt an.
Weisen Sie die vorhandenen AOSP-Hilfsmodule als Unterklassen für die CTS-Testmodule zu, die mit der Benutzeroberfläche interagieren müssen. Ersetzen Sie die erforderlichen Interaktionen entsprechend für die angepasste Benutzeroberfläche. Die Ersetzungen variieren je nach Art der Änderungen.
- Die OEM-Unterklassen befinden sich in einem OEM-Paket, z. B. com.[oem].cts.helpers.
- Jede OEM-Unterklasse hat ein gemeinsames Präfix, das sie von der AOSP-Implementierung mit dem Präfix Default unterscheidet.
Erstellen Sie die Hilfsprogramme in einer APK-Datei, die den folgenden Testrunner-Konventionen entspricht.
- In Android.bp sollte android_test_helper_app mit demselben Namen wie das enthaltene Paket deklariert werden.
- In der AndroidManifest.xml für das APK muss eine Metadateneigenschaft mit dem Namen interaction-helpers-prefix und dem Wert des im vorherigen Aufzählungspunkt ausgewählten Klassenpräfixes deklariert werden.
- Die App sollte von cts-helpers-core, cts-helpers-interfaces und com.android.cts.helpers.aosp abhängen. Wenn die OEM-Helfer alle relevanten Schnittstellen vollständig implementieren, ist com.android.cts.helpers.aosp optional.
Legen Sie die Eigenschaft ro.vendor.cts_interaction_helper_packages im Gerätebild fest, um den Namen des APK einzufügen. Wenn Sie Ihre Helper-Implementierungen auf mehrere APKs aufteilen müssen, kann diese Property eine durch Doppelpunkte getrennte Liste von Paketen enthalten.
Achten Sie darauf, dass die APK-Datei im Verzeichnis testcases verfügbar ist, wenn Sie Tradefed für CTS ausführen. Prüfen Sie anhand von logcat-Nachrichten, ob die erwartete Helferimplementierungsklasse ausgewählt wurde.
Optional, aber sehr empfehlenswert: Reichen Sie Ihre Helper-Implementierung bei AOSP ein oder stellen Sie sie für Tests durch Drittanbieter zur Verfügung.

Beispielimplementierung des Helpers

Für CtsPrintTestCases wird beispielsweise ein Helper mit der in ICtsPrintHelper definierten Schnittstelle erwartet. Die AOSP-Implementierung heißt com.android.cts.helpers.aosp.DefaultCtsPrintHelper.

Wenn Sie die Druck-UI anpassen, können Sie com.oem.cts.helpers.OemCtsPrintHelper erstellen, die Unterklassen von DefaultCtsPrintHelper sind. android_test_helper_app in Android.bp wird com.oem.cts.helpers genannt, was com.oem.cts.helpers.apk ergibt, und deklariert interaction-helpers-prefix als Oem in AndroidManifest.xml.

Die Geräte-Property ro.vendor.cts_interaction_helper_packages ist auf com.oem.cts.helpers festgelegt.

Referenzimplementierungen

Referenzimplementierungen umfassen Schnittstellen unter cts/libs/helpers und die standardmäßigen AOSP-Helfer unter cts/helpers. Die Schnittstelle der obersten Ebene ist unter cts/libs/helpers/core/src/com/android/cts/helpers/ICtsDeviceInteractionHelper.java dokumentiert.

Um den CTS-Test mit seinen Helfern zu verbinden, können Testinhaber die in cts/libs/helpers/core/src/com/android/cts/helpers/DeviceInteractionHelperRule.java dokumentierte @Rule-Definition verwenden.

Jedes CTS-Modul, das das Framework und das erwartete Verhalten der zugehörigen Hilfsprogramme verwendet, wird in einer Schnittstelle dokumentiert, die unter cts/libs/helpers/core/src/com/android/cts/helpers definiert ist.

CTS-Tests ausführen

Ohne Helfer testen

Abgesehen von einer Eigenschaft ist die Option zum Testen ohne Helfer nicht zur Laufzeit auf dem Gerät verfügbar. Sie ändert jedoch optional, wie CTS-Tests mit dem Gerät interagieren. Wenn Sie CTS ohne die Helferimplementierungen ausführen müssen, haben Sie zwei Möglichkeiten:

Entfernen Sie die ro.vendor.cts_interaction_helper_packages-Property vom Gerät. Dadurch wird verhindert, dass die Helfer für diesen Build verwendet werden.
Entfernen Sie die Helper-APK aus dem Verzeichnis testcases, bevor Sie CTS ausführen. Dadurch wird verhindert, dass die Hilfsprogramme von Läufen verwendet werden, bis die APK auf testcases zurückgesetzt wurde.

Sie können die Standardeinstellungen mit Tradefed-Argumenten und der ro.vendor.cts_interaction_helper_packages-Attributsteuerung ändern, über die die Helper-APK geladen wird.

Im Folgenden finden Sie die erwarteten Werte oder Bereiche für die einzelnen verfügbaren Einstellungen.

ro.vendor.cts_interaction_helper_packages ist ein durch Doppelpunkte getrennter String mit Paketnamen. Er kann einen beliebigen Wert annehmen, der eine gültige Paketauswahl für die Helper-Implementierung des OEM ist.
cts-tradefed akzeptiert ein device-interaction-helper:property-name-Argument, mit dem die erwartete Property für einen Testlauf vorübergehend geändert wird, z. B. --module-arg 'CtsPrintTestCases:{device-interaction-helper}property-name:debug.cts.hlp'. Der Wert des Attributnamens kann ein beliebiges Attribut sein, das Sie auf dem Gerät festlegen. Für den Wert der Property gelten dieselben Einschränkungen wie für die oben beschriebene Property ro.vendor.cts_interaction_helper_packages.

Mit Anpassungen testen

Standardmäßig bestehen Referenzimplementierungen den CTS auf Stock-Android. Prüfen Sie, ob Partnerimplementierungen den CTS-Test mit UI-Anpassungen bestehen. Führen Sie die CTS-Module aus, die die von Ihnen angepasste Benutzeroberfläche oder die von Ihnen angepassten Funktionen abdecken.

Einige CTS-Module oder ‑Helfer unterstützen bestimmte Anpassungen möglicherweise noch nicht.

Ein CTS-Modul, das mit der Benutzeroberfläche interagiert, die Sie anpassen möchten, verwendet möglicherweise nicht das Hilfs-Framework. CTS-Module sollen je nach Bedarf und Prioritäten des Testinhabers in das Hilfs-Framework konvertiert werden. Stellen Sie frühzeitig im Prozess Dateianfragen für die Konvertierung, damit die Konvertierung wie geplant durchgeführt wird. Das ist ähnlich wie bei CTS-Änderungen zur Unterstützung Ihrer geplanten Funktionen.
Die von einem vorhandenen Helfer bereitgestellten Funktionen decken möglicherweise nicht alle gewünschten Anpassungen ab. Hilfsfunktionen sollten UI-Abhängigkeiten abstrahieren. Wenn eine Hilfsfunktion indirekt eine UI-Abhängigkeit hat, kann dies ähnlich wie bei Fehlern im CTS behandelt werden.

CTS-Hilfemodul für die Geräteinteraktion Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.