Google is committed to advancing racial equity for Black communities. See how.
This page was translated by the Cloud Translation API.
Switch to English

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

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