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

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

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

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

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

Создайте и запустите CTS

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

Примечание. Вы можете использовать aosp_x86_64 в качестве альтернативы aosp_arm64 .

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

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

tf> run cts --plan CTS

Написание тестов CTS

Чтобы написать тест CTS (CTS-D) на базе разработчика, необходимо сначала отправить предложение по тесту, следуя инструкциям в процессе подачи CTS.

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

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

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

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

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

Тип API	Формат аннотации	Примечания
Метод	android.example.ClassA#methodA	Самый распространенный вариант использования.
Метод с ключевыми значениями	android.example.ClassB#methodB(KeyA)	Используйте только в том случае, если ваш тест использует метод API для проверки поля, как в этом примере.
Поле	android.example.ClassC#FieldA	Используйте только тогда, когда ваш тест напрямую проверяет поле API, как в этом примере.

Если ваш тест проверяет требование 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 добавьте к каждому действию в 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.

КТС 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

КТС 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

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

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

КТС v1

Если вы используете CTS v1, обратитесь к примеру в разделе cts/tests/tests/example и создайте новый каталог. Кроме того, обязательно добавьте имя модуля вашего нового пакета из его Android.mk в CTS_COVERAGE_TEST_CASE_LIST в cts/CtsTestCaseList.mk . build/core/tasks/cts.mk использует этот make-файл для объединения всех тестов и создания окончательного пакета 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 .

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

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 или VTS в AOSP, выберите ветку разработки в зависимости от того, к каким уровням API применяется исправление.

• Для изменений, которые применяются к нескольким уровням API, сначала разработайте патч в aosp/main , а затем выберите самую старшую тестовую ветку . Разрешить автослиянию объединить изменения в последующих ветках тестирования AOSP. Список ветвей и информацию о путях автоматического объединения см. в разделе График выпуска и информация о ветках .
• Для изменений, специфичных для определенного уровня API, разработайте или выберите изменения в правильной тестовой ветке с помощью NOT MERGE или RESTRICT AUTOMERGE в сообщении о фиксации.

Следуйте рабочему процессу отправки исправлений , чтобы внести изменения в CTS. Для проверки вашего изменения будет назначен рецензент.

График релизов и информация о филиалах

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

Примечание. Это расписание является предварительным и будет обновляться по мере развития CTS для данной версии Android.

Версия	уровень API	Ветвь	Частота
15	35	android15-tests-dev	Ежеквартальный
14	34	android14-tests-dev	Ежеквартальный
13	33	android13-tests-dev	Ежеквартальный
12л	32	android12L-tests-dev	Ежеквартальный
12	31	android12-tests-dev	Ежеквартальный

Примечание. Дальнейшие выпуски версий с 4.2 по 11 не планируются.

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

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

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

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

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

Для изменений только в следующей версии Android путь автоматического объединения:
aosp-main > <Internal git_main> .

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

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