من المفترض أن يكون زوجان من مصفوفات التوافق والبيان للتحقق من أن إطار العمل وتنفيذ البائع مع بعضهما البعض. عملية التحقق هذه يكون ناجحًا عند تطابق مصفوفة توافق إطار العمل مع أو ملف بيان الجهاز، وكذلك بين بيان إطار العمل والجهاز مصفوفة التوافق.
يتم إجراء عملية التحقّق هذه في وقت الإصدار في التحديث عبر الهواء. وقت إنشاء الحزمة ووقت التشغيل واختبارات توافق VTS.
توضح الأقسام التالية بالتفصيل القواعد المطابقة التي يستخدمها المكونات المختلفة.
تطابقات إصدار مصفوفة توافق إطار العمل
لمطابقة بيان جهاز مع مصفوفة توافق إطار العمل،
إصدار خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" المخصَّص للشحن المحدّد من قِبل "manifest.target-level
"
أن يكون مطابقًا تمامًا لإصدار ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" المحدد من خلال
compatibility-matrix.level
وبخلاف ذلك، ما مِن مطابقة.
عند طلب مصفوفة توافق إطار العمل مع libvintf
، تصبح هذه المطابقة مطلوبة.
تكون دائمًا ناجحة لأن libvintf
يفتح بيان الجهاز، يسترجع بيانات الشحن
إصدار خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" وعرض مصفوفة توافق إطار العمل عند إصدار خدمة الشحن والمراسلة عبر السحابة الإلكترونية من Firebase (بالإضافة إلى بعض
HALs اختيارية من مصفوفات التوافق في إصدارات المراسلة عبر السحابة الإلكترونية من Firebase الأعلى).
مباريات HAL
تحدد قاعدة مطابقة HAL إصدارات عناصر hal
في
ملف البيان الذي يُعد معتمَدًا من قِبل مالك الملف
مصفوفة التوافق.
HIDL وHALs الأصلية
في ما يلي قواعد المطابقة الخاصة بشهادة HIDL وHALs الأصلية.
- يتم تقييم عناصر
<hal>
متعددة باستخدام دالة AND واحدة. العلاقة. - قد تحتوي عناصر
<hal>
على<hal optional="true">
لوضع علامة عليها كـ غير مطلوب. - عناصر
<version>
متعددة ضمن نفس<hal>
لديهم علاقة أو. إذا تم تحديد قيمتين أو أكثر، يجب تنفيذ أحد الإصدارات. (اطّلِع على مثال DRM أدناه.) - عدة
<instance>
عناصر<regex-instance>
داخل نفس يتم تقييم<hal>
باستخدام علاقة AND واحدة عندما يجب ملء الحقل<hal>
. (اطلع على <a href="#drm">مثال إدارة الحقوق الرقمية أدناه.)</a href="#drm">
مثال: مطابقة 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 HALs
جميع إصدارات Android الأحدث من الإصدار 11 من Android (باستثناء Android)
11) يدعم إصدارات AIDL HALs في VINTF.
تتشابه قواعد المطابقة الخاصة بـ AIDL HALs مع قواعد HIDL وHALs الأصلية، باستثناء:
ليس هناك إصدارات رئيسية، وهناك نسخة واحدة فقط لكل مثيل HAL (1
إذا
غير محدد).
- يتم تقييم عناصر
<hal>
متعددة باستخدام دالة AND واحدة. العلاقة. - قد تحتوي عناصر
<hal>
على<hal optional="true">
لوضع علامة عليها كـ غير مطلوب. - عدة
<instance>
عناصر<regex-instance>
داخل نفس يتم تقييم<hal>
باستخدام علاقة AND واحدة عندما يجب ملء الحقل<hal>
. (راجع <a href="#vibrator">مثال الهزّاز أدناه.)</a href="#vibrator">
مثال: مطابقة HAL ناجحة لوحدة معيّنة
بالنسبة إلى HAL في الإصدار 5، تكون قاعدة المطابقة على النحو التالي:
مصفوفة | بيان المطابقة |
---|---|
5 |
5-∞. و5 هو اختصار في مصفوفة التوافق
5-5 |
5-7 |
5-∞. يشير إلى ما يلي:
5-7 في مصفوفة التوافق. |
مثال: مطابقة HAL ناجحة لوحدات متعددة
توضح مصفوفة توافق إطار العمل معلومات الإصدار التالية لهزّازات HALs للكاميرا:
<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
) بلاحقة فريدة
إصدار kernel FCM (على سبيل المثال، 5). عملية الربط مماثلة لعملية الربط بين حروف الإصدار.
(على سبيل المثال، R) وإصدارات المراسلة عبر السحابة الإلكترونية من Firebase (على سبيل المثال، 5).
تفرض اختبارات VTS أن يحدد الجهاز بشكل صريح إصدار kernel FCM في
بيان الجهاز، /vendor/etc/vintf/manifest.xml
، في حال استيفاء أيٍّ من المتطلّبات التالية:
-
يختلف إصدار kernel FCM عن إصدار FCM المستهدف. على سبيل المثال،
أن الجهاز المذكور سابقًا له الإصدار 4 المستهدف من خدمة المراسلة عبر السحابة الإلكترونية من Firebase، وإصدار kernel FCM هو 5 (kernel
لاحقة الفرع
r
). -
إصدار kernel FCM أكبر من أو يساوي 5 (لاحقة فرع النواة
r
).
تفرض اختبارات VTS أنه في حال تحديد إصدار kernel FCM، فإن إصدار kernel FCM سيكون أكبر من أو يساوي إصدار المراسلة عبر السحابة الإلكترونية من Firebase المستهدف في بيان الجهاز.
مثال: تحديد فرع النواة
إذا كان الجهاز يحتوي على الإصدار 4 المستهدَف من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" (تم طرحه في Android 10)، ولكن
تشغيل kernel من فرع 4.19-r
، فينبغي أن يحدد بيان الجهاز ما يلي:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
يتحقّق كائن VINTF من توافق النواة مع المتطلّبات على نواة 4.19-r
.
الذي تم تحديده في الإصدار 5 من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase". تستند هذه المتطلبات إلى
kernel/configs/r/android-4.19
في شجرة مصادر Android
مثال: تحديد فرع النواة في GKI
إذا كان الجهاز يستخدم صورة النواة العامة (GKI)، وسلسلة إصدار النواة (kernel) من
في ما يلي /proc/version
:
5.4.42-android12-0-00544-ged21d463f856
بعد ذلك، يحصل كائن VINTF على إصدار Android من إصدار النواة، ويستخدمه لتحديد
لإصدار kernel FCM. في هذا المثال، يشير android12
إلى الإصدار 6 من بروتوكول "المراسلة عبر السحابة الإلكترونية من Firebase" بالنواة
(تم طرحه في الإصدار 12 من نظام التشغيل Android).
للحصول على تفاصيل حول كيفية تحليل سلسلة إصدار النواة، يمكنك الاطّلاع على إصدارات GKI:
مطابقة إصدارات النواة
يمكن أن تتضمن المصفوفة أقسام <kernel>
متعددة، كل منها
سمة version
مختلفة باستخدام التنسيق:
${ver}.${major_rev}.${kernel_minor_rev}
يتعامل كائن VINTF مع القسم <kernel>
فقط من
خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" مع نسخة مطابقة من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" تحمل الاسم نفسه
${ver}
و${major_rev}
كنواة للجهاز (أي
version="${ver}.${major_rev}.${matrix_minor_rev}")
؛ أقسام أخرى
وتجاهلها. بالإضافة إلى ذلك، يجب أن تكون المراجعة الثانوية من النواة قيمة
من مصفوفة التوافق (${kernel_minor_rev} >=
${matrix_minor_rev}
;). في حال عدم استيفاء قسم <kernel>
هذه المتطلبات، فإن الأمر لا يكون مطابقًا.
مثال: اختيار متطلبات المطابقة
يُرجى مراعاة الحالة الافتراضية التالية حيث يعلن فريق "المراسلة عبر السحابة الإلكترونية من Firebase" في /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 -->
يحدد كل من إصدار المراسلة عبر السحابة الإلكترونية من Firebase المستهدف وإصدار kernel FCM وإصدار النواة معًا النواة المتطلبات التي تفرضها خدمة "المراسلة عبر السحابة الإلكترونية من Firebase":
إصدار "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدَف | إصدار Kernel 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 (يجب تحديد إصدار ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" الخاص بالنواة للإصدار 5 المستهدَف من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase") |
5 (R) | 4 (Q) | أي واحد | تعذُّر البث عبر VTS (إصدار kernel 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
أو مكافئ سداسي عشري.
مثال: مطابقة نواة ناجحة
تحتوي مصفوفة توافق إطار العمل مع الإصدار 1 من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" على معلومات النواة التالية:
<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 متطلبات النواة من المصفوفة في الإصدار 2 من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" بدلاً من ذلك.
ثم تتم مطابقة إصدار الكيرنل (النواة). إذا كان الجهاز في uname()
التقارير:
- 4.9.84 (لا يطابق المصفوفة ما لم يكن هناك قسم kernel منفصل باسم
<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>
تمامًا مع النص بعد
علامة يساوي (بما فيها علامات الاقتباس)، وحتى حرف السطر الجديد
#
، مع اقتطاع المسافات البيضاء البادئة واللاحقة.
فيما يلي إعداد النواة (kernel) مثال على مطابقة ناجحة:
# 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)
تتطلّب سياسة شريحة العنصر الآمن استيفاء المتطلبات التالية:
- تُحدِّد الدالة
<sepolicy-version>
نطاقًا مغلقًا من القيم الصغيرة. لكل إصدار رئيسي. إصدار سياسة الأوراق المالية الذي أبلغ عنه الجهاز يجب أن تقع ضمن أحد هذه النطاقات كي تكون متوافقة مع إطار العمل. محتوى مطابِق مماثلة لإصدارات HAL؛ تكون مطابقة إذا تم إصدار سياسة sepolicy أعلى من الحد الأدنى لإصدار النطاق أو مساويًا له. الحد الأقصى للإصدار هو وعلمية بحتة. <kernel-sepolicy-version>
، أي إصدار Policydb يجب أقل منsecurity_policyvers()
التي أبلغ عنها الجهاز.
مثال: مطابقة ناجحة لسياسة شريحة العنصر الآمن (SE)
توضح مصفوفة توافق إطار العمل معلومات 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، فهذا يعني تطابقًا.
- يجب أن يكون إصدار سياسة شريحة العنصر الآمن أحد الخيارات 25.0-∞ أو 26.0-∞. وبخلاف ذلك، ليس
تطابق. ("
-3
" بعد "26.0
" هي تمامًا المعلوماتية).
إصدار AVB مطابق
يحتوي إصدار AVB على إصدار MAJOR وإصدار ثانوي بالتنسيق كـ 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) لا تكون هذه المعلومات غير موجودة في حال تعذُّر عملية إثبات الملكية (أو لم يحدث أي تحقق على الإطلاق).
تقارن مطابقة التوافق ما يلي:
- syspro
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
- syspro
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
.
ومكتبات كل منها لديه إصدار MAJOR مختلف لترقية الأجهزة وإطلاق
الأجهزة. في هذه الحالة، يمكن مشاركة نفس صورة النظام غير الموقَّعة، ولكن
تكون صور النظام الموقَّعة النهائية مختلفة (بحيث تكون
avb.vbmeta-version
):
الشكل 1. يتطابق إصدار AVB (/النظام هو 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 أثناء الاتصال عبر الهواء
بالنسبة إلى الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم، عند التحديث إلى Android 10، AVB تتم مطابقة متطلبات الإصدار في مصفوفة توافق إطار العمل مع AVB الحالي. الإصدار على الجهاز. إذا كان إصدار AVB يتضمّن ترقية رئيسية للإصدار خلال التحديث عبر الهواء (مثلاً، من 0.0 إلى 1.0)، فإن فحص VINTF للتوافق في OTA لا يعكس التوافق بعد وكالة سفر على الإنترنت.
للتخفيف من حدة هذه المشكلة، يمكن للمصنّع الأصلي للجهاز وضع إصدار AVB مزيف في حزمة OTA
(compatibility.zip
) لاجتياز عملية التحقّق. لإجراء ذلك:
- اختَر سجلّات CLs التالية في شجرة مصادر Android 9:
- حدِّد
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
للجهاز. قيمتها يجب أن يساوي إصدار AVB قبل الاتصال عبر الهواء، أي إصدار 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>
المثال أ هو تطابق، لأن الإصدار 27 من VNDK موجود في بيان إطار العمل،
و{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>
المثال ب ليس مطابقًا. على الرغم من توفّر الإصدار 27 من VNDK في إطار العمل
ملف البيان، libjpeg.so
غير متوافق مع إطار العمل
نبذة عني. يتم تجاهل الإصدار 26 من VNDK.
إصدار حزمة تطوير البرامج (SDK) للنظام مطابق
تعرض مصفوفة توافق الجهاز مجموعة من حزمة تطوير البرامج (SDK) المطلوبة للنظام
في compatibility-matrix.system-sdk.version
. تتوفر
لا تتطابق إلا إذا كانت المجموعة هي مجموعة فرعية من إصدارات System SDK المقدَّمة على النحو الموضّح في البيان
في manifest.system-sdk.version
في بيان إطار العمل.
- حالة خاصة، إذا لم يتم تعداد أي إصدارات من حزمة تطوير البرامج (SDK) للنظام في الجهاز فإن مصفوفة التوافق، تعتبر دائمًا مطابقة، لأن إفراغ مجموعة هي مجموعة فرعية من أي مجموعة.
مثال: مطابقة ناجحة لإصدار حزمة تطوير البرامج (SDK) للنظام
إذا كانت مصفوفة توافق الجهاز تنص على الشرط التالي على System حزمة SDK:
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
وبعد ذلك، يجب أن يوفّر إطار العمل الإصدار 26 و27 من حزمة تطوير البرامج (SDK) للنظام ليتوافق مع هذه السياسة.
<!-- 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>
لا يتطابق المثال "ج" لأنّه لم يتم توفير الإصدار 27 من حزمة تطوير البرامج (SDK) للنظام.