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

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

يتم إجراء هذا التحقق في وقت الإنشاء، وفي وقت إنشاء حزمة تحديث OTA ، وفي وقت التمهيد، وفي اختبارات توافق VTS.

توضح الأقسام التالية قواعد المطابقة التي تستخدمها المكونات المختلفة.

يتطابق إصدار مصفوفة توافق الإطار

لمطابقة بيان جهاز مع مصفوفة توافق إطار العمل، يجب أن يكون إصدار FCM للشحن المحدد بواسطة manifest.target-level مساويًا تمامًا لإصدار FCM المحدد بواسطة compatibility-matrix.level . وإلا فلا يوجد تطابق.

عندما يتم طلب مصفوفة توافق إطار العمل باستخدام libvintf ، تكون هذه المطابقة ناجحة دائمًا لأن libvintf يفتح بيان الجهاز، ويسترد إصدار FCM للشحن، ويعيد مصفوفة توافق إطار العمل في إصدار FCM للشحن هذا (بالإضافة إلى بعض شرائح HAL الاختيارية من مصفوفات التوافق في FCM الأعلى الإصدارات).

مباريات هال

تحدد قاعدة مطابقة HAL إصدارات عناصر hal في ملف البيان التي تعتبر مدعومة من قبل مالك مصفوفة التوافق المقابلة.

HIDL وHALs الأصلية

قواعد المطابقة لـ HIDL وHALs الأصلية هي كما يلي.

  • يتم تقييم عناصر <hal> المتعددة بعلاقة AND واحدة.
  • قد تحتوي عناصر <hal> على <hal optional="true"> لوضع علامة عليها على أنها غير مطلوبة.
  • عناصر <version> المتعددة داخل نفس <hal> لها علاقة OR . إذا تم تحديد اثنين أو أكثر، فيجب تنفيذ إصدار واحد فقط. (راجع مثال إدارة الحقوق الرقمية أدناه.)
  • يتم تقييم عناصر <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 هو الحد الأدنى للإصدار المطلوب، مما يعني أن البيان الذي يوفر HAL 2.0-2.4 غير متوافق.
  • 2.7 هو الحد الأقصى للإصدار الذي يمكن طلبه، مما يعني أن مالك مصفوفة التوافق (الإطار أو الجهاز) لن يطلب إصدارات تتجاوز 2.7. لا يزال بإمكان مالك البيان المطابق تقديم الإصدار 2.10 (كمثال) عند طلب 2.7. يعرف مالك مصفوفة التوافق فقط أن الخدمة المطلوبة متوافقة مع الإصدار 2.7 من واجهة برمجة التطبيقات (API).
  • -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 هال

تدعم جميع إصدارات Android الأحدث من Android 11 (باستثناء Android 11) إصدارات AIDL HALs في VINTF. تتشابه قواعد المطابقة لـ AIDL HALs مع قواعد HIDL وHALs الأصلية، فيما عدا أنه لا توجد إصدارات رئيسية، ويوجد إصدار واحد بالضبط لكل مثيل 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 هو الحد الأدنى للإصدار المطلوب، مما يعني أن البيان الذي يوفر HAL 1-4 غير متوافق.
  • 7 هو الحد الأقصى للإصدار الذي يمكن طلبه، مما يعني أن مالك مصفوفة التوافق (الإطار أو الجهاز) لن يطلب إصدارات تتجاوز 7. لا يزال بإمكان مالك البيان المطابق تقديم الإصدار 10 (كمثال) عند طلب 7 . يعرف مالك مصفوفة التوافق فقط أن الخدمة المطلوبة متوافقة مع الإصدار 7 من واجهة برمجة التطبيقات (API).
  • -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 الخاص بالجهاز.

تطابق فروع النواة

يتم تعيين كل لاحقة فرع kernel (على سبيل المثال، 5.4- r ) إلى إصدار FCM فريد من kernel (على سبيل المثال، 5). التعيين هو نفس التعيين بين أحرف الإصدار (على سبيل المثال، R) وإصدارات FCM (على سبيل المثال، 5).

تفرض اختبارات VTS أن يحدد الجهاز بشكل صريح إصدار kernel FCM في بيان الجهاز، /vendor/etc/vintf/manifest.xml ، إذا كان أي مما يلي صحيحًا:

  • يختلف إصدار kernel FCM عن إصدار FCM المستهدف. على سبيل المثال، يحتوي الجهاز المذكور أعلاه على إصدار FCM مستهدف 4، وإصدار kernel FCM الخاص به هو 5 (لاحقة فرع kernel r ).
  • إصدار kernel FCM أكبر من أو يساوي 5 (لاحقة فرع kernel r ).

تفرض اختبارات VTS أنه إذا تم تحديد إصدار kernel FCM، فإن إصدار kernel FCM أكبر من أو يساوي إصدار FCM المستهدف في بيان الجهاز.

مثال: تحديد فرع النواة

إذا كان الجهاز يحتوي على الإصدار 4 المستهدف من FCM (الذي تم إصداره في Android 10)، ولكنه يقوم بتشغيل kernel من الفرع 4.19-r ، فيجب أن يحدد بيان الجهاز ما يلي:

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

يتحقق كائن VINTF من توافق kernel مع المتطلبات الموجودة على فرع kernel 4.19-r ، المحدد في الإصدار 5 من FCM. تم إنشاء هذه المتطلبات من kernel/configs/r/android-4.19 في شجرة مصدر Android.

مثال: تحديد فرع النواة لـ GKI

إذا كان الجهاز يستخدم صورة Kernel العامة (GKI)، وكانت سلسلة إصدار kernel من /proc/version كما يلي:

5.4.42-android12-0-00544-ged21d463f856

بعد ذلك، يحصل كائن VINTF على إصدار Android من إصدار kernel، ويستخدمه لتحديد إصدار kernel FCM. في هذا المثال، يعني android12 الإصدار 6 من kernel FCM (تم إصداره في Android 12).

للحصول على تفاصيل حول كيفية تحليل سلسلة إصدار kernel، راجع إصدار GKI .

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

يمكن أن تتضمن المصفوفة عدة أقسام <kernel> ، لكل منها سمة version مختلفة باستخدام التنسيق:

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

يأخذ كائن VINTF فقط قسم <kernel> من FCM مع إصدار FCM المطابق مع نفس ${ver} و ${major_rev} مثل kernel للجهاز (أي version="${ver}.${major_rev}.${matrix_minor_rev}") ; يتم تجاهل الأقسام الأخرى. بالإضافة إلى ذلك، يجب أن تكون المراجعة الثانوية من النواة قيمة من مصفوفة التوافق ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). إذا لم يلبي أي قسم <kernel> هذه المتطلبات، فهذا غير مطابق.

مثال: حدد متطلبات المطابقة

خذ بعين الاعتبار الحالة الافتراضية التالية حيث تعلن FCMs في /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 المستهدف وإصدار kernel FCM وإصدار kernel معًا بتحديد متطلبات kernel من FCMs:

نسخة 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 (يجب تحديد إصدار kernel FCM لإصدار FCM المستهدف 5)
5 (ص) 4 (س) أي فشل VTS (إصدار kernel 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 أو ما يعادله بالنظام الست عشري.

مثال: مطابقة النواة الناجحة

تحتوي مصفوفة توافق الإطار مع الإصدار 1 من FCM على معلومات النواة التالية:

<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>

تتم مطابقة فرع النواة أولاً. يتم تحديد فرع kernel في بيان الجهاز في manifest.kernel.target-level ، والذي يكون افتراضيًا هو manifest.level إذا لم يتم تحديد الأول. إذا كان فرع النواة في الجهاز واضحًا:

  • هو 1، وينتقل إلى الخطوة التالية ويتحقق من إصدار النواة.
  • هو 2، لا يوجد تطابق للمصفوفة. تقرأ كائنات VINTF متطلبات kernel من المصفوفة في الإصدار 2 من FCM بدلاً من ذلك.

ومن ثم، تتم مطابقة إصدار النواة. إذا أبلغ جهاز في 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> تمامًا مع النص بعد علامة المساواة (بما في ذلك علامات الاقتباس)، حتى حرف السطر الجديد أو # ، مع اقتطاع المسافة البيضاء البادئة واللاحقة.

يعد تكوين 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"

يعد تكوين kernel التالي مثالاً على المطابقة غير الناجحة:

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 (على سبيل المثال، 1.0، 2.1). للحصول على التفاصيل، راجع الإصدار والتوافق . يحتوي إصدار AVB على خصائص النظام التالية:

  • ro.boot.vbmeta.avb_version هو إصدار libavb في أداة تحميل التشغيل
  • ro.boot.avb_version هو إصدار libavb في نظام التشغيل Android ( init/fs_mgr )

تظهر خاصية النظام فقط عند استخدام libavb المقابل للتحقق من بيانات تعريف AVB (وترجع موافق). وهو غائب إذا حدث فشل في التحقق (أو لم يحدث أي تحقق على الإطلاق).

تقارن مطابقة التوافق ما يلي:

  • 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 لا يعكس التوافق بعد OTA.

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

  1. قم باختيار CLs التالية لشجرة مصدر 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> ، فسيتم البحث عن إدخال <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.

يتطابق إصدار System 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 ليس متطابقًا، لأنه لم يتم توفير الإصدار 27 من System SDK.