Einfache Build-Konfiguration

Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Paketierungsanweisungen zu steuern. Android verwendet jetzt das Soong-Build-System für eine einfachere Testkonfiguration.

Soong verwendet Blueprint- oder .bp -Dateien, die JSON-ähnliche einfache deklarative Beschreibungen von zu erstellenden Modulen sind. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard .

Um benutzerdefinierte Tests durchzuführen oder die Android Compatibility Test Suite (CTS) zu verwenden, befolgen Sie stattdessen die komplexe Testkonfiguration .

Beispiel

Die folgenden Einträge stammen aus dieser beispielhaften Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp

Der Einfachheit halber ist hier ein Schnappschuss enthalten:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Beachten Sie, dass die android_test Deklaration am Anfang darauf hinweist, dass es sich um einen Test handelt. Das Einschließen android_app würde umgekehrt anzeigen, dass es sich stattdessen um ein Build-Paket handelt.

Einstellungen

Die folgenden Einstellungen werden erklärt:

    name: "HelloWorldTests",

Die name ist erforderlich, wenn der android_test angegeben wird (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen, und die resultierende APK wird genauso benannt und mit einem .apk Suffix versehen, z. B. in diesem Fall wird die resultierende Test-APK als HelloWorldTests.apk bezeichnet. Darüber hinaus definiert dies auch einen Make-Zielnamen für Ihr Modul, sodass Sie make [options] <HelloWorldTests> verwenden können, um Ihr Testmodul und alle seine Abhängigkeiten zu erstellen.

    static_libs: ["android-support-test"],

Die Einstellung static_libs weist das Build-System an, den Inhalt der benannten Module in die resultierende apk des aktuellen Moduls zu integrieren. Das bedeutet, dass von jedem benannten Modul erwartet wird, dass es eine .jar -Datei erzeugt, und sein Inhalt wird zum Auflösen von Klassenpfadreferenzen während der Kompilierzeit verwendet und in die resultierende apk integriert.

In diesem Beispiel Dinge, die allgemein für Tests nützlich sein könnten:

Der android-support-test ist vorgefertigt für die Android Test Support Library, die den neuen AndroidJUnitRunner : ein Ersatz für den inzwischen veralteten integrierten InstrumentationTestRunner mit Unterstützung für das JUnit4-Testframework. Lesen Sie mehr unter Apps auf Android testen .

Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der android-support-test Bibliothek als Testrunner beginnen. Der Plattform-Quellbaum enthält auch andere nützliche Test-Frameworks wie ub-uiautomator , mockito-target , easymock und mehr.

    certificate: "platform",

Die certificate weist das Build-System an, die APK mit demselben Zertifikat wie die Kernplattform zu signieren. Dies ist erforderlich, wenn Ihr Test eine signaturgeschützte Berechtigung oder API verwendet. Beachten Sie, dass dies für kontinuierliche Plattformtests geeignet ist, aber nicht in CTS-Testmodulen verwendet werden sollte. Beachten Sie, dass dieses Beispiel diese Zertifikatseinstellung nur zur Veranschaulichung verwendet: Der Testcode des Beispiels muss eigentlich nicht mit dem speziellen Plattformzertifikat signiert werden.

Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h. sie ist mehr oder weniger wie eine normale App-APK gepackt, außer dass sie in das System-Image integriert ist und möglicherweise eine privilegierte App ist, besteht die Möglichkeit, dass Ihre Instrumentierung dies tut auf das App-Paket (siehe unten Abschnitt über Manifest) Ihrer Komponente abzielen. In diesem Fall verfügt Ihr Anwendungs-Makefile möglicherweise über eine eigene certificate , und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Dies liegt daran, dass Ihre Test-APK und Ihre App-APK mit demselben Zertifikat signiert sein müssen, um Ihre Instrumentierung auf die zu testende App auszurichten.

In anderen Fällen benötigen Sie diese Einstellung überhaupt nicht: Das Build-System signiert es einfach mit einem standardmäßig integrierten Zertifikat, das auf der Build-Variante basiert und normalerweise als dev-keys bezeichnet wird.

    test_suites: ["device-tests"],

Die Einstellung test_suites macht den Test für die Trade Federation-Testumgebung leicht auffindbar. Andere Suiten wie CTS können hier hinzugefügt werden, damit dieser Test geteilt werden kann.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Optionale Einstellungen

Die folgenden optionalen Einstellungen werden erklärt:

    test_config: "path/to/hello_world_test.xml"

Die Einstellung test_config weist das Build-System an, dass Ihr Testziel eine bestimmte Konfiguration benötigt. Standardmäßig ist eine AndroidTest.xml neben Android.bp mit der Konfiguration verknüpft.

    auto_gen_config: true

Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll oder nicht. Wenn neben AndroidTest.xml keine Android.bp ist, muss dieses Attribut nicht explizit auf true gesetzt werden.

    require_root: true

Die Einstellung require_root weist das Build-System an, RootTargetPreparer zur automatisch generierten Testkonfiguration hinzuzufügen. Dadurch wird garantiert, dass der Test mit Root-Berechtigungen ausgeführt wird.

    test_min_api_level: 29

Die Einstellung test_min_api_level weist das Buildsystem an, MinApiLevelModuleController zur automatisch generierten Testkonfiguration hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn die Geräteeigenschaft von ro.product.first_api_level < test_min_api_level .