Проект Android Open Source Project (AOSP) предоставляет несколько инструментов и наборов тестов для тестирования различных частей вашей реализации. Перед использованием страниц этого раздела вам следует ознакомиться со следующими терминами:
- Android-совместимое устройство
- Устройство, на котором может запускаться любое стороннее приложение, написанное сторонними разработчиками с использованием Android SDK и NDK. Устройства, совместимые с Android, должны соответствовать требованиям документа определения совместимости (CDD) и проходить набор тестов на совместимость (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» и проведите тест « Advanced Android in Kotlin 05.1:Testing Basics», используя предоставленные примеры . 
- Узнайте о базовом тестировании перед отправкой, доступном через хуки репозитория. Эти хуки можно использовать для запуска линтеров, проверки форматирования и запуска модульных тестов перед дальнейшими действиями, такими как загрузка коммита. По умолчанию эти хуки отключены. Подробнее см. в разделе «Хуки предварительной загрузки AOSP» . 
- Дополнительную информацию о ведении журнала см. в разделе Понимание ведения журнала . 
- Чтобы понять, как отлаживать код Android, ознакомьтесь со статьей Отладка собственного кода платформы Android . 
