Две пары матриц совместимости и манифесты предназначены для согласования, чтобы убедиться, что платформа и реализация поставщика могут работать друг с другом. Эта проверка считается успешной при совпадении между матрицей совместимости платформы и манифестом устройства, а также между манифестом платформы и матрицей совместимости устройства.
Эта проверка выполняется во время сборки, во время создания пакета обновлений OTA , во время загрузки и в тестах совместимости VTS.
В следующих разделах подробно описаны правила сопоставления, используемые различными компонентами.
Версия матрицы совместимости фреймворка соответствует
Чтобы манифест устройства соответствовал матрице совместимости платформы, версия FCM доставки, указанная в manifest.target-level , должна точно совпадать с версией FCM, указанной в compatibility-matrix.level . В противном случае нет совпадения.
Когда матрица совместимости фреймворка запрашивается с помощью libvintf , это совпадение всегда успешно, потому что libvintf открывает манифест устройства, извлекает версию FCM для доставки и возвращает матрицу совместимости фреймворка для этой версии FCM для доставки (плюс некоторые необязательные HAL из матриц совместимости для более высоких значений FCM). версии).
HAL соответствует
Правило соответствия HAL определяет версии элементов hal в файле манифеста, которые считаются поддерживаемыми владельцем соответствующей матрицы совместимости.
HIDL и собственные HAL
Правила соответствия для HIDL и собственных HAL следующие.
- Несколько элементов
<hal>оцениваются с помощью одного отношения AND . - Элементы
<hal>могут иметь<hal optional="true">, чтобы пометить их как ненужные. - Несколько элементов
<version>внутри одного<hal>имеют отношение ИЛИ . Если указано два или более, необходимо реализовать только одну из версий. (См. пример DRM ниже.) - Несколько элементов
<instance>и<regex-instance>в одном<hal>оцениваются с помощью одного отношения AND , когда требуется<hal>. (См.
Пример: успешное соответствие HAL для модуля
Для HAL версии 2.5 правило соответствия выглядит следующим образом:
| Матрица | Соответствующий манифест |
|---|---|
2.5 | 2,5-2,∞. В матрице совместимости 2.5 — это сокращение от 2.5-5 . |
2.5-7 | 2,5-2,∞. Указывает следующее:
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 HAL
Все версии Android более поздние, чем Android 11 (за исключением Android 11), поддерживают версии для AIDL HAL в VINTF. Правила сопоставления для AIDL HAL аналогичны правилам HIDL и собственных HAL, за исключением того, что нет основных версий и существует ровно одна версия для каждого экземпляра HAL ( 1 , если версия не указана).
- Несколько элементов
<hal>оцениваются с помощью одного отношения AND . - Элементы
<hal>могут иметь<hal optional="true">, чтобы пометить их как ненужные. - Несколько элементов
<instance>и<regex-instance>в одном<hal>оцениваются с помощью одного отношения AND , когда требуется<hal>. (См.
Пример: успешное соответствие HAL для модуля
Для HAL версии 5 правило соответствия выглядит следующим образом:
| Матрица | Соответствующий манифест |
|---|---|
5 | 5-∞. В матрице совместимости 5 — это сокращение от 5-5 . |
5-7 | 5-∞. Указывает следующее:
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 в манифесте устройства.
Пример: определение ветки ядра
Если на устройстве установлена целевая версия 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 (П) | неопределенные | 4.4.106 | Несоответствие (несоответствие второстепенной версии) |
| 3 (П) | неопределенные | 4.4.107 | 4.4-p |
| 3 (П) | неопределенные | 4.19.42 | 4.19-q (см. примечание ниже) |
| 3 (П) | неопределенные | 5.4.41 | 5.4-r (см. примечание ниже) |
| 3 (П) | 3 (П) | 4.4.107 | 4.4-p |
| 3 (П) | 3 (П) | 4.19.42 | Нет совпадений (нет ветки ядра 4.19-p ) |
| 3 (П) | 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 (Р) | 4.14.105 | 4.14-r |
| 4 (К) | 5 (Р) | 5.4.41 | 5.4-r |
| 5 (Р) | неопределенные | Любые | Сбой VTS (необходимо указать версию ядра FCM для целевой версии FCM 5) |
| 5 (Р) | 4 (К) | Любые | Сбой VTS (версия ядра FCM < целевой версии FCM) |
| 5 (Р) | 5 (Р) | 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
Политика SE соответствует
Политика SE требует следующих совпадений:
-
<sepolicy-version>определяет закрытый диапазон дополнительных версий для каждой основной версии. Версия sepolicy, сообщаемая устройством, должна находиться в одном из этих диапазонов, чтобы быть совместимой с платформой. Правила соответствия аналогичны версиям HAL; это совпадение, если версия sepolicy выше или равна минимальной версии для диапазона. Максимальная версия носит чисто информационный характер. -
<kernel-sepolicy-version>т. е. версия policydb. Должно быть меньше, чем значениеsecurity_policyvers(), сообщаемое устройством.
Пример: успешное совпадение политики SE
В матрице совместимости фреймворка указана следующая информация о политике безопасности:
<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, это совпадение.
- Версия политики SE должна быть одной из 25.0-∞ или 26.0-∞. В противном случае это не совпадение. ("
-3" после "26.0" носит чисто информационный характер.)
Версия AVB соответствует
Версия AVB содержит MAJOR версию и MINOR версию в формате 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 ):
/system — P, все остальные разделы — O).
Пример: успешное совпадение версии 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 не отражает совместимость после OTA.
Чтобы смягчить проблему, OEM-производитель может поместить поддельную версию AVB в пакет OTA ( compatibility.zip ), чтобы пройти проверку. Для этого:
- Выберите следующие CL для исходного дерева Android 9:
- Определите
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEдля устройства. Его значение должно равняться версии AVB до OTA, то есть версии AVB устройства при его запуске. - Пересоберите пакет 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> , запись <vendor-ndk> с соответствующей <version> ищется в наборе моментальных снимков поставщиков VNDK, предоставленных платформой в манифесте платформы. Если такой записи не существует, совпадений нет.
Если такая запись существует, набор библиотек, перечисленных в матрице совместимости устройств, должен быть подмножеством набора библиотек, указанного в манифесте платформы; в противном случае запись не считается совпадением.
- В качестве особого случая, если в матрице совместимости устройств не перечислено ни одной библиотеки, запись всегда считается совпадением, поскольку пустой набор является подмножеством любого набора.
Пример: успешное совпадение версии 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 совпадает
Матрица совместимости устройств объявляет набор требуемой версии System SDK в compatibility-matrix.system-sdk.version . Совпадение есть только в том случае, если набор является подмножеством предоставленных версий System SDK, как указано в manifest.system-sdk.version в манифесте платформы.
- В качестве особого случая, если в матрице совместимости устройств не указаны версии System SDK, это всегда считается совпадением, поскольку пустой набор является подмножеством любого набора.
Пример: успешное совпадение версии System SDK
Если в матрице совместимости устройств указано следующее требование к System SDK:
<!-- Example Device Compatibility Matrix -->
<system-sdk>
<version>26</version>
<version>27</version>
</system-sdk>
Затем платформа должна предоставить System 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>
Пример Б — совпадение.
<!-- Framework Manifest Example C -->
<system-sdk>
<version>26</version>
</system-sdk>
Пример C не подходит, так как System SDK версии 27 не предоставляется.