Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Build-System mit Modulmetadaten, Kompilierzeitabhängigkeiten und Verpackungsanweisungen zu versorgen. Android verwendet jetzt das Soong-Build-System für eine einfachere Testkonfiguration.
Soong verwendet Blueprint- oder .bp-Dateien. Das sind JSON-ähnliche einfache deklarative Beschreibungen von Modulen, die erstellt werden sollen. Dieses Format ersetzt das Make-basierte System, das in früheren Versionen verwendet wurde. Vollständige Informationen finden Sie in den Soong-Referenzdateien
im Continuous Integration Dashboard.
Wenn Sie benutzerdefinierte Tests durchführen oder die Android Compatibility Test Suite (CTS) verwenden möchten, folgen Sie Komplexe Testkonfiguration stattdessen.
Beispiel
Die Einträge unten stammen aus dieser Blueprint-Konfigurationsdatei: /platform_testing/tests/example/instrumentation/Android.bp
Hier ist ein Snapshot zur Veranschaulichung:
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 zeigt an, dass es sich um einen Test handelt.
Wenn Sie android_app einfügen, wird stattdessen angegeben, dass es sich um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen werden erläutert:
name: "HelloWorldTests",
Die Einstellung name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Dadurch wird Ihrem Modul ein Name gegeben.Die resultierende
APK-Datei hat denselben Namen und das Suffix .apk. In diesem Fall heißt die
resultierende Test-APK-Datei HelloWorldTests.apk. Außerdem wird dadurch ein Make-Zielname für Ihr Modul definiert, sodass Sie mit make [options]
<HelloWorldTests> Ihr Testmodul und alle seine Abhängigkeiten erstellen können.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, die Inhalte der genannten Module in die resultierende APK-Datei des aktuellen Moduls aufzunehmen. Das bedeutet, dass jedes genannte Modul eine .jar-Datei erzeugen muss. Der Inhalt wird verwendet, um Klassenpfadverweise während der Kompilierung aufzulösen und in die resultierende APK-Datei aufgenommen.
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-Test-Framework und hat in Android 10 InstrumentationTestRunner ersetzt. 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 Test Runner beginnen. Der Quellbaum der Plattform enthält auch andere nützliche Test-Frameworks wie ub-uiautomator, mockito-target und easymock.
certificate: "platform",
Die Einstellung certificate weist das Build-System an, die APK-Datei mit demselben Zertifikat wie die Kernplattform zu signieren. Das ist erforderlich, wenn Ihr Test eine signaturschutzgeschützte Berechtigung oder API verwendet. Diese Einstellung eignet sich für kontinuierliche Plattformtests, sollte aber nicht in CTS-Testmodulen verwendet werden. In diesem Beispiel wird diese Zertifikateinstellung nur zur Veranschaulichung verwendet. Der Testcode des Beispiels erfordert nicht, dass die Test-APK-Datei mit dem speziellen Plattformzertifikat signiert wird.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die sich außerhalb des Systemservers befindet, d. h., sie wird mehr oder weniger wie eine reguläre App-APK-Datei verpackt, aber in das Systemimage integriert und ist möglicherweise eine privilegierte App, zielt Ihre Instrumentierung wahrscheinlich auf das App-Paket (siehe Abschnitt zum Manifest unten) Ihrer Komponente ab. In diesem Fall hat die Make-Datei Ihrer Anwendung möglicherweise eine eigene certificate-Einstellung und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. Damit Ihre Instrumentierung auf die zu testende App ausgerichtet werden kann, müssen Ihre Test-APK-Datei und die App-APK-Datei mit demselben Zertifikat signiert sein.
In anderen Fällen ist diese Einstellung überhaupt nicht erforderlich. Das Build-System signiert sie einfach mit einem standardmäßigen integrierten Zertifikat, das auf der Build-Variante basiert und in der Regel dev-keys genannt wird.
test_suites: ["device-tests"],
Mit der Einstellung test_suites kann die Test-Suite leicht von der Trade Federation-Test-Suite gefunden werden. Hier können weitere Test-Suites wie CTS hinzugefügt werden, damit dieser Test freigegeben werden kann.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Optionale Einstellungen
Die folgenden optionalen Einstellungen werden erläutert:
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-Datei neben der Android.bp-Datei mit der Konfiguration verknüpft.
auto_gen_config: true
Die Einstellung auto_gen_config gibt an, ob die Testkonfiguration automatisch erstellt werden soll. 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. 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 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 ro.product.first_api_level < test_min_api_level ist.