Konfiguracja prostej kompilacji

Każdy nowy moduł testowy musi mieć plik konfiguracji, który kieruje system kompilacji za pomocą metadanych modułu, zależności w czasie kompilacji i instrukcji pakowania. Android korzysta teraz z systemu kompilacji Soong, który ułatwia korzystanie konfigurację testową.

Soong używa plików Blueprint lub .bp, które są prostymi opisami deklaratywnymi modułów do skompilowania, podobnymi do plików JSON. Ten format zastępuje system oparty na make, który był używany w poprzednich wersjach. Zobacz pliki referencyjne utworu w panelu ciągłej integracji.

Aby przeprowadzić testy niestandardowe lub użyć Compatibility Test Suite (CTS) na Androida, postępuj zgodnie z konfiguracją testu złożonego.

Przykład

Poniższe wpisy pochodzą z przykładowego pliku konfiguracyjnego Blueprint: /platform_testing/tests/example/instrumentation/Android.bp

Dla wygody podajemy tu podsumowanie:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Zwróć uwagę, że deklaracja android_test na początku wskazuje, że jest to test. Dodanie android_app oznaczałoby, że jest to pakiet kompilacji.

Ustawienia

Wyjaśnienie tych ustawień:

    name: "HelloWorldTests",

Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Moduł nadaje mu nazwę, Plik APK będzie miał taką samą nazwę, ale z sufiksem .apk, np. W tym przypadku wynikowy testowy plik APK ma nazwę HelloWorldTests.apk. Dodatkowo, określa docelową nazwę modułu, tak aby możliwe było użycie funkcji make [options] <HelloWorldTests> do utworzenia modułu testowego i wszystkich jego zależności.

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

Ustawienie static_libs instruuje system kompilacji, aby uwzględniał zawartość nazwanych modułów do wynikowego pakietu apk bieżącego modułu. Oznacza to, że każdy nazwany moduł powinien wygenerować plik .jar, a jego zawartość zostanie używane do rozpoznawania odwołań do ścieżek zajęć podczas kompilowania oraz do do wynikowego pliku APK.

Moduł androidx.test.runner to biblioteka AndroidX Test Runner, która zawiera narzędzie do testowania AndroidJUnitRunner. AndroidJUnitRunner obsługuje platformę testowania JUnit4 i zastępuje ją InstrumentationTestRunner na Androidzie 10. Więcej informacji o testowaniu aplikacji na Androida znajdziesz w artykule Testowanie aplikacji na Androida.

Jeśli tworzysz nowy moduł instrumentacji, zacznij od i użyj biblioteki androidx.test.runner. Drzewo źródłowe platformy zawiera również inne przydatne platformy testowe, takie jak ub-uiautomator, mockito-target, easymock i inne.

    certificate: "platform",

Ustawienie certificate instruuje system kompilacji, aby podpisywał plik APK tym samym kluczem jako podstawowej platformy. Jest to wymagane, jeśli test używa podpisu chronione uprawnienie lub interfejs API. Pamiętaj, że ta metoda jest odpowiednia do ciągłego testowania platformy, ale nie powinna być używana w modułach testów CTS. Zwróć uwagę, że ten przykład używa tego ustawienia certyfikatu tylko w celach ilustracyjnych: kod testowy nie trzeba w rzeczywistości korzystać z pliku APK podpisanego za pomocą parametru specjalny certyfikat platformy.

Jeśli tworzysz instrumentację dla komponentu, który działa poza serwera systemu, czyli jest mniej lub bardziej jak zwykły plik APK aplikacji, z wyjątkiem tego, że jest wbudowany w obraz systemu i może być aplikacją uprzywilejowaną, że narzędzia są kierowane na pakiet aplikacji (patrz poniżej) o pliku manifestu). W takim przypadku makefile aplikacji może mieć własne ustawienie certificate, a twój moduł pomiarów powinien zachować to samo ustawienie. Dzieje się tak, ponieważ kierowanie narzędzia w testowanej aplikacji, muszą być podpisane testowe pakiety apk i apk aplikacji z tym samym certyfikatem.

W innych przypadkach to ustawienie jest niepotrzebne. System kompilacji po prostu podpisze go domyślnym, wbudowanym certyfikatem opartym na kompilacji i zwykle nosi on nazwę dev-keys.

    test_suites: ["device-tests"],

Ustawienie test_suites ułatwia znalezienie testu na platformie handlowej Ekstraktor federacji. Możesz tu dodać inne pakiety, na przykład CTS, aby udostępnić ten test.

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

Ustawienia opcjonalne

Wyjaśnienie tych ustawień opcjonalnych:

    test_config: "path/to/hello_world_test.xml"

Ustawienie test_config instruuje system kompilacji, dla którego testowy cel musi mieć parametr dla danej konfiguracji. Domyślnie obok opcji Android.bp znajduje się ikona AndroidTest.xml powiązane z konfiguracją.

    auto_gen_config: true

Ustawienie auto_gen_config wskazuje, czy konfiguracja testu ma być tworzona automatycznie. Jeśli AndroidTest.xml nie istnieje obok Android.bp, to nie trzeba jednoznacznie ustawiać wartości „true” (prawda).

    require_root: true

Ustawienie require_root instruuje system kompilacji, aby dodał element RootTargetPreparer do automatycznie wygenerowanej konfiguracji testowej. Gwarantuje to uruchomienie testu z poziomu roota uprawnień.

    test_min_api_level: 29

Ustawienie test_min_api_level instruuje system kompilacji, aby dodał MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testowej. Podczas wymiany Federacja uruchamia konfigurację testową; test zostanie pominięty, jeśli właściwość urządzenia z ro.product.first_api_level < test_min_api_level