Две пары матриц совместимости и манифестов предназначены для согласования, чтобы убедиться, что платформа и реализация поставщика могут работать друг с другом. Эта проверка успешна после совпадения между матрицей совместимости платформы и манифестом устройства, а также между манифестом платформы и матрицей совместимости устройств.
Эта проверка выполняется во время сборки, во время создания пакета обновления OTA , во время загрузки и в тестах совместимости с VTS.
В следующих разделах подробно описаны правила сопоставления, используемые различными компонентами.
Соответствие версии матрицы совместимости фреймворка
Чтобы сопоставить манифест устройства с матрицей совместимости фреймворка, версия FCM доставки, указанная в manifest.target-level
должна быть точно равна версии FCM, заданной в файле compatibility-matrix.level
. В противном случае совпадения не будет.
Когда матрица совместимости фреймворка запрашивается с помощью libvintf
, это совпадение всегда успешно, поскольку libvintf
открывает манифест устройства, извлекает версию FCM доставки и возвращает матрицу совместимости фреймворка в этой версии FCM доставки (плюс некоторые дополнительные HAL из матриц совместимости с более высоким FCM Версии).
Матчи HAL
Правило соответствия HAL определяет версии элементов hal
в файле манифеста, которые считаются поддерживаемыми владельцем соответствующей матрицы совместимости.
HIDL и родные HAL
Правила соответствия для HIDL и собственных HAL следующие.
- Несколько
<hal>
элементы вычисляются с помощью одного и отношений. - Несколько элементов
<version>
в одном<hal>
имеют отношение ИЛИ . Если указано два или более, необходимо реализовать только одну из версий. (См. Пример DRM ниже.) - Несколько элементов
<instance>
и<regex-instance>
в одном<hal>
оцениваются с помощью одного отношения AND . (См. Пример DRM ниже.)
Пример: успешное соответствие HAL для модуля
Для HAL версии 2.5 правило соответствия выглядит следующим образом:
Матрица | Соответствующий манифест |
---|---|
2.5 | 2.5-2.∞. В матрице совместимости 2.5 - это сокращение от 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. Правила соответствия для HAL AIDL аналогичны правилам HIDL и родным HAL, за исключением того, что нет основных версий и существует ровно одна версия на каждый экземпляр HAL ( 1
если версия не указана).
- Несколько
<hal>
элементы вычисляются с помощью одного и отношений. - Несколько элементов
<instance>
и<regex-instance>
в одном<hal>
оцениваются с помощью одного отношения AND . (См. Пример вибратора ниже.)
Пример: успешное совпадение 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 /vendor/etc/vintf/manifest.xml
, чтобы устройство явно указывало версию FCM ядра в манифесте устройства, /vendor/etc/vintf/manifest.xml
, если /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
в дереве исходных kernel/configs/r/android-4.19
Android.
Соответствие версии ядра
Матрица может включать в себя несколько разделов <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
декларируют следующие требования (теги верхнего и /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 (Q) | 4.19.42 | 4.19-q |
4 (Q) | неопределенные | 4.4.107 | Нет совпадений (нет ветки ядра 4.4-q ) |
4 (Q) | неопределенные | 4.9.165 | 4.9-q |
4 (Q) | неопределенные | 5.4.41 | 5.4-r (см. Примечание ниже) |
4 (Q) | 4 (Q) | 4.9.165 | 4.9-q |
4 (Q) | 4 (Q) | 5.4.41 | Нет совпадений (нет ветки ядра 5.4-q ) |
4 (Q) | 5 (R) | 4.14.105 | 4.14-r |
4 (Q) | 5 (R) | 5.4.41 | 5.4-r |
5 (R) | неопределенные | Любые | VTS не работает (необходимо указать версию ядра FCM для целевой версии FCM 5) |
5 (R) | 4 (Q) | Любые | 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
существовать в/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 содержит ОСНОВНУЮ версию и МИНИМАЛЬНУЮ версию с форматом ОСНОВНОЙ.МИНОР (например, 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
) для прохождения проверки. Для этого:
- Выберите Cherry следующие 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
в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
Матрица совместимости устройств объявляет набор необходимой версии системного SDK в compatibility-matrix.system-sdk.version
. manifest.system-sdk.version
только в том случае, если набор является подмножеством предоставленных версий системного SDK, как объявлено в manifest.system-sdk.version
в манифесте платформы.
- В качестве особого случая, если в матрице совместимости устройств не указаны версии System SDK, это всегда считается совпадением, поскольку пустой набор является подмножеством любого набора.
Пример: успешное совпадение версии системного SDK
Если в матрице совместимости устройств указано следующее требование к System 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 не подходит, потому что не предоставляется System SDK версии 27.