CTS Девелопмент

Инициализация вашего клиента репо

Следуйте инструкциям из раздела «Загрузка исходного кода» , чтобы получить и собрать исходный код 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:

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

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

tf> run cts --plan CTS

Написать 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.

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

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

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

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

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

Версия Уровень API Ответвляться Частота
12л 32 android12L-тесты-dev Ежеквартальный
12 31 android12-тесты-dev Ежеквартальный
11 30 android11-тесты-dev Ежеквартальный
10 29 android10-тесты-dev Ежеквартальный
Дальнейшие выпуски версий 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 и 4.2 не планируются.

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

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

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

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

Для изменений непосредственно в ветке AOSP путь автоматического слияния:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Для изменений в предстоящей версии Android путь автоматического слияния:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

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

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

,

Инициализация вашего клиента репо

Следуйте инструкциям из раздела «Загрузка исходного кода» , чтобы получить и собрать исходный код 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:

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

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

tf> run cts --plan CTS

Написать 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.

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

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

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

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

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

Версия Уровень API Ответвляться Частота
12л 32 android12L-тесты-dev Ежеквартальный
12 31 android12-тесты-dev Ежеквартальный
11 30 android11-тесты-dev Ежеквартальный
10 29 android10-тесты-dev Ежеквартальный
Дальнейшие выпуски версий 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 и 4.2 не планируются.

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

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

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

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

Для изменений непосредственно в ветке AOSP путь автоматического слияния:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Для изменений в предстоящей версии Android путь автоматического слияния:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

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

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