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

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

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

Чтобы выполнить настраиваемое тестирование или использовать Android Compatibility Test Suite (CTS), используйте вместо этого сложную конфигурацию теста .

Пример

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

Сюда для удобства включен снимок:

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

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

Настройки

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

    name: "HelloWorldTests",

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

    static_libs: ["android-support-test"],

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

В этом примере вещи, которые могут быть полезны для тестов:

android-support-test - это предварительно созданная библиотека поддержки тестов Android, которая включает в себя новую программу AndroidJUnitRunner тестов AndroidJUnitRunner : замену устаревшего встроенного InstrumentationTestRunner с поддержкой среды тестирования JUnit4. Подробнее читайте в разделе «Тестирование приложений на Android» .

Если вы создаете новый инструментальный модуль, вам всегда следует начинать с библиотеки android-support-test качестве средства запуска тестов. Дерево исходных кодов платформы также включает другие полезные среды тестирования, такие как 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 .