Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Buildsystem mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Verpackungsanweisungen zu steuern. Android verwendet jetzt das Soong-Buildsystem für eine einfachere Testkonfiguration.
Soong verwendet Blueprint- oder .bp-Dateien, die JSON-ähnliche einfache deklarative Beschreibungen von zu erstellenden Modulen sind. Dieses Format ersetzt das markenbasierte System, das in früheren Releases verwendet wurde. Ausführliche Informationen finden Sie in den Soong-Referenzdateien im Continuous Integration Dashboard.
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.
Verwendungsbeispiele
Die folgenden Einträge stammen aus dieser Beispiel-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 gibt an, dass es sich um einen Test handelt.
Wenn Sie android_app angeben, wird dagegen angezeigt, dass es sich um ein Build-Paket handelt.
Einstellungen
Die folgenden Einstellungen erfordern eine Erklärung:
name: "HelloWorldTests",
Die Einstellung name ist erforderlich, wenn der Modultyp android_test angegeben wird (am Anfang des Blocks). Damit wird Ihrem Modul ein Name zugewiesen.Die resultierende APK hat denselben Namen mit dem Suffix .apk. In diesem Fall heißt die resultierende Test-APK beispielsweise HelloWorldTests.apk. Außerdem wird dadurch ein Make-Zielname für Ihr Modul definiert, sodass Sie make [options]
<HelloWorldTests> verwenden können, um Ihr Testmodul und alle zugehörigen Abhängigkeiten zu erstellen.
static_libs: ["androidx.test.runner"],
Die Einstellung static_libs weist das Build-System an, den Inhalt der genannten Module in die resultierende APK des aktuellen Moduls einzubinden. Das bedeutet, dass für jedes benannte Modul eine .jar-Datei erstellt wird. Der Inhalt dieser Datei wird zur Auflösung von Klassenpfadverweisen während der Kompilierung verwendet und in die resultierende APK eingefügt.
Das Modul androidx.test.runner ist die vorkonfigurierte AndroidX Test Runner Library, die den Test-Ausführer AndroidJUnitRunner enthält.
AndroidJUnitRunner unterstützt das JUnit4-Test-Framework und hat InstrumentationTestRunner in Android 10 ersetzt. Weitere Informationen 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 mit demselben Zertifikat wie die Hauptplattform zu signieren. Dies ist erforderlich, wenn in Ihrem Test eine signaturgeschützte Berechtigung oder API verwendet wird. Diese Methode eignet sich für kontinuierliche Plattformtests, sollte aber nicht in CTS-Testmodulen verwendet werden. Hinweis: In diesem Beispiel wird diese Zertifikatseinstellung nur zu Veranschaulichungszwecken verwendet. Für den Testcode des Beispiels muss die Test-APK nicht mit dem speziellen Plattformzertifikat signiert sein.
Wenn Sie eine Instrumentierung für Ihre Komponente schreiben, die nicht auf dem Systemserver ausgeführt wird, d. h., sie ist mehr oder weniger wie eine normale App-APK verpackt, mit der Ausnahme, dass sie in das Systemimage eingebunden ist und möglicherweise eine privilegierte App ist, wird Ihre Instrumentierung wahrscheinlich auf das App-Paket (siehe Abschnitt zum Manifest unten) Ihrer Komponente ausgerichtet. In diesem Fall hat Ihr Anwendungs-Makefile möglicherweise eine eigene certificate-Einstellung und Ihr Instrumentierungsmodul sollte dieselbe Einstellung beibehalten. 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 ist diese Einstellung nicht erforderlich: Das Build-System signiert das Paket einfach mit einem standardmäßigen integrierten Zertifikat, das auf der Build-Variante basiert. Dieses Zertifikat wird in der Regel als dev-keys bezeichnet.
test_suites: ["device-tests"],
Mit der Einstellung test_suites wird der Test für den Trade Federation-Test-Harness leicht auffindbar. 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 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 der Konfiguration neben der Android.bp eine AndroidTest.xml zugeordnet.
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 „wahr“ festgelegt werden.
require_root: true
Die Einstellung require_root weist das Build-System an, der automatisch generierten Testkonfiguration RootTargetPreparer hinzuzufügen. So wird sichergestellt, 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, der automatisch generierten Testkonfiguration MinApiLevelModuleController hinzuzufügen. Wenn Trade Federation die Testkonfiguration ausführt, wird der Test übersprungen, wenn der Wert der Geräteeigenschaft ro.product.first_api_level < test_min_api_level ist.