اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

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

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

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

مباريات HAL

تحدّد قاعدة المطابقة مع HAL إصدارات عناصر hal في ملف بيان يُعتقد أنّ مالك مصفوفة التوافق المقابلة يتيح استخدامها.

طبقات تجريد الأجهزة (HAL) الأصلية وHIDL

في ما يلي قواعد المطابقة الخاصة بطبقات HAL الأصلية وطبقات HAL المستندة إلى لغة تعريف واجهة HIDL:

يتم تقييم عناصر <hal> المتعددة باستخدام علاقة AND واحدة.
يمكن أن تتضمّن عناصر <hal> السمة <hal optional="true"> للإشارة إلى أنّها غير مطلوبة.

تحذير: لا تتوافق العلامة optional مع الإصدار 16 من نظام التشغيل Android والإصدارات الأحدث.

تكون عناصر <version> المتعددة ضمن عنصر <hal> واحد مرتبطة بعلاقة أو. إذا تم تحديد إصدارين أو أكثر، يجب تنفيذ إصدار واحد فقط. (راجِع مطابقة ناجحة لواجهة HAL لوحدة إدارة الحقوق الرقمية).
يتم تقييم عناصر <instance> و<regex-instance> المتعددة ضمن عنصر <hal> واحد باستخدام علاقة و واحدة عندما يكون <hal> مطلوبًا. (راجِع مطابقة HAL ناجحة لوحدة إدارة الحقوق الرقمية).

مثال: تطابق ناجح في طبقة تجريد الأجهزة (HAL) لأحد الوحدات

بالنسبة إلى طبقة تجريد الأجهزة (HAL) الإصدار 2.5، تكون قاعدة المطابقة على النحو التالي:

مصفوفة ملف البيان المطابق

