Правила матча

Две пары матриц совместимости и манифестов предназначены для согласования с целью проверки совместимости фреймворка и реализации поставщика. Эта проверка считается успешной при совпадении матрицы совместимости фреймворка и манифеста устройства, а также манифеста фреймворка и матрицы совместимости устройства.

Эта проверка выполняется во время сборки, во время генерации пакетов OTA-обновлений , во время загрузки и в ходе тестов совместимости VTS.

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

Матрица совместимости фреймворков соответствует версиям

Для сопоставления манифеста устройства с матрицей совместимости фреймворков, версия FCM, указанная в manifest.target-level должна точно совпадать с версией FCM, указанной в compatibility-matrix.level . В противном случае сопоставление невозможно.

Когда матрица совместимости фреймворков запрашивается с помощью libvintf , это сопоставление всегда проходит успешно, поскольку libvintf открывает манифест устройства, получает версию FCM, указанную в поставках, и возвращает матрицу совместимости фреймворков для этой версии FCM (плюс некоторые необязательные HAL из матриц совместимости для более высоких версий FCM).

HAL играет

Правило HAL-match определяет версии элементов hal в файле манифеста, которые считаются поддерживаемыми владельцем соответствующей матрицы совместимости.

HIDL и нативные HAL

Правила сопоставления для HIDL и нативных HAL следующие:

  • Несколько элементов <hal> оцениваются с помощью одного логического И.
  • Элементы <hal> могут иметь атрибут <hal optional="true"> чтобы пометить их как необязательные.
  • Несколько элементов <version> внутри одного элемента <hal> имеют отношение ИЛИ . Если указано два или более таких элементов, достаточно реализовать только одну из версий. (См. Успешное совпадение HAL для модуля DRM .)
  • При необходимости использования элемента <hal> несколько элементов <instance> и <regex-instance> внутри одного и того же элемента <hal> оцениваются с помощью единого логического И. (См. Успешное совпадение HAL для модуля DRM .)

Пример: Успешное сопоставление HAL с модулем.

Для HAL версии 2.5 правило соответствия выглядит следующим образом:

Матрица Соответствующий манифест
2.5 2.5-2.∞. В матрице совместимости 2.5 — это сокращенное обозначение для 2.5-5 .
2.5-7 2.5-2.∞. Указывает на следующее:
  • 2.5 — это минимально необходимая версия, то есть манифест, содержащий HAL 2.0-2.4, несовместим.
  • 2.7 — это максимальная версия, которую можно запросить, то есть владелец матрицы совместимости (фреймворка или устройства) не может запрашивать версии выше 2.7. Владелец соответствующего манифеста может по-прежнему предоставлять версию 2.10 (например), даже если запрашивается версия 2.7. Владелец матрицы совместимости знает только то, что запрашиваемая услуга совместима с версией API 2.7.
  • -7 носит исключительно информационный характер и не влияет на процесс обновления по воздуху (OTA).
Таким образом, устройство с HAL версии 2.10 в файле манифеста остается совместимым с фреймворком, в матрице совместимости которого указаны 2.5-7 .

Пример: Успешное сопоставление HAL с модулем DRM.

В матрице совместимости фреймворка указана следующая информация о версиях DRM HAL:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Поставщик может реализовать любой из следующих вариантов:

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1
android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HALs

Android и более поздние версии поддерживают версии AIDL HAL в VINTF. Правила сопоставления для AIDL HAL аналогичны правилам для HIDL и нативных HAL, за исключением того, что основных версий нет, и на каждый экземпляр HAL приходится ровно одна версия ( 1 , если версия не указана):

  • Несколько элементов <hal> оцениваются с помощью одного логического И.
  • Элементы <hal> могут иметь атрибут <hal optional="true"> чтобы пометить их как необязательные.
  • При необходимости использования элемента <hal> несколько элементов <instance> и <regex-instance> в рамках одного и того же <hal> оцениваются с помощью единого логического оператора И. (См. раздел «Успешное совпадение HAL для нескольких модулей ».)

Пример: Успешное сопоставление HAL с модулем.

Для HAL версии 5 правило соответствия выглядит следующим образом:

Матрица Соответствующий манифест
5 5-∞. В матрице совместимости 5 — это сокращенное обозначение 5-5 .
5-7 5-∞. Обозначает следующее:
  • 5 — это минимально необходимая версия, то есть манифест, содержащий HAL 1-4, несовместим.
  • 7 — это максимальная версия, которую можно запросить, то есть владелец матрицы совместимости (фреймворка или устройства) не будет запрашивать версии выше 7. Владелец соответствующего манифеста может по-прежнему предоставлять версию 10 (например), даже если запрашивается версия 7. Владелец матрицы совместимости знает только то, что запрашиваемая услуга совместима с версией API 7.
  • -7 носит исключительно информационный характер и не влияет на процесс обновления по воздуху (OTA).
