Einfache Build-Konfiguration

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

Soong verwendet Blueprint- oder .bp Dateien, bei denen es sich um JSON-ähnliche einfache deklarative Beschreibungen der zu erstellenden Module handelt. 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 Beispiel-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: ["androidx.test.runner"],
    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 von android_app würde umgekehrt darauf hinweisen, dass es sich stattdessen um ein Build-Paket handelt.

Einstellungen

Die folgenden Einstellungen geben Erklärung:

    name: "HelloWorldTests",

Die name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Es gibt Ihrem Modul einen Namen und die resultierende APK erhält denselben Namen und ein .apk Suffix. In diesem Fall heißt die resultierende Test-Apk beispielsweise HelloWorldTests.apk . Darüber hinaus wird dadurch auch ein Make-Zielname für Ihr Modul definiert, sodass Sie make [options] <HelloWorldTests> verwenden können, um Ihr Testmodul und alle seine Abhängigkeiten zu erstellen.

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

Die Einstellung static_libs weist das Build-System an, die Inhalte der genannten 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 deren Inhalt zum Auflösen von Klassenpfadverweisen während der Kompilierungszeit verwendet und in die resultierende APK integriert wird.

Das Modul androidx.test.runner ist das vorgefertigte Modul für die AndroidX Test Runner Library, die den Test Runner AndroidJUnitRunner enthält. AndroidJUnitRunner unterstützt das JUnit4-Testframework und ersetzt InstrumentationTestRunner in Android 10. Weitere Informationen zum Testen von Android-Apps finden Sie unter Apps auf Android testen .

Wenn Sie ein neues Instrumentierungsmodul erstellen, sollten Sie immer mit der Bibliothek androidx.test.runner als Testläufer 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 erfordert nicht, dass die Test-Apk mit dem speziellen Plattformzertifikat signiert wird.

Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, das heißt, sie ist mehr oder weniger wie eine normale App-Apk verpackt, mit der Ausnahme, dass sie in das System-Image integriert ist und möglicherweise eine privilegierte App ist, ist die Wahrscheinlichkeit groß, dass Ihre Instrumentierung dies tut Zielen Sie auf das App-Paket (siehe Abschnitt unten zum Manifest) Ihrer Komponente. 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 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äßigen integrierten Zertifikat, basierend auf der Build-Variante, und es wird normalerweise als dev-keys bezeichnet.

    test_suites: ["device-tests"],

Durch die Einstellung test_suites ist der Test für die Testumgebung der Trade Federation leicht erkennbar. Hier können weitere Suiten wie CTS hinzugefügt werden, sodass dieser Test gemeinsam genutzt werden kann.

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

Optionale Einstellungen

Die folgenden optionalen Einstellungen sind erläuternd:

    test_config: "path/to/hello_world_test.xml"

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

    auto_gen_config: true

Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll oder nicht. Wenn AndroidTest.xml nicht neben Android.bp vorhanden 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. Dies garantiert, dass der Test mit Root-Berechtigungen ausgeführt wird.

    test_min_api_level: 29

Die Einstellung test_min_api_level weist das Build-System 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 ist.