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

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

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

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

Build and run CTS

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

Build CTS (AOSP 14 or earlier)

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

Build 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

Write CTS tests

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