Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release
вместо aosp-main
для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Тестирование платформы Android
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Android Open Source Project (AOSP) предоставляет несколько инструментов и тестовых наборов для тестирования различных частей вашей реализации. Перед использованием страниц в этом разделе вам следует ознакомиться со следующими терминами:
- Android-совместимое устройство
- Устройство, на котором можно запускать любое стороннее приложение, написанное сторонними разработчиками с использованием Android SDK и NDK. Устройства, совместимые с Android, должны соответствовать требованиям Compatibility Definition Document (CDD) и проходить Compatibility Test Suite (CTS) . Устройства, совместимые с Android, имеют право участвовать в экосистеме Android, которая включает потенциальное лицензирование Google Play, потенциальное лицензирование набора приложений и API Google Mobile Services (GMS) и использование товарного знака Android. Любой желающий может использовать исходный код Android, но чтобы считаться частью экосистемы Android, устройство должно быть совместимо с Android.
- артефакт
- Журнал сборки, позволяющий устранять неполадки локально.
- Документ определения совместимости (CDD)
- Документ, в котором перечислены требования к программному и аппаратному обеспечению для Android-совместимого устройства.
- Набор тестов на совместимость (CTS)
Бесплатный тестовый набор коммерческого уровня, доступный для загрузки в виде двоичного файла или исходного кода в AOSP. CTS — это набор модульных тестов, разработанных для интеграции в ваш ежедневный рабочий процесс. Цель CTS — выявить несовместимости и гарантировать, что программное обеспечение остается совместимым на протяжении всего процесса разработки.
Тесты CTS и платформы не являются взаимоисключающими. Вот некоторые общие рекомендации:
- Если тест подтверждает правильность функций или поведения API фреймворка и его необходимо применять ко всем OEM-партнерам, то его следует включить в CTS.
- Если тест предназначен для выявления регрессий во время разработки платформы и для его проведения может потребоваться привилегированное разрешение, а также он может зависеть от деталей реализации (опубликованных в AOSP), то это должен быть платформенный тест.
- Мобильные службы Google (GMS)
Коллекция приложений и API Google, которые можно предварительно установить на устройства.
- GoogleTest (GTest)
Фреймворк тестирования и имитации C++. Двоичные файлы GTest обычно обращаются к слоям абстракции более низкого уровня или выполняют необработанный IPC против различных системных служб. Подход к тестированию для GTest обычно тесно связан с тестируемой службой. CTS содержит фреймворк GTest.
- инструментальный тест
Специальная среда выполнения теста, запускаемая командой am instrument
, где целевой процесс приложения перезапускается и инициализируется с базовым контекстом приложения, а поток инструментирования запускается внутри виртуальной машины процесса приложения. CTS содержит тесты инструментирования.
- ЛогКэт
Инструмент командной строки, который создает журнал системных сообщений, включая трассировки стека ошибок, возникающих при возникновении устройством, и сообщения, записанные вами из приложения с помощью класса Log
.
- ведение журнала
Использование журнала для отслеживания событий компьютерной системы, таких как ошибки. Ведение журнала в Android является сложным из-за смеси используемых стандартов, объединенных в инструменте Logcat.
- тест после отправки
Тест Android, который выполняется, когда новый патч фиксируется в общей ветке ядра. Введя aosp_kernel
в качестве частичного имени ветки, вы можете увидеть список веток ядра с доступными результатами. Например, результаты для android-mainline
можно найти по адресу https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .
- предварительный тест
Тест, используемый для предотвращения появления сбоев в общих ядрах.
- Торговая федерация
Также называется Tradefed, непрерывный тестовый фреймворк, разработанный для запуска тестов на устройствах Android. Например, Tradefed используется для запуска тестов Compatibility Test Suite и Vendor Test Suite.
- Тестовый набор поставщика (VTS)
Набор обширных возможностей для тестирования Android, способствующий процессу разработки на основе тестирования, а также автоматизации уровня абстракции оборудования (HAL) и тестирования ядра ОС.
Типы испытаний платформы
Тест платформы обычно взаимодействует с одной или несколькими системными службами Android или слоями HAL, проверяет функциональные возможности тестируемого объекта и подтверждает правильность результатов тестирования. Тест платформы может:
- (Тип 1) API-интерфейсы фреймворка упражнений с использованием фреймворка Android. Конкретные API-интерфейсы, которые практикуются, могут включать:
- Публичные API, предназначенные для сторонних приложений
- Скрытые API, предназначенные для привилегированных приложений, а именно системные API или частные API (
@hide
, или protected
, package private
)
- (Тип 2) Вызов системных служб Android напрямую с использованием raw-binder или прокси-серверов IPC.
- (Тип 3) Взаимодействуйте напрямую с HAL, используя низкоуровневые API или интерфейсы IPC.
Тесты типа 1 и 2 обычно являются инструментальными тестами, тогда как тесты типа 3 обычно являются GTests.
Что дальше?
Вот список документов, с которыми вы можете ознакомиться для получения более подробной информации:
Если вы не изучали архитектуру Android, см. Обзор архитектуры .
Если вы создаете устройство, совместимое с Android, ознакомьтесь с обзором программы совместимости с Android .
Чтобы интегрировать инструментальные, функциональные, метрические и хост-тесты JAR в службу непрерывного тестирования платформы, см. Рабочий процесс разработки тестов .
Чтобы обнаружить уязвимости и защитить свои устройства от них, см. раздел Тестирование безопасности .
Информацию о тестировании реализаций HAL и ядра см. в разделе Набор тестов поставщика (VTS) и инфраструктура .
Для тестирования приложений ознакомьтесь с разделом «Основы тестирования приложений Android» и проведите тест « Продвинутый Android на Kotlin 05.1: Основы тестирования», используя предоставленные примеры .
Узнайте о базовом тестировании presubmit, доступном вам через repo hooks. Эти hooks можно использовать для запуска линтеров, проверки форматирования и запуска модульных тестов перед продолжением, например загрузкой коммита. По умолчанию эти hooks отключены. Для получения дополнительной информации см. AOSP Preupload Hooks .
Дополнительную информацию о ведении журнала см. в разделе Понимание ведения журнала .
Чтобы понять, как отлаживать код Android, см. раздел Отладка собственного кода платформы Android .
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-29 UTC."],[],[],null,["# Android platform testing\n\nAndroid Open Source Project (AOSP) provides several tools and test suites\nfor testing various parts of your implementation. Before using the pages in this\nsection, you should be familiar with the following terms:\n\n*Android-compatible device*\n: A device that can run any third-party app written by third-party developers\n using the Android SDK and NDK. Android-compatible devices must adhere to the\n requirements of the\n [Compatibility Definition Document (CDD)](#CDD) and pass the\n [Compatibility Test Suite (CTS)](#cts). Android-compatible\n devices are eligible to participate in the Android ecosystem, which includes\n potential licensure of Google Play, potential licensure of the\n [Google Mobile Services (GMS)](#gms) suite of\n app and APIs, and use of the Android trademark. Anyone is welcome to\n use the Android source code, but to be considered part of the Android ecosystem,\n a device must be Android compatible.\n\n*artifact*\n: A build-related log that enables local troubleshooting.\n\n*Compatibility Definition Document (CDD)*\n: A document that enumerates the software and hardware requirements for an\n Android-compatible device.\n\n*Compatibility Test Suite (CTS)*\n\n: A free, commercial-grade test suite, available for download as a binary or as\n source in AOSP. The CTS is a set of unit tests designed to be integrated into\n your daily workflow. The intent of CTS is to reveal incompatibilities, and\n ensure that the software remains compatible throughout the development process.\n\n CTS and platform tests aren't mutually exclusive. Here are some general\n guidelines:\n\n - If a test is asserting correctness of framework API functions or behaviors, and the test should be enforced across OEM partners, it should be in CTS.\n - If a test is intended to catch regressions during platform development, and might require privileged permission to carry out, and might be dependent on implementation details (as released in AOSP), it should be a platform test.\n\n*Google Mobile Services (GMS)*\n\n: A collection of Google apps and APIs that can be preinstalled on devices.\n\n*GoogleTest (GTest)*\n\n: A C++ testing and mocking framework. GTest binaries typically\n access lower-level abstraction layers or perform raw IPC against various system\n services. The testing approach for GTest is usually tightly coupled with the\n service being tested. CTS contains the GTest framework.\n\n*instrumentation test*\n\n: A special test execution environment\n launched by the `am instrument` command, where the targeted app process\n is restarted and initialized with basic app context, and an\n instrumentation thread is started inside the app process virtual\n machine. CTS contains instrumentation tests.\n\n*Logcat*\n\n: A command-line tool that creates a log of system messages, including\n stack traces of when the device throws an error and messages that you have\n written from your app with the `Log` class.\n\n*logging*\n\n: Using a log to keep track of computer system events, such\n as errors. Logging in Android is complex due to the mix of standards used that\n are combined in the Logcat tool.\n\n*postsubmit test*\n\n: An Android test that is performed when a new patch is committed to a\n common kernel branch. By entering `aosp_kernel` as a partial branch name, you\n can see a list of kernel branches with results available. For example, results\n for `android-mainline` can be found at\n \u003chttps://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid\u003e.\n\n*presubmit test*\n\n: A test used to prevent failures from being introduced into the\n common kernels.\n\n*Trade Federation*\n\n: Also called Tradefed, a continuous test\n framework designed for running tests on Android devices. For example,\n Tradefed is used to run Compatibility Test Suite and Vendor Test Suite tests.\n\n*Vendor Test Suite (VTS)*\n\n: A set of extensive capabilities for\n Android testing, promoting a test-driven development process, and automating\n hardware abstraction layer (HAL) and OS kernel testing.\n\nPlatform test types\n-------------------\n\nA platform test typically interacts with one or more of the Android system\nservices or HAL layers, exercises the\nfunctionalities of the subject under test, and asserts correctness of the\ntesting outcome. A platform test might:\n\n- (Type 1) Exercise framework APIs using Android framework. Specific APIs being exercised can include:\n - Public APIs intended for third-party apps\n - Hidden APIs intended for privileged apps, namely system APIs or private APIs (`@hide`, or `protected`, `package private`)\n- (Type 2) Invoke Android system services using raw binder or IPC proxies directly.\n- (Type 3) Interact directly with HALs using low-level APIs or IPC interfaces.\n\nType 1 and 2 tests are typically instrumentation tests, while type 3 tests are\nusually GTests.\n\nWhat's next?\n------------\n\nHere is a list of documents that you can read for more detailed information:\n\n- If you haven't studied Android architecture, see\n [Architecture overview](/docs/core/architecture).\n\n- If you're creating an Android-compatible device, see\n the [Android compatibility program overview](/docs/compatibility/overview).\n\n- To integrate instrumentation, functional, metric, and JAR host tests\n into a platform continuous testing service, see\n [Test development workflow](/docs/core/tests/development).\n\n- To detect and harden your devices against vulnerabilities,\n see [Security testing](/docs/security/test/fuzz-sanitize).\n\n- To learn about testing your HAL and kernel implementations, see\n [Vendor Test Suite (VTS) and infrastructure](/docs/core/tests/vts).\n\n- For app testing, read\n [Fundamentals of testing Android\n apps](https://developer.android.com/training/testing/fundamentals)\n and conduct the [Advanced Android in Kotlin 05.1:Testing\n Basics](https://codelabs.developers.google.com/codelabs/advanced-android-kotlin-training-testing-basics/index.html)\n using the\n [samples](https://github.com/android/testing-samples) provided.\n\n- Learn about the basic presubmit testing available to you through repo hooks.\n These hooks can be used to run linters, check formatting, and trigger unit\n tests before proceeding, such as uploading a commit. These hooks are disabled\n by default. For further information, see [AOSP Preupload\n Hooks](https://android.googlesource.com/platform/tools/repohooks/+/refs/heads/android16-release/README.md).\n\n- To read more about logging, see [Understand logging](/docs/core/tests/debug/understanding-logging).\n\n- To understand how to debug Android code, see\n [Debug native Android platform code](/docs/core/tests/debug)."]]