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.

Um benutzerdefinierte Tests zu ermöglichen oder die Android Compatibility Test Suite (CTS), folgen Sie Komplexe Testkonfiguration .

Beispiel

Die folgenden Einträge stammen aus dieser Blueprint-Beispielkonfigurationsdatei: /platform_testing/tests/beispiel/instrumentation/Android.bp

Der Einfachheit halber finden Sie hier eine Übersicht:

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 Es wird erwartet, dass jedes benannte Modul eine .jar-Datei erstellt und ihr Inhalt zum Auflösen von Klassenpfadreferenzen während der Kompilierungszeit sowie in die resultierende APK-Datei integriert.

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 ersetzt InstrumentationTestRunner in Android 10. Mehr erfahren zum Testen von Android-Apps finden Sie unter Apps auf Android-Geräten testen.

Wenn du ein neues Instrumentierungsmodul entwickelst, die androidx.test.runner-Bibliothek als Test-Runner verwenden. Quellstruktur der Plattform enthält auch andere nützliche Test-Frameworks wie ub-uiautomator, mockito-target, easymock und weitere.

    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. In diesem Beispiel verwendet diese Zertifikatseinstellung nur zur Veranschaulichung: Der Testcode des Beispiels muss die Test-APK-Datei nicht mit dem ein spezielles Plattformzertifikat.

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. Der Grund dafür ist, dass Sie Instrumentierung in der zu testenden App müssen Ihre Test-APK und App-APKs signiert sein. mit demselben Zertifikat.

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.