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

Инициализируйте клиент репозитория.

Следуйте инструкциям из раздела «Загрузка исходного кода» , чтобы получить и собрать исходный код 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, добавьте аннотацию @CddTest к идентификатору требования (включая идентификатор раздела CDD и идентификатор требования) в коде теста 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-тестов нацелены на конкретный класс в Android API. Эти тесты имеют имена пакетов 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 использует этот makefile для объединения всех тестов и создания окончательного пакета 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 , содержащий нативный код и makefile-файл 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 публикуется на странице загрузок пакета тестов на совместимость .

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

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

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

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

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

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

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