القواعد المطابقة

من المفترض أن يكون زوجان من مصفوفات التوافق والبيان للتحقق من أن إطار العمل وتنفيذ البائع مع بعضهما البعض. عملية التحقق هذه يكون ناجحًا عند تطابق مصفوفة توافق إطار العمل مع أو ملف بيان الجهاز، وكذلك بين بيان إطار العمل والجهاز مصفوفة التوافق.

يتم إجراء عملية التحقّق هذه في وقت الإصدار في التحديث عبر الهواء. وقت إنشاء الحزمة ووقت التشغيل واختبارات توافق 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 هو الحد الأدنى من الإصدار المطلوب، ما يعني أنّ البيان يوفّر طبقة تجريد الأجهزة (HAL) الإصدار 2.0-2.4 غير متوافق. الإصدار 2.7 هو الحد الأقصى للإصدار الذي يمكن طلبه، وهو ما يعني أن مالك لن تطلب مصفوفة التوافق (إطار العمل أو الجهاز) إصدارات أكثر من 2.7. سيظل بإمكان مالك البيان المطابق عرض الإصدار 2.10. (كمثال) عند طلب 2.7. يعرف مالك مصفوفة التوافق فقط أن الخدمة المطلوبة متوافقة مع الإصدار 2.7 لواجهة برمجة التطبيقات. -7 إعلامية فقط ولا تؤثر في عملية تحديث التحديث عبر الهواء. وبالتالي، يظل الجهاز المثبَّت عليه طبقة تجريد الأجهزة (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 الأحدث من الإصدار 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 هو الحد الأدنى من الإصدار المطلوب، أي أنّ البيان يوفّر طبقة تجريد الأجهزة (HAL) الأرقام من 1 إلى 4 غير متوافقة. والرقم 7 هو الحد الأقصى للإصدار الذي يمكن طلبه، ما يعني أنّ مالك لن تطلب مصفوفة التوافق (إطار العمل أو الجهاز) إصدارات أكثر من 7. لا يزال بإمكان مالك البيان المطابق عرض الإصدار 10 (كمثال) عند طلب الرقم 7. يعرف مالك مصفوفة التوافق فقط أن الخدمة المطلوبة متوافقة مع الإصدار 7 من واجهة برمجة التطبيقات. -7 إعلامية فقط ولا تؤثر في عملية تحديث التحديث عبر الهواء. وبالتالي، يظل أي جهاز يحتوي على طبقة تجريد الأجهزة (HAL) بالإصدار 10 في ملف البيان الخاص به متوافقة مع إطار عمل ينص على 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).

ملاحظة: إذا كان إصدار kernel FCM يساوي إصدار FCM المستهدف وكانت قيمته أكبر من أو تساوي 5، لا يحتوي الملف المصدر لبيان الجهاز المحدّد من قِبل DEVICE_MANIFEST_FILE على لتحديد إصدار kernel FCM. تستنتج assemble_vintf تلقائيًا إصدار kernel FCM من إصدار FCM المستهدف إذا كان إصدار FCM المستهدف أكبر من أو يساوي 5-

تفرض اختبارات 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

ملاحظة: بالنسبة إلى الأجهزة التي تستخدم الإصدار المستهدَف من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" بالإصدار 5 (R) وإصدار غير محدَّد من النواة من خلال المراسلة عبر السحابة الإلكترونية من Firebase، يحدد كائن VINTF فرع النواة ذي اللاحقة الأقل التي تزيد عن FCM المستهدف مع إصدار النواة المطابق. في المثال أعلاه، جهاز مزوّد بإصدار مستهدَف من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" من 3 (P) تستخدم فرع النواة 4.19-q لأن 4.19-q تحتوي على أدنى لاحقة من بين جميع فروع النواة البالغ عددها 4.19-*، [4.19-q, 4.19-r, 4.19-s]. هذا النمط لا يُسمح بسلوك اختيار المتطلبات في الأجهزة التي تستخدم الإصدار 5 (R) من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدفة أو إذ يجب أن يكون إصدار kernel FCM المحددة.

مطابقة إعدادات النواة

في حال تطابق القسم "<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 أثناء الاتصال عبر الهواء

ملاحظة: لا ينطبق هذا القسم على الأجهزة التي يتم تحديثها إلى Android 11.

بالنسبة إلى الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم، عند التحديث إلى Android 10، AVB تتم مطابقة متطلبات الإصدار في مصفوفة توافق إطار العمل مع AVB الحالي. الإصدار على الجهاز. إذا كان إصدار AVB يتضمّن ترقية رئيسية للإصدار خلال التحديث عبر الهواء (مثلاً، من 0.0 إلى 1.0)، فإن فحص VINTF للتوافق في OTA لا يعكس التوافق بعد وكالة سفر على الإنترنت.

للتخفيف من حدة هذه المشكلة، يمكن للمصنّع الأصلي للجهاز وضع إصدار AVB مزيف في حزمة OTA (compatibility.zip) لاجتياز عملية التحقّق. لإجراء ذلك:

1. اختَر سجلّات CLs التالية في شجرة مصادر Android 9:
   • CL 732261
   • CL 732262
2. حدِّد BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE للجهاز. قيمتها يجب أن يساوي إصدار AVB قبل الاتصال عبر الهواء، أي إصدار 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> وهي عبارة عن إدخال <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) للنظام.