разработка СТС

Инициализируйте свой клиент Repo

Следуйте инструкциям из раздела Загрузка исходного кода , чтобы получить и собрать исходный код Android. При выполнении команды repo init укажите конкретную ветку CTS с помощью -b . Это гарантирует включение ваших изменений CTS в последующие выпуски CTS.

В следующем примере кода показано, как использовать repo init .

Создание и запуск CTS

Выполните следующие команды для сборки CTS и запуска интерактивной консоли CTS:

Сборка CTS (AOSP 14 или более ранняя версия)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Сборка CTS (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

Для выбора значения target-release обратитесь к следующей таблице:

Запустить CTS

В консоли CTS введите:

tf> run cts --plan CTS

Напишите тесты CTS

Тесты CTS используют JUnit и API тестирования Android. Ознакомьтесь с руководством по тестированию приложения и существующими тестами в каталоге cts/tests . Тесты CTS в основном следуют тем же соглашениям, что и другие тесты Android.

CTS работает на многих производственных устройствах, поэтому тесты должны соответствовать следующим правилам:

• Учитывайте различные размеры экрана, ориентацию и раскладку клавиатуры.
• Используйте только публичные методы API. Другими словами, избегайте всех классов, методов и полей с аннотацией hide .
• Избегайте использования макетов представлений или расчетов на размеры ресурсов, которые могут отсутствовать на некоторых устройствах.
• Не полагайтесь на привилегии root.

Добавить аннотацию Java

Если ваш тест проверяет поведение API, добавьте к тестовому коду аннотацию @ApiTest и перечислите все задействованные API в поле apis . Используйте подходящий формат из следующих примеров:

Если ваш тест проверяет требование CDD, аннотируйте идентификатор требования (включая идентификатор раздела CDD и идентификатор требования) с помощью @CddTest в тестовом коде CTS, как показано в следующем примере. В сообщении о коммите укажите, какое требование CDD проверяется вашим тестом, указав идентификаторы требований CDD. Идентификаторы требований CDD представляют собой комбинацию идентификаторов раздела и требования, соединённых косой чертой (/), как в 7.3.1/C-1-1.

/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

Для CTS Verifier добавьте к каждому Activity в файле AndroidManifest.xml соответствующий идентификатор CDD. Форматы полей значений аналогичны форматам аннотаций Java в CTS. В сообщении о коммите укажите, какое требование CDD применяется, указав идентификатор требования CDD.

  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

В сообщении о коммите

Чётко укажите, почему ваш тест необходимо добавить, и добавьте соответствующие ссылки для получения поддержки. Для тестов CTS-D включите ссылку на предложение по тестированию, созданное вами в Google Issue Tracker в процессе подачи заявки на CTS-D .

Создать подплан

В качестве примера вы можете добавить файл SubPlan.xml в android-cts/subplans следующим образом:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

Чтобы запустить подплан:

run cts --subplan aSubPlan

Формат записи подплана:

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

Наименование и местоположение теста

Большинство тестовых случаев CTS ориентированы на определённый класс в API Android. Имена этих тестов имеют имена пакетов Java с суффиксом cts и имена классов с суффиксом Test . Каждый тестовый случай состоит из нескольких тестов, каждый из которых обычно проверяет определённый метод тестируемого класса. Эти тесты организованы в структуру каталогов, где тесты сгруппированы по различным категориям, например, «виджеты» или «представления».

Например, тест CTS для пакета Java android.widget.TextView — android.widget.cts.TextViewTest с именем пакета Java android.widget.cts и именем класса TextViewTest .

• Имя пакета Java
  Имя пакета Java для тестов CTS состоит из имени пакета класса, который тестируется, и расширения .cts . В нашем примере имя пакета будет android.widget.cts .
• Имя класса
  Имя класса для тестов CTS — это имя тестируемого класса с добавлением слова «Test». Например, если тест предназначен для TextView , имя класса должно быть TextViewTest .
• Имя модуля (только CTS v2)
  CTS v2 организует тесты по модулям. Имя модуля обычно представляет собой вторую строку имени пакета Java (в нашем примере — widget ).

Структура каталога и пример кода зависят от того, используете ли вы CTS v1 или CTS v2.

CTS v1

Для Android 6.0 и ниже используйте CTS v1. Пример кода для CTS v1 находится по адресу cts/tests/tests/example .

Структура каталогов в тестах CTS v1 выглядит следующим образом:

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

CTS v2

Для Android 7.0 и выше используйте CTS v2. Подробнее см. пример теста в Android Open Source Project (AOSP) .

Структура каталога CTS v2 выглядит следующим образом:

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

Новые образцы пакетов

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

CTS v1

Если вы используете CTS v1, обратитесь к примеру в cts/tests/tests/example и создайте новый каталог. Также обязательно добавьте имя модуля нового пакета из Android.mk в CTS_COVERAGE_TEST_CASE_LIST в cts/CtsTestCaseList.mk . build/core/tasks/cts.mk использует этот make-файл для объединения всех тестов и создания финального пакета CTS.

CTS v2

Используйте тестовый пример /cts/tests/sample/ для быстрого запуска нового тестового модуля, выполнив следующие шаги:

1. Чтобы создать тестовый каталог и скопировать файлы образцов, выполните:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. Перейдите в cts/tests/ module-name и замените все вхождения «[Ss]ample» рекомендуемым соглашением об именовании, приведенным выше.
3. Обновите SampleDeviceActivity , чтобы протестировать тестируемую функцию.
4. Обновите SampleDeviceTest , чтобы убедиться, что действие выполнено успешно или регистрируются его ошибки.

Дополнительные каталоги

Также можно добавить другие каталоги Android, такие как assets , jni , libs и res . Чтобы добавить код JNI, создайте в корне проекта каталог рядом с src с нативным кодом и создайте в нём make-файл Android.mk .

Makefile обычно содержит следующие настройки:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni

# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)

# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)

Файл Android.mk

Наконец, измените файл Android.mk в корне проекта, чтобы собрать нативный код и использовать его в зависимости от него, как показано ниже:

# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner

# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni

# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)

#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))

Исправить или удалить тесты

Помимо добавления новых тестов, вы можете исправлять или удалять тесты, аннотированные BrokenTest или KnownFailure .

Отправьте ваши изменения

При внесении изменений в CTS следуйте инструкциям по отправке изменений кода .

• Выберите ветку разработки на основе уровней API, к которым применяется патч.
• Разработайте или выберите изменения для правильной тестовой ветки с DO NOT MERGE или RESTRICT AUTOMERGE в сообщении о коммите.

Назначается рецензент, который проверяет ваши изменения и соответствующим образом отбирает изменения для внесения во внутренний Gerrit.

График выпуска и информация о филиалах

Релизы CTS следуют этому графику.

Важные даты во время релиза

• Конец первой недели: заморозка кода. Изменения, внесённые в ветку до момента заморозки кода, рассматриваются для следующей версии CTS. Изменения, поданные в ветку после заморозки кода или после выбора кандидата на выпуск, рассматриваются для последующего выпуска.
• Вторая или третья неделя: CTS публикуется на странице загрузок Compatibility Test Suite .

Автоматическое объединение потока

Ветви разработки CTS были настроены таким образом, что изменения, внесенные в каждую ветку, автоматически объединяются с ветками более высокого уровня.

Для изменений, непосредственно вносимых в тестовую ветку разработки AOSP, путь автоматического слияния следующий:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• Для версий CTS 16+ рецензент отберет соответствующие изменения во внутреннем Gerrit.

Если список изменений (CL) не удалось слить корректно, автору патча отправляется электронное письмо с инструкциями по разрешению конфликта. В большинстве случаев автор патча может воспользоваться инструкциями, чтобы пропустить автоматическое слияние конфликтующего CL.

Если изменение требуется для более старой ветки, то патч необходимо выбрать из более новой ветки.

Для тестовых изменений, применимых к следующей версии Android, после загрузки предлагаемого изменения Google его рассматривает и, если оно принято, выбирает его и помещает во внутренний Gerrit.