2.5 ‫2.5-2.∞. في مصفوفة التوافق، 2.5 هو الاختصار الخاص بـ 2.5-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` في مصفوفة التوافق.

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

يتم تقييم عناصر <hal> المتعددة باستخدام علاقة AND واحدة.
يمكن أن تتضمّن عناصر <hal> السمة <hal optional="true"> للإشارة إلى أنّها غير مطلوبة.

تحذير: لا تتوافق العلامة optional مع الإصدار 16 من نظام التشغيل Android والإصدارات الأحدث.

يتم تقييم عناصر <instance> و<regex-instance> المتعددة ضمن <hal> نفسها باستخدام علاقة AND واحدة عندما يكون <hal> مطلوبًا. (راجِع مطابقة ناجحة لطبقة تجريد الأجهزة (HAL) مع وحدات متعدّدة.)

مثال: تطابق ناجح في طبقة تجريد الأجهزة (HAL) لأحد الوحدات

بالنسبة إلى طبقة تجريد الأجهزة (HAL) الإصدار 5، تكون قاعدة المطابقة كما يلي:

مصفوفة ملف البيان المطابق

5 ‫5-∞: في مصفوفة التوافق، 5 هو اختصار لـ 5-5.

مصفوفة	ملف البيان المطابق
`5`	‫5-∞: في مصفوفة التوافق، `5` هو اختصار لـ `5-5`.
`5-7`	‫5-∞: يشير إلى ما يلي: ‫5 هو الحد الأدنى للإصدار المطلوب، ما يعني أنّ البيان الذي يوفّر الإصدارات من 1 إلى 4 من HAL غير متوافق. ‫7 هو الحد الأقصى للإصدار الذي يمكن طلبه، ما يعني أنّ مالك مصفوفة التوافق (إطار العمل أو الجهاز) لن يطلب إصدارات تتجاوز 7. سيظل بإمكان مالك ملف البيان المطابق عرض الإصدار 10 (على سبيل المثال) عند طلب الإصدار 7. لا يعرف مالك مصفوفة التوافق سوى أنّ الخدمة المطلوبة متوافقة مع الإصدار 7 من واجهة برمجة التطبيقات. ‫-7 هي معلومات فقط ولا تؤثر في عملية تحديث البرامج عبر الهواء. وبالتالي، يظل الجهاز الذي يتضمّن طبقة تجريد الأجهزة (HAL) بالإصدار 10 في ملف البيان متوافقًا مع إطار عمل يحدّد `5-7` في مصفوفة التوافق.

5-7

‫5-∞: يشير إلى ما يلي:

‫5 هو الحد الأدنى للإصدار المطلوب، ما يعني أنّ البيان الذي يوفّر الإصدارات من 1 إلى 4 من HAL غير متوافق.
‫7 هو الحد الأقصى للإصدار الذي يمكن طلبه، ما يعني أنّ مالك مصفوفة التوافق (إطار العمل أو الجهاز) لن يطلب إصدارات تتجاوز 7. سيظل بإمكان مالك ملف البيان المطابق عرض الإصدار 10 (على سبيل المثال) عند طلب الإصدار 7. لا يعرف مالك مصفوفة التوافق سوى أنّ الخدمة المطلوبة متوافقة مع الإصدار 7 من واجهة برمجة التطبيقات.
‫-7 هي معلومات فقط ولا تؤثر في عملية تحديث البرامج عبر الهواء.

وبالتالي، يظل الجهاز الذي يتضمّن طبقة تجريد الأجهزة (HAL) بالإصدار 10 في ملف البيان متوافقًا مع إطار عمل يحدّد 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 المستهدف. على سبيل المثال، يحتوي الجهاز المذكور أعلاه على الإصدار 4 المستهدف من FCM، وإصدار FCM لنواة الجهاز هو 5 (لاحقة فرع النواة r).
إصدار FCM لنواة النظام أكبر من أو يساوي 5 (لاحقة فرع النواة r).

ملاحظة: إذا كان إصدار FCM للنواة يساوي إصدار FCM المستهدف وكان أكبر من أو يساوي 5، ليس من الضروري أن يحدّد ملف المصدر لبيان الجهاز الذي يحدّده DEVICE_MANIFEST_FILE إصدار FCM للنواة. تستنتج assemble_vintf تلقائيًا إصدار FCM لنظام التشغيل من إصدار FCM المستهدَف إذا كان إصدار FCM المستهدَف أكبر من أو يساوي 5.

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

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

إذا كان الجهاز يتضمّن الإصدار 4 من FCM (الذي تم إصداره في Android 10)، ولكنّه يعمل بنواة من فرع 4.19-r، يجب أن يحدّد بيان الجهاز ما يلي:

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

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

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

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

5.4.42-android12-0-00544-ged21d463f856

بعد ذلك، يحصل عنصر VINTF على إصدار Android من إصدار النواة، ويستخدمه لتحديد إصدار FCM للنواة. في هذا المثال، يعني android12 الإصدار 6 من FCM لنواة النظام (الذي تم إصداره في 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> هذه المتطلبات، يكون ذلك عدم تطابق.

مثال: اختيار متطلبات المطابقة

لنفترض الحالة الافتراضية التالية التي تحدّد فيها منصات إدارة الموافقة في /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 للنواة	إصدار النواة	المطابقة مع
‫3 (P)	غير محدد	`4.4.106`	ما مِن تطابق (اختلاف في الإصدار الثانوي)
‫3 (P)	غير محدد	`4.4.107`	`4.4-p`
‫3 (P)	غير محدد	`4.19.42`	`4.19-q` (راجِع الملاحظة التالية للجدول)
‫3 (P)	غير محدد	`5.4.41`	`5.4-r` (راجِع الملاحظة التالية للجدول)
‫3 (P)	‫3 (P)	`4.4.107`	`4.4-p`
‫3 (P)	‫3 (P)	`4.19.42`	ما مِن تطابق (ما مِن فرع نواة `4.19-p`)
‫3 (P)	‫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 (R)	`4.14.105`	`4.14-r`
‫4 (س)	‫5 (R)	`5.4.41`	`5.4-r`
‫5 (R)	غير محدد	أي واحد	تعذُّر اختبار VTS (يجب تحديد إصدار FCM لنواة الإصدار 5 من FCM المستهدف)
‫5 (R)	‫4 (س)	أي واحد	تعذُّر اختبار VTS (إصدار النواة من FCM أقل من إصدار FCM المستهدف)
‫5 (R)	‫5 (R)	`4.14.180`	`4.14-r`

ملاحظة: بالنسبة إلى الأجهزة التي تستخدم إصدارًا مستهدفًا من FCM أقل من 5 (R) وإصدارًا غير محدّد من FCM للنواة، يختار عنصر VINTF فرع النواة الذي يتضمّن أدنى لاحقة أكبر من إصدار FCM المستهدف مع إصدار النواة المطابق. في المثال أعلاه، يستخدم جهاز يعمل بالإصدار 3 من FCM (الإصدار P) فرع النواة 4.19-q لأنّ 4.19-q يحتوي على أدنى لاحقة بين جميع فروع النواة 4.19-*، أي [4.19-q, 4.19-r, 4.19-s]. لا يُسمح بهذا السلوك الخاص باختيار المتطلبات للأجهزة التي تستخدم الإصدار 5 (R) أو إصدارًا أحدث من FCM، لأنّه يجب تحديد إصدار 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 من 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>

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

إذا كان فرع النواة في بيان الجهاز هو 1، تنتقل العملية إلى الخطوة التالية ويتم التحقّق من إصدار النواة.
إذا كان فرع النواة في بيان الجهاز هو 2، لن يكون هناك تطابق مع المصفوفة. كائنات VINTF اقرأ متطلبات النواة من المصفوفة في الإصدار 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> المناسب، يجب أن يكون الإدخال المقابل متوفّرًا في /proc/config.gz لكل عنصر <config> بقيمة غير n، ويجب ألا يكون الإدخال المقابل متوفّرًا في /proc/config.gz لكل عنصر <config> بقيمة n. يجب أن يتطابق محتوى <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

SEPolicy matches

تتطلّب سياسة الأمان في نظام التشغيل Android مطابقة ما يلي:

تحدّد <sepolicy-version> نطاقًا مغلقًا من الإصدارات الثانوية لكل إصدار رئيسي. يجب أن يندرج إصدار SEPolicy الذي يبلّغ عنه الجهاز ضمن أحد النطاقات التالية ليكون متوافقًا مع إطار العمل. تتشابه قواعد المطابقة مع إصدارات HAL، وتحدث المطابقة إذا كان إصدار SEPolicy أعلى من الحد الأدنى للإصدار أو يساويه. الحد الأقصى للإصدار هو معلومات فقط.
يجب أن يكون <kernel-sepolicy-version>، أي إصدار قاعدة بيانات السياسات، أقل من security_policyvers() الذي يبلّغ عنه الجهاز.

مثال: تطابق ناجح مع SEPolicy

توضّح مصفوفة توافق إطار العمل معلومات 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، يعني ذلك أنّه تم العثور على تطابق.
يجب أن يكون إصدار SEPolicy أحد الإصدارات 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 مختلفة):

الشكل 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 أثناء التحديث عبر اتصال لاسلكي

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

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

اختَر تغييرات الرمز التالية في شجرة المصدر لنظام Android 9:
- CL 732261
- CL 732262
حدِّد 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. بعد التحديث عبر الأثير، يتم استخدام القيمة الجديدة في /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. لا يكون هناك تطابق إلا إذا كانت المجموعة مجموعة فرعية من إصدارات حزمة تطوير البرامج (SDK) المتوفّرة في النظام كما هو موضّح في manifest.system-sdk.version في بيان الحزمة.

في حالة خاصة، إذا لم يتم إدراج أي إصدارات من حِزم تطوير البرامج (SDK) الخاصة بالنظام في مصفوفة توافق الأجهزة، سيتم دائمًا اعتبارها متوافقة، لأنّ المجموعة الفارغة هي مجموعة فرعية من أي مجموعة.

مثال: تطابُق إصدار حزمة تطوير البرامج (SDK) مع إصدار النظام بنجاح

إذا كانت مصفوفة توافق الأجهزة تنص على المتطلبات التالية في حزمة تطوير البرامج (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>

المثال C ليس مطابقًا لأنّه لم يتم توفير الإصدار 27 من حزمة تطوير البرامج (SDK) للنظام.

قواعد المطابقة تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

مباريات HAL

طبقات تجريد الأجهزة (HAL) الأصلية وHIDL

مثال: تطابق ناجح في طبقة تجريد الأجهزة (HAL) لأحد الوحدات

مثال: مطابقة ناجحة لطبقة تجريد الأجهزة (HAL) لوحدة إدارة الحقوق الرقمية

واجهات AIDL HAL

مثال: تطابق ناجح في طبقة تجريد الأجهزة (HAL) لأحد الوحدات

مثال: تطابق ناجح لطبقة تجريد الأجهزة (HAL) مع وحدات متعددة

تطابقات النواة

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

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

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

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

مثال: اختيار متطلبات المطابقة

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

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

مثال: تطابق ناجح للبرنامج

SEPolicy matches

مثال: تطابق ناجح مع SEPolicy

تطابقات إصدار AVB

مثال: مطابقة ناجحة لإصدار AVB

مطابقة إصدار AVB أثناء التحديث عبر اتصال لاسلكي

تطابُق إصدارات مجموعة تطوير أصلية للمورّدين (VNDK)

مثال: تطابق إصدار VNDK بنجاح

تطابق إصدار حزمة تطوير البرامج (SDK) للنظام

مثال: تطابُق إصدار حزمة تطوير البرامج (SDK) مع إصدار النظام بنجاح

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