Einfache Build-Konfiguration

Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modul-Metadaten, Kompilierzeit-Abhängigkeiten und Verpackungsanweisungen zu leiten. Android nutzt nun das Soong Build - System für einfachere Testkonfiguration.

Soong verwendet Blueprint oder .bp - Dateien, die sind JSON-wie einfache deklarative Beschreibungen der Module zu bauen. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Siehe die Soong Referenzdateien auf der Continuous Integration - Dashboard für weitere Informationen.

Um benutzerdefinierte Tests oder verwenden Sie das Android aufnehmen Compatibility Test Suite (CTS), folgen Komplexe Testkonfiguration statt.

Beispiel

Die Einträge unter kommen aus diesem 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: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Beachten Sie die android_test Erklärung am Anfang zeigt dies ein Test ist. Einschließlich android_app würde umgekehrt zeigt dieses Paket stattdessen ein Build ist.

Einstellungen

Die folgenden Einstellungen erhalten eine Erklärung:

    name: "HelloWorldTests",

Der name Einstellung ist erforderlich, wenn der android_test Modultyp (zu Beginn des Blockes) angegeben wird. Es gibt einen Namen zu Ihrem Modul und die resultierende APK des gleichen und mit einem Namen wird .apk - Suffix, zB in diesem Fall resultierender Test apk als Namen HelloWorldTests.apk . Darüber hinaus definiert das auch ein Make Zielnamen für Ihr Modul, so dass Sie verwenden können , make [options] <HelloWorldTests> Ihr Testmodul zu bauen und alle seine Abhängigkeiten.

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

Die static_libs instruiert die Bausystem Setzen der Inhalte der genannten Module in die resultierende apk Strommodul zu integrieren. Das bedeutet , dass jede benannte Modul wird erwartet , um eine in der .jar - Datei, und sein Inhalt wird zur Lösung Classpath Referenzen während der Kompilierung, sowie integrierte in die resultierenden apk verwendet werden.

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

Der android-support-test ist die vorkompilierte für den Android - Test - Support Library, die den neuen Test - Runner enthält AndroidJUnitRunner : ein Ersatz für die jetzt eingebauten in veralteten InstrumentationTestRunner , mit Unterstützung für JUnit4 Test - Framework. Lesen Sie mehr bei Test - Apps auf Android .

Wenn Sie ein neues Instrumentierungsmodul bauen, sollten Sie immer mit dem Start android-support-test - Bibliothek als Testläufer. Die Plattform Quellbaum umfasst auch andere nützliche Test Frameworks wie ub-uiautomator , mockito-target , easymock und mehr.

    certificate: "platform",

Das certificate Einstellung weist das Bausystem die apk mit demselben Zertifikat als Kern - Plattform zu unterschreiben. Dies ist erforderlich, wenn Ihr Test eine signaturgeschützte Berechtigung oder API verwendet. Beachten Sie, dass diese für die Plattform kontinuierliche Prüfung geeignet ist, sollte aber nicht in CTS - Testmodulen verwendet werden. Beachten Sie, dass dieses Beispiel diese Zertifikatseinstellung nur zur Veranschaulichung verwendet: Der Testcode des Beispiels muss nicht wirklich 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 verpackt, außer dass sie in das Systemabbild integriert ist und möglicherweise eine privilegierte App ist, besteht die Möglichkeit, dass Ihre Instrumentierung dies tut zielen Sie auf das App-Paket (siehe Abschnitt über Manifest unten) Ihrer Komponente. In diesem Fall kann die Anwendung Make - Datei seine eigenen hat certificate Einstellung und Ihre Instrumentierungsmodul sollten die gleiche Einstellung beibehalten. Dies liegt daran, dass Ihre Test- und App-Apk mit demselben Zertifikat signiert sein müssen, um Ihre Instrumentierung auf die zu testende App auszurichten.

In anderen Fällen müssen Sie diese Einstellung nicht überhaupt haben: das Build - System einfach mit einem Standard unterzeichnen integrierte Zertifikat, bezogen auf der Build - Variante, und es ist in der Regel die genannte dev-keys .

    test_suites: ["device-tests"],

Die test_suites Einstellung macht den Test leicht auffindbar durch Test - Harnisch Trade Federation. Hier können weitere Suiten wie CTS hinzugefügt werden, damit dieser Test geteilt werden kann.

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

Optionale Einstellungen

Die folgenden optionalen Einstellungen erhalten eine Erklärung:

    test_config: "path/to/hello_world_test.xml"

Die test_config Einstellung weist das Build - System Ihr Testziel eine spezifische Konfiguration benötigt. Standardmäßig wird eine AndroidTest.xml neben dem Android.bp mit der Config verbunden.

    auto_gen_config: true

Die auto_gen_config Einstellung zeigt an, ob der Test Config automatisch zu erstellen. Wenn AndroidTest.xml nicht neben dem existieren Android.bp , wird dieses Attribut nicht müssen explizit auf true gesetzt werden.

    require_root: true

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

    test_min_api_level: 29

Die test_min_api_level Einstellung weist das Build - System MinApiLevelModuleController an den automatisch generierten Test Config hinzuzufügen. Wenn Trade Federation den Test Config ausgeführt wird , wird der Test , ob das Gerät Eigentum von übersprungenen sein ro.product.first_api_level < test_min_api_level .