Простая конфигурация сборки

Каждый новый тестовый модуль должен иметь файл конфигурации, управляющий системой сборки, содержащий метаданные модуля, зависимости времени компиляции и инструкции по упаковке. Теперь Android использует систему сборки Soong для упрощения настройки тестов.

Soong использует файлы Blueprint или .bp , представляющие собой простые декларативные описания модулей в формате JSON. Этот формат заменяет систему на основе Make, использовавшуюся в предыдущих версиях. Подробную информацию см. в справочных файлах Soong на панели мониторинга непрерывной интеграции .

Чтобы провести пользовательское тестирование или использовать набор тестов на совместимость с Android (CTS), следуйте разделу «Сложная конфигурация теста» .

Пример

Приведенные ниже записи взяты из этого примера файла конфигурации Blueprint: /platform_testing/tests/example/instrumentation/Android.bp

Для удобства здесь приведен снимок:

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

Обратите внимание, что объявление android_test в начале указывает на то, что это тест. Включение android_app , наоборот, укажет на то, что это пакет сборки.

Настройки

Следующие настройки требуют пояснения:

    name: "HelloWorldTests",

Настройка name обязательна, если указан тип модуля android_test (в начале блока). Она задаёт имя вашему модулю, и результирующий APK-файл будет иметь то же имя с суффиксом .apk , например, в данном случае результирующий тестовый APK-файл будет назван HelloWorldTests.apk . Кроме того, она также определяет целевое имя для вашего модуля, чтобы вы могли использовать make [options] <HelloWorldTests> для сборки тестового модуля и всех его зависимостей.

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

Параметр static_libs указывает системе сборки включить содержимое указанных модулей в результирующий APK-файл текущего модуля. Это означает, что каждый указанный модуль должен создать файл .jar , содержимое которого будет использоваться для разрешения ссылок classpath во время компиляции, а также будет включено в результирующий APK-файл.

Модуль androidx.test.runner — это готовый модуль для библиотеки AndroidX Test Runner, которая включает в себя средство запуска тестов AndroidJUnitRunner . AndroidJUnitRunner поддерживает тестовый фреймворк JUnit4 и заменил InstrumentationTestRunner в Android 10. Подробнее о тестировании приложений Android читайте в статье Тестирование приложений на Android .

При создании нового модуля инструментария всегда следует начинать с библиотеки androidx.test.runner в качестве инструмента для запуска тестов. Дерево исходного кода платформы также включает другие полезные фреймворки для тестирования, такие как ub-uiautomator , mockito-target , easymock и другие.

    certificate: "platform",

Настройка certificate предписывает системе сборки подписать APK тем же сертификатом, что и основная платформа. Это необходимо, если ваш тест использует защищённое подписью разрешение или API. Обратите внимание, что это подходит для непрерывного тестирования платформы, но не должно использоваться в тестовых модулях CTS. Обратите внимание, что в этом примере эта настройка сертификата используется только для иллюстрации: тестовый код примера не требует подписи тестового APK специальным сертификатом платформы.

Если вы пишете инструментарий для компонента, который находится вне системного сервера, то есть он упакован более или менее как обычный APK-файл приложения, за исключением того, что он встроен в образ системы и может быть привилегированным приложением, то, скорее всего, ваш инструментарий будет ориентирован на пакет приложения (см. раздел о манифесте ниже) вашего компонента. В этом случае make-файл вашего приложения может иметь собственную настройку certificate , и ваш модуль инструментирования должен сохранить эту настройку. Это связано с тем, что для того, чтобы инструментарий был ориентирован на тестируемое приложение, ваш тестовый APK-файл и APK-файл приложения должны быть подписаны одним и тем же сертификатом.

В других случаях вам вообще не нужен этот параметр: система сборки просто подпишет его встроенным сертификатом по умолчанию на основе варианта сборки, и обычно он называется dev-keys .

    test_suites: ["device-tests"],

Параметр test_suites позволяет легко обнаружить тест в тестовой среде Trade Federation. Здесь можно добавить другие наборы, например CTS, для совместного использования этого теста.

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

Дополнительные настройки

Следующие необязательные настройки требуют пояснения:

    test_config: "path/to/hello_world_test.xml"

Параметр test_config указывает системе сборки, что вашей тестовой цели нужна определённая конфигурация. По умолчанию с конфигурацией связан файл AndroidTest.xml , расположенный рядом с Android.bp .

    auto_gen_config: true

Параметр auto_gen_config определяет, нужно ли автоматически создавать тестовую конфигурацию. Если рядом с Android.bp нет AndroidTest.xml , этому атрибуту не нужно явно задавать значение true.

    require_root: true

Параметр require_root указывает системе сборки добавить RootTargetPreparer в автоматически сгенерированную конфигурацию теста. Это гарантирует запуск теста с правами root.

    test_min_api_level: 29

Параметр test_min_api_level указывает системе сборки добавить MinApiLevelModuleController в автоматически сгенерированную тестовую конфигурацию. При запуске тестовой конфигурации Trade Federation тест будет пропущен, если свойство устройства ro.product.first_api_level < test_min_api_level .