Einfache Build-Konfiguration

Für jedes neue Testmodul muss eine Konfigurationsdatei vorhanden sein, die das Build-System anweist mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Anweisungen zur Paketerstellung. Android nutzt jetzt das Soong-Build-System Testkonfiguration.

Soong verwendet Blueprint- oder .bp-Dateien, die eine einfache deklarative JSON-ähnliche Form haben. Beschreibungen der zu erstellenden Module. Dieses Format ersetzt das Make-based-System. in früheren Releases verwendet. Weitere Informationen findest du in den Soong-Referenzdateien. finden Sie im Dashboard für kontinuierliche Integration weitere Informationen.

Wenn Sie benutzerdefinierte Tests ausführen oder die Compatibility Test Suite (CTS) von Android verwenden möchten, folgen Sie stattdessen der Anleitung unter Komplexe Testkonfiguration.

Beispiel

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

Hier ist ein Snapshot für Sie:

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

Die Deklaration android_test am Anfang gibt an, dass es sich um einen Test handelt. Wenn Sie android_app angeben, deutet dies im umgekehrten Fall darauf hin, dass es sich stattdessen um einen Build handelt. Paket.

Einstellungen

Erklärungen zu den folgenden Einstellungen:

    name: "HelloWorldTests",

Die Einstellung name ist erforderlich, wenn der Modultyp android_test angegeben ist (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen und die daraus resultierenden Das APK erhält den gleichen Namen und das Suffix .apk, z.B. in diesem Fall Die resultierende Test-APK hat den Namen HelloWorldTests.apk. Darüber hinaus definiert einen Zielnamen für das Modul, damit Sie das Testmodul und alle zugehörigen Abhängigkeiten mit make [options] <HelloWorldTests> erstellen können.

    static_libs: ["androidx.test.runner"],

Mit der Einstellung static_libs wird das Build-System angewiesen, den Inhalt zu integrieren der benannten Module in die resultierende APK-Datei des aktuellen Moduls. Das bedeutet, dass für jedes benannte Modul eine .jar-Datei erstellt wird. Der Inhalt dieser Datei wird zur Auflösung von Klassenpfadreferenzen während der Kompilierung verwendet und in die resultierende APK eingefügt.

Das Modul androidx.test.runner ist das vorgefertigte Modul für den AndroidX Test Runner Bibliothek, die den Test-Runner AndroidJUnitRunner enthält. AndroidJUnitRunner unterstützt das JUnit4-Test-Framework und hat InstrumentationTestRunner in Android 10 ersetzt. Mehr erfahren zum Testen von Android-Apps finden Sie unter Apps auf Android-Geräten testen.

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

    certificate: "platform",

Die Einstellung certificate weist das Build-System an, die APK-Datei mit derselben als Kernplattform. Dies ist erforderlich, wenn in Ihrem Test eine Signatur verwendet wird geschützte Berechtigung oder API. Diese Option eignet sich für kontinuierliche Testmodule, sollten aber nicht in CTS-Testmodulen verwendet werden. Hinweis: In diesem Beispiel wird diese Zertifikatseinstellung nur zu Veranschaulichungszwecken verwendet. Für den Testcode des Beispiels ist es nicht erforderlich, dass die Test-APK mit dem speziellen Plattformzertifikat signiert ist.

Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, d. h., es ist mehr oder weniger wie ein reguläres App-APK gepackt, mit Ausnahme der Tatsache, dass sie in das System-Image integriert ist und eine privilegierte App ist, ob Ihre Instrumentierung auf das App-Paket ausgerichtet ist (siehe unten zum Manifest) Ihrer Komponente. In diesem Fall hat Ihre Anwendung kann ein Makefile eine eigene certificate-Einstellung haben und Ihre Instrumentierung sollte die Einstellung beibehalten werden. Das liegt daran, dass die Test-APK und die App-APK mit demselben Zertifikat signiert sein müssen, damit die Instrumentierung auf die zu testende App ausgerichtet werden kann.

In anderen Fällen benötigen Sie diese Einstellung gar nicht: beim Build-System wird es einfach mit einem integrierten Standardzertifikat signiert, das auf dem Build basiert. und wird in der Regel als dev-keys bezeichnet.

    test_suites: ["device-tests"],

Durch die Einstellung „test_suites“ ist der Test für Trader leicht zu finden Föderations-Test-Harnisch. Hier können weitere Suiten (z. B. CTS) hinzugefügt werden, Test möglicherweise geteilt werden.

${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, das Ihr Testziel benötigt Konfiguration. Standardmäßig wird neben Android.bp ein AndroidTest.xml die mit der Konfiguration verknüpft sind.

    auto_gen_config: true

Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration erstellt werden soll automatisch. Wenn AndroidTest.xml nicht neben Android.bp vorhanden ist, wird Folgendes angezeigt: muss nicht explizit auf "true" festgelegt werden.

    require_root: true

Mit der Einstellung require_root wird das Build-System angewiesen, RootTargetPreparer hinzuzufügen mit der automatisch generierten Testkonfiguration. Dadurch wird sichergestellt, dass der Test mit Root ausgeführt wird. Berechtigungen.

    test_min_api_level: 29

Mit der Einstellung test_min_api_level wird das Build-System angewiesen, MinApiLevelModuleController auf die automatisch generierte Testkonfiguration hinzu. Beim Handeln Die Föderation führt die Testkonfiguration aus. Der Test wird übersprungen, wenn die Geräteeigenschaft von ro.product.first_api_level < test_min_api_level.