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

Каждый новый тестовый модуль должен иметь файл конфигурации, который будет управлять системой сборки с метаданными модуля, зависимостями времени компиляции и инструкциями по упаковке. Android теперь использует систему сборки 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 для вашего модуля, так что вы можете использовать make [options] <HelloWorldTests> для сборки вашего тестового модуля и всех его зависимостей.

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

Параметр static_libs указывает системе сборки включить содержимое именованных модулей в результирующий APK текущего модуля. Это означает, что каждый именованный модуль должен создать файл .jar , и его содержимое будет использоваться для разрешения ссылок на пути к классам во время компиляции, а также включено в результирующий 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 позволяет легко обнаружить тест с помощью тестового оборудования Торговой федерации. Сюда можно добавить другие пакеты, например 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 указывает, создавать ли тестовую конфигурацию автоматически. Если AndroidTest.xml не существует рядом с Android.bp , для этого атрибута не требуется явно устанавливать значение 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 .