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