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

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

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

Для размещения пользовательского тестирования или использовать Android Compatibility Test Suite (CTS), следовать сложной конфигурации Test вместо.

Пример

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

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

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

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

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

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

    certificate: "platform",

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

Если вы пишете инструментарий для своего компонента, который находится за пределами системного сервера, то есть он упакован более или менее как обычный apk приложения, за исключением того, что он встроен в образ системы и может быть привилегированным приложением, скорее всего, ваши инструменты быть нацеленным на пакет приложения (см. ниже раздел о манифесте) вашего компонента. В этом случае ваше приложение Makefile может иметь свой собственный 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 , этот атрибут не должен быть установлен верно в явном виде.

    require_root: true

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

    test_min_api_level: 29

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