Таким образом, устройство с HAL версии 10 в файле манифеста остается совместимым с фреймворком, в матрице совместимости которого указаны 5-7 .

Пример: Успешное сопоставление HAL для нескольких модулей.

В матрице совместимости фреймворка указана следующая информация о версиях HAL для вибраторов и камер:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

Поставщик может реализовать любой из этих вариантов:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

Сопоставление ядра

В разделе <kernel> матрицы совместимости фреймворков описываются требования фреймворка к ядру Linux на устройстве. Эта информация предназначена для сопоставления с информацией о ядре, которая сообщается объектом VINTF устройства.

Соответствие ветвям ядра

Каждый суффикс ветви ядра (например, 5.4- r ) сопоставляется с уникальной версией ядра в FCM (например, 5). Это сопоставление аналогично сопоставлению между буквами версий (например, R) и версиями FCM (например, 5).

Тесты VTS гарантируют, что устройство явно указывает версию FCM ядра в манифесте устройства, /vendor/etc/vintf/manifest.xml , если выполняется одно из следующих условий:

  • Версия ядра FCM отличается от версии целевого устройства FCM. Например, у упомянутого устройства целевая версия FCM — 4, а версия ядра FCM — 5 (суффикс ветви ядра r ).
  • Версия ядра FCM больше или равна 5 (суффикс ветви ядра r ).

Тесты VTS гарантируют, что если указана версия FCM ядра, то она должна быть больше или равна целевой версии FCM в манифесте устройства.

Пример: Определите ветвь ядра.

Если устройство использует целевую версию FCM 4 (выпущенную в Android 10), но работает на ядре из ветки 4.19-r , то в манифесте устройства следует указать следующее:

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

Объект VINTF проверяет совместимость ядра с требованиями ветки ядра 4.19-r , указанной в версии FCM 5. Эти требования формируются из kernel/configs/r/android-4.19 в исходном коде Android.

Пример: Определить ветку ядра для GKI.

Если устройство использует универсальный образ ядра (GKI), и строка версии ядра из /proc/version выглядит следующим образом:

5.4.42-android12-0-00544-ged21d463f856

Затем объект VINTF получает номер версии Android из номера версии ядра и использует его для определения версии FCM ядра. В этом примере android12 означает версию FCM ядра 6 (выпущенную в Android 12).

Подробную информацию о том, как анализируется строка выпуска ядра, см. в разделе «Версионирование GKI» .

Соответствие версиям ядра

Матрица может содержать несколько разделов <kernel> , каждый из которых имеет свой атрибут version , используя следующий формат:

${ver}.${major_rev}.${kernel_minor_rev}

Объект VINTF учитывает только раздел <kernel> из FCM с совпадающей версией FCM, имеющей те же значения ${ver} и ${major_rev} , что и ядро ​​устройства (то есть version="${ver}.${major_rev}.${matrix_minor_rev}") ; другие разделы игнорируются. Кроме того, минорная ревизия ядра должна быть значением из матрицы совместимости ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Если ни один раздел <kernel> не соответствует этим требованиям, это считается несоответствием.

Пример: Выберите требования для сопоставления.

Рассмотрим следующий гипотетический случай, когда FCM-модули в /system/etc/vintf задают следующие требования (теги заголовка и нижнего колонтитула опущены):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

Целевая версия FCM, версия FCM ядра и версия ядра совместно определяют требования к ядру из FCM:

Целевая версия FCM Версия ядра FCM Версия ядра Совпадение с
3 (P) Не указано 4.4.106 Нет совпадения (несоответствие незначительных версий)
3 (P) Не указано 4.4.107 4.4-p
3 (P) Не указано 4.19.42 4.19-q (см. примечание после таблицы)
3 (P) Не указано 5.4.41 5.4-r (см. примечание после таблицы)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Совпадения не найдено (нет ветки ядра 4.19-p )
3 (P) 4 (В) 4.19.42 4.19-q
4 (В) Не указано 4.4.107 Совпадения не найдено (нет ветки ядра 4.4-q )
4 (В) Не указано 4.9.165 4.9-q
4 (В) Не указано 5.4.41 5.4-r (см. примечание после таблицы)
4 (В) 4 (В) 4.9.165 4.9-q
4 (В) 4 (В) 5.4.41 Совпадения не найдено (нет ветки ядра 5.4-q )
4 (В) 5 (R) 4.14.105 4.14-r
4 (В) 5 (R) 5.4.41 5.4-r
5 (R) Не указано любой VTS завершается с ошибкой (необходимо указать версию ядра FCM для целевой версии FCM 5).
5 (R) 4 (В) любой VTS завершается с ошибкой (версия ядра FCM < целевая версия FCM)
5 (R) 5 (R) 4.14.180 4.14-r

Сопоставление конфигураций ядра

Если раздел <kernel> совпадает, процесс продолжается попыткой сопоставления элементов config с файлом /proc/config.gz . Для каждого элемента конфигурации в матрице совместимости выполняется поиск в файле /proc/config.gz , чтобы проверить наличие соответствующей конфигурации. Если элемент конфигурации имеет значение n в матрице совместимости для соответствующего раздела <kernel> , он должен отсутствовать в файле /proc/config.gz . Наконец, элемент конфигурации, отсутствующий в матрице совместимости, может присутствовать или отсутствовать в /proc/config.gz .

Пример: Сопоставление конфигураций ядра

  • <value type="string">bar</value> соответствует "bar" . Кавычки опущены в матрице совместимости, но присутствуют в /proc/config.gz .
  • <value type="int">4096</value> соответствует 4096 , 0x1000 или 0X1000 .
  • <value type="int">0x1000</value> соответствует 4096 , 0x1000 или 0X1000 .
  • <value type="int">0X1000</value> соответствует 4096 , 0x1000 или 0X1000 .
  • <value type="tristate">y</value> соответствует y .
  • <value type="tristate">m</value> соответствует m .
  • <value type="tristate">n</value> означает, что элемент конфигурации НЕ должен существовать в /proc/config.gz .
  • <value type="range">1-0x3</value> соответствует 1 , 2 или 3 , или их шестнадцатеричному эквиваленту.

Пример: Успешное сопоставление ядра

Матрица совместимости фреймворка с версией FCM 1 содержит следующую информацию о ядре:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

Сначала определяется ветвь ядра. Ветвь ядра указывается в манифесте устройства в параметре manifest.kernel.target-level , который по умолчанию равен manifest.level , если предыдущий параметр не указан:

  • Если в манифесте устройства указана ветка ядра, равная 1, процесс переходит к следующему шагу и проверяет версию ядра.
  • Если в манифесте устройства указана ветка ядра с номером 2, то соответствие матрице отсутствует. Объекты VINTF считывают требования ядра из матрицы версии FCM 2.

Затем проверяется соответствие версии ядра. Если устройство в uname() сообщает:

  • 4.9.84 (нет совпадения с матрицей, если нет отдельного раздела ядра с <kernel version="4.9.x"> , где x <= 84 )
  • 4.14.41 (нет соответствия матрице, меньше version )
  • 4.14.42 (сопоставление с матрицей)
  • 4.14.43 (сопоставление с матрицей)
  • 4.1.22 (нет соответствия матрице, если нет отдельного раздела ядра с <kernel version="4.1.x"> , где x <= 22 )

После выбора соответствующего раздела <kernel> для каждого элемента <config> со значением, отличным от n , соответствующая запись должна присутствовать в /proc/config.gz ; для каждого элемента <config> со значением n соответствующая запись не должна присутствовать в /proc/config.gz . Содержимое <value> должно точно соответствовать тексту после знака равенства (включая кавычки) до символа новой строки или # , при этом начальные и конечные пробелы должны быть усечены.

Следующая конфигурация ядра является примером успешного совпадения: 

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

Приведенная ниже конфигурация ядра является примером неудачного совпадения: 

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

Соответствует политикам SEPolicy

Для корректной работы SEPolicy требуются следующие совпадения:

  • <sepolicy-version> определяет замкнутый диапазон минорных версий для каждой основной версии. Версия SEPolicy, сообщаемая устройством, должна попадать в один из этих диапазонов, чтобы быть совместимой с фреймворком. Правила соответствия аналогичны правилам для версий HAL; соответствие считается таковым, если версия SEPolicy выше или равна минимальной версии для диапазона. Максимальная версия носит чисто информационный характер.
  • <kernel-sepolicy-version> , то есть версия базы данных политик, должна быть меньше, чем security_policyvers() сообщаемая устройством.

Пример: Успешное сопоставление SEPolicy

В матрице совместимости фреймворка указана следующая информация о политике SEPolicy: 

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

На устройстве:

  • Значение, возвращаемое функцией security_policyvers() , должно быть больше или равно 30. В противном случае совпадение не будет обнаружено. Например:
    • Если устройство возвращает значение 29, значит, оно не соответствует действительности.
    • Если устройство возвращает значение 31, значит, это совпадение.
  • Версия SEPolicy должна быть одной из 25.0-∞ или 26.0-∞. В противном случае совпадение не будет обнаружено. (Цифра -3 после 26.0 носит чисто информативный характер.)

Версия AVB соответствует

Версия AVB содержит основную и дополнительную версии в формате MAJOR.MINOR (например, 1.0, 2.1). Более подробную информацию см. в разделе «Версионирование и совместимость» . Версия AVB имеет следующие системные свойства:

  • ro.boot.vbmeta.avb_version — это версия libavb в загрузчике.
  • ro.boot.avb_version — это версия libavb в операционной системе Android ( init/fs_mgr ).

Системное свойство отображается только в том случае, если соответствующая libavb использовалась для проверки метаданных AVB (и возвращала OK). Оно отсутствует, если проверка завершилась неудачей (или проверка вообще не проводилась).

Для проверки совместимости сравниваются следующие параметры:

  • sysprop ro.boot.vbmeta.avb_version с avb.vbmeta-version из матрицы совместимости фреймворков:
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • sysprop ro.boot.avb_version с avb.vbmeta-version из матрицы совместимости фреймворков:
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Загрузчик или ОС Android могут содержать две копии библиотек libavb , каждая с разной основной версией для устройств обновления и устройств запуска. В этом случае может использоваться один и тот же неподписанный образ системы, но конечные подписанные образы системы будут разными (с разной avb.vbmeta-version ):

Рисунок 1. Соответствие версии AVB (/system — P, все остальные разделы — O).



Рисунок 2. Соответствие версии AVB (все разделы имеют кодировку P).

Пример: Успешное совпадение версии AVB

В матрице совместимости фреймворка указана следующая информация об AVB: 

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

На устройстве: 

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 
ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 
ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

Сопоставление версии AVB во время OTA

Для устройств, выпущенных с Android 9 или более ранними версиями, при обновлении до Android 10 требования к версии AVB в матрице совместимости фреймворка сопоставляются с текущей версией AVB на устройстве. Если версия AVB обновляется до более новой версии во время OTA-обновления (например, с 0.0 до 1.0), проверка совместимости VINTF в OTA-обновлении не отражает совместимость после обновления.

Для решения этой проблемы производитель оборудования может поместить поддельную версию AVB в пакет OTA ( compatibility.zip ), чтобы пройти проверку. Для этого:

  1. Выберите следующие изменения в исходном коде Android 9:
  2. Определите параметр BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE для устройства. Его значение должно совпадать с версией AVB до обновления OTA, то есть с версией AVB устройства на момент его запуска.
  3. Пересоберите пакет OTA.

Эти изменения автоматически добавляют BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE в файл compatibility-matrix.avb.vbmeta-version в следующих файлах:

  • /system/compatibility_matrix.xml (который не используется в Android 9) на устройстве
  • system_matrix.xml находится в compatibility.zip в OTA-пакете.

Эти изменения не затрагивают другие матрицы совместимости фреймворков, включая /system/etc/vintf/compatibility_matrix.xml . После обновления по воздуху (OTA) для проверок совместимости будет использоваться новое значение из /system/etc/vintf/compatibility_matrix.xml .

Версия VNDK соответствует

Матрица совместимости устройств указывает требуемую версию VNDK в compatibility-matrix.vendor-ndk.version . Если в матрице совместимости устройств отсутствует тег <vendor-ndk> , никаких требований не предъявляется, и устройство всегда считается соответствующим требованиям.

Если в матрице совместимости устройств присутствует тег <vendor-ndk> , то в наборе снимков VNDK поставщиков, предоставленных фреймворком в манифесте фреймворка, выполняется поиск записи <vendor-ndk> с соответствующей <version> . Если такой записи нет, значит, совпадения нет.

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

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

Пример: Успешное совпадение версий VNDK

Если в матрице совместимости устройств указано следующее требование к VNDK: 

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

В манифесте фреймворка учитывается только запись с версией 27. 

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

Пример A совпадает, поскольку в манифесте фреймворка указана версия VNDK 27, и {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} . 

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

Пример B не подходит. Хотя в манифесте фреймворка указана версия VNDK 27, libjpeg.so не поддерживается фреймворком в этом снимке. Версия VNDK 26 игнорируется.

Версия системного SDK соответствует

Матрица совместимости устройств определяет набор необходимых версий системного SDK в файле compatibility-matrix.system-sdk.version . Совпадение возможно только в том случае, если этот набор является подмножеством предоставленных версий системного SDK, указанных в manifest.system-sdk.version в манифесте фреймворка.

  • В качестве частного случая, если в матрице совместимости устройств не указаны версии системного SDK, это всегда считается совпадением, поскольку пустое множество является подмножеством любого множества.

Пример: Успешное совпадение версий системного SDK.

Если в матрице совместимости устройств указано следующее требование к системному SDK: 

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Затем платформа должна обеспечить соответствие версиям системного SDK 26 и 27: 

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Пример А — это совпадение: 

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

Пример B совпадает: 

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

Пример C не подходит, поскольку не предоставлена ​​версия системного SDK 27.