يحتوي إصدار إطار عمل Android على العديد من "مصفوفات توافق إطار العمل" (FCM)، واحدة لكل إصدار مستهدف من FCM يمكن ترقيته، وتحدّد هذه المصفوفات ما يمكن أن يستخدمه إطار العمل ومتطلبات الإصدار المستهدف من FCM. كجزء من دورة حياة FCM، توقف منصة Android نهائيًا عن استخدام حزم HAL المستندة إلى HIDL وتزيلها، ثم تعدّل ملفات FCM لتعكس حالة إصدار HAL.
لتفعيل تحديثات OTA التي تتضمّن إطار العمل فقط في الأنظمة المتكاملة الخاصة بالشركاء الذين يوسّعون نطاق واجهات المورّدين، يجب أيضًا إيقاف وحدات HAL المستندة إلى HIDL نهائيًا وإزالتها باستخدام الطرق نفسها.
المصطلحات
- مصفوفة توافق إطار العمل (FCM)
- ملف XML يحدّد متطلبات إطار العمل بشأن عمليات التنفيذ المتوافقة مع البائعين. يتم إصدار نسخة من مصفوفة التوافق، ويتم تجميد نسخة جديدة مع كل إصدار من إطار العمل. يحتوي كل إصدار من إطار العمل على عدة وحدات FCM.
- إصدارات FCM للمنصّة (SF)
- مجموعة جميع إصدارات FCM في إصدار إطار عمل. يمكن أن يعمل إطار العمل مع أي عملية تنفيذ من المورّد تستوفي أحد نماذج الموافقة والإدارة هذه.
- إصدار FCM (F)
- أعلى إصدار بين جميع رسائل FCM في إصدار إطار عمل.
- إصدار FCM المستهدف (V)
- إصدار FCM المستهدَف (من SF)، والذي تم تحديده بشكل صريح في بيان الجهاز، والذي يفي به تنفيذ المورّد. يجب إنشاء عملية تنفيذ خاصة بمورّد استنادًا إلى واجهة FCM منشورة، على الرغم من أنّه يمكنها الإعلان عن إصدارات أحدث من طبقة تجريد الأجهزة (HAL) في بيان الجهاز.
- إصدار طبقة تجريد الأجهزة (HAL)
- يتّبع إصدار HAL التنسيق
foo@x.y، حيث يمثّلfooاسم HAL وx.yيمثّل الإصدار المحدّد، مثلاًnfc@1.0أوkeymaster@3.0(يتم حذف البادئة الجذرية، مثلاًandroid.hardware، في جميع أجزاء هذا المستند). - بيان الجهاز
- ملفات XML التي تحدّد إصدارات HAL التي يوفّرها جانب الجهاز من واجهة المورّد، بما في ذلك صور المورّد والشركة المصنّعة للجهاز الأصلي (ODM). تخضع محتويات بيان الجهاز لإصدار FCM المستهدَف للجهاز، ولكن يمكن أن تتضمّن طبقات تجريد الأجهزة (HAL) أحدث من إصدار FCM المتوافق مع V.
- طبقات تجريد الأجهزة (HAL)
- طبقات تجريد الأجهزة (HAL) المُدرَجة (الموفَّرة) في بيان الجهاز والمُدرَجة في مصفوفة توافق إطار العمل (FCM).
- مصفوفة توافق الأجهزة (DCM)
- ملف XML يحدّد متطلبات المورّد بشأن عمليات تنفيذ إطار العمل المتوافق. يحتوي كل جهاز على وحدة تحكّم واحدة في إدارة الأجهزة الجوّالة.
- بيان إطار العمل
- ملف XML يحدّد إصدارات HAL التي يوفّرها جانب إطار العمل لواجهة المورّد، بما في ذلك صور النظام وsystem_ext والمنتج. يتم إيقاف HALs في بيان إطار العمل بشكل ديناميكي وفقًا لإصدار FCM المستهدف للجهاز.
- طبقات تجريد الأجهزة الخاصة بإطار العمل
- حِزم HAL المُدرَجة على أنّها متوفّرة في ملف بيان إطار العمل والمُدرَجة في مصفوفة توافق الأجهزة (DCM).
مراحل نشاط FCM في قاعدة الرموز
يوضّح هذا المستند دورة حياة FCM بشكل مجرّد. للاطّلاع على البيانات الوصفية المتوافقة، يُرجى الرجوع إلى hardware/interfaces/compatibility_matrices/compatibility_matrix.<FCM>.xml حيث يمكن العثور على FCM في system/libvintf/include/vintf/Level.h.
من المتوقّع أن يكون للجهاز الذي يتم شحن إصدار Android المتوافق معه قيمة FCM أكبر من أو تساوي المستوى المكافئ. على سبيل المثال، يكون مستوى FCM على الجهاز الذي يتم شحنه مع الإصدار 12 من نظام التشغيل Android هو 6 بشكل عام، ولكن يمكن أن يكون مستوى FCM 7 أو أعلى، ما يؤدي إلى تغيير سلوك Android وفرض استخدام أحدث واجهات برمجة تطبيقات خاصة بالمورّدين على النحو المحدّد في مصفوفات التوافق. في ما يلي المستويات المتوافقة مع Android 16:
| FCM | إصدار Android |
|---|---|
| 6 | Android 12/S |
| 7 | Android 13/T |
| 8 | Android 14/U |
| 202404 | Android 15/V |
| 202504 | Android 16/B |
يجب أن يكون مستوى FCM مساويًا لمستوى واجهة برمجة التطبيقات الخاصة بالمورّد أو أحدث منه.
عند الإعلان عن Project Treble، تم تصميم صور نظام Android لتكون متوافقة مع الإصدارات الثلاثة السابقة من عمليات التنفيذ الخاصة بالمورّدين (أربعة إصدارات إجمالاً). ولإتاحة استخدام الأجهزة لفترة أطول، تم تمديد هذه الفترة لتشمل الإصدار الحالي وستة إصدارات سابقة من FCM (أي سبعة إصدارات إجمالاً) للإصدار 202404 والإصدارات الأحدث.
عندما توقف Android نهائيًا مستوى معيّنًا من FCM، سيظل متاحًا للأجهزة الحالية. يُسمح ضمنيًا للأجهزة التي تستهدف مستويات FCM أقل باستخدام طبقات تجريد الأجهزة (HAL) المدرَجة في مستويات FCM أعلى، طالما أنّها متاحة في الفرع.
التطوير في إصدار جديد من FCM
يزيد نظام التشغيل Android إصدار FCM مع كل إصدار من إطار العمل (مثل Android 8 و8.1). أثناء عملية التطوير، يتم إنشاء compatibility_matrix.F.xml جديد، ولا يتم تغيير compatibility_matrix.f.xml الحالي (حيث f < F).
لبدء التطوير في إصدار جديد من FCM F:
- انسخ أحدث
compatibility_matrix.<F-1>.xmlإلىcompatibility_matrix.F.xml. - عدِّل سمة
levelفي الملف إلىF. - أضِف قواعد الإصدار المناسبة لتثبيت مصفوفة التوافق هذه على الجهاز.
تقديم طبقة تجريد أجهزة جديدة
أثناء عملية التطوير، عند إضافة طبقة تجريد أجهزة جديدة (مثل Wi-Fi وNFC وما إلى ذلك) إلى نظام التشغيل Android على إصدار FCM الحالي F، أضِف طبقة تجريد الأجهزة إلى compatibility_matrix.F.xml.
على سبيل المثال، قدّم الإصدار 8.1 من نظام التشغيل Android cas@1.0. يمكن للأجهزة التي تعمل بالإصدار 8.1 من نظام التشغيل Android تنفيذ طبقة HAL هذه، لذا تمت إضافة الإدخال التالي إلى compatibility_matrix.F.xml (الذي كان يُطلق عليه اسم compatibility_matrix.current.xml مؤقتًا أثناء تطوير هذا الإصدار):
<hal format="hidl">
<name>android.hardware.cas</name>
<version>1.0</version>
<interface>
<name>IMediaCasService</name>
<instance>default</instance>
</interface>
</hal>
ترقية طبقة تجريد الأجهزة (HAL) (إصدار ثانوي)
يتم احتساب إصدارات AIDL HAL كإصدارات ثانوية من HAL. تحتوي إصدارات واجهة HIDL على
major.minor إصدارات مثل 1.2.
أثناء عملية التطوير، عند ترقية إصدار AIDL HAL من 2 إلى 3 في إصدار FCM الحالي F، تتم إضافة الإصدار الجديد إلى إدخال HAL في compatibility_matrix.F.xml. يقبل حقل الإصدار في إدخال HAL نطاقات مثل 2-3.
على سبيل المثال، قدّمت خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" (FCM) على Android F foo@3 كترقية بسيطة لإصدار HAL. يتم استخدام الإصدار القديم، foo@2، للأجهزة التي تستهدف الإصدارات القديمة من FCM، بينما يمكن استخدام الإصدار الأحدث، foo@3، للأجهزة التي تستهدف الإصدار F من FCM على Android. يبدو الإدخال في رسائل FCM القديمة قبل الإصدار 2 على النحو التالي:
<hal format="aidl">
<name>foo</name>
<version>2</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
تم نسخ هذه الإدخال إلى compatibility_matrix.F.xml وتعديله ليتوافق مع الإصدار 3 على النحو التالي:
<hal format="aidl">
<name>foo</name>
<version>2-3</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
ترقية طبقة تجريد الأجهزة (HAL) (إصدار رئيسي)
أثناء عملية التطوير، عندما يتضمّن أحد مستويات تجريد الأجهزة (HAL) ترقية إلى إصدار رئيسي في الإصدار الحالي من FCM
(Version F)، تتم إضافة الإصدار الرئيسي الجديد x.0 إلى
compatibility_matrix.F.xml مع الإعدادات التالية:
- الإصدار
x.0فقط، إذا كان يجب أن يتم إطلاق الأجهزة التي يتم شحنها معV = Fباستخدامx.0. - مع الإصدارات الرئيسية القديمة في العلامة
<hal>نفسها، إذا كانت الأجهزة التي يتم شحنها معV = Fيمكنها التشغيل بإصدار رئيسي قديم.
على سبيل المثال، يقدّم إصدار FCM F foo@2.0 كترقية للإصدار الرئيسي من طبقة HAL 1.0، ويوقف نهائيًا طبقة HAL 1.0. يتم استخدام الإصدار القديم، foo@1.0، للأجهزة التي تستهدف إصدارات سابقة من FCM. يجب أن توفّر الأجهزة التي تستهدف الإصدار F من FCM الإصدار الجديد 2.0 إذا كانت توفّر طبقة تجريد الأجهزة (HAL). في هذا المثال، تحتوي إصدارات FCM السابقة على الإدخال التالي:
<hal format="hidl">
<name>foo</name>
<version>1.0</version>;
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
انسخ هذا الإدخال إلى compatibility_matrix.F.xml وعدِّله على النحو التالي:
<hal format="hidl">
<name>foo</name>
<version>2.0</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
التقييدات:
- بما أنّ الإصدار 1.0 من طبقة تجريد الأجهزة (HAL) غير متوفّر في
compatibility_matrix.F.xml، يجب ألا توفّر الأجهزة التي تستهدف الإصدارFمن FCM الإصدار 1.0 من طبقة تجريد الأجهزة (HAL) (لأنّ هذا الإصدار من طبقة تجريد الأجهزة (HAL) يُعدّ قديمًا). - بما أنّ الإصدار 1.0 من طبقة HAL متوفّر في إصدارات FCM القديمة، سيظل بإمكان إطار العمل العمل مع الإصدار 1.0 من طبقة HAL، وبالتالي سيكون متوافقًا مع الأجهزة القديمة التي تستهدف إصدارات FCM القديمة.
إصدارات FCM الجديدة
تتولّى Google وحدها عملية طرح إصدار من FCM على قسم النظام كجزء من إصدار AOSP، وتشمل هذه العملية الخطوات التالية:
- تأكَّد من أنّ
compatibility_matrix.F.xmlيتضمّن السمةlevel="F". - تأكَّد من إنشاء جميع الأجهزة وتشغيلها.
- تحديث اختبارات VTS
لضمان أنّ الأجهزة التي يتم إطلاقها باستخدام أحدث إطار عمل (استنادًا
إلى مستوى واجهة برمجة التطبيقات الخاصة بالشحن) تتضمّن الإصدار
V >= Fمن خدمة "المراسلة عبر السحابة الإلكترونية من Firebase". - نشر الملف على AOSP
على سبيل المثال، تضمن اختبارات VTS أنّ الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android تتضمّن الإصدار 3 من FCM أو إصدارًا أحدث.
بالإضافة إلى ذلك، قد تتضمّن رسائل FCM الخاصة بالمنتج وsystem_ext أيضًا متطلبات لكل إصدار من إصدارات FCM على كل منصة. يتم إصدار إصدارات FCM على أقسام المنتج وsystem_ext من قِبل مالك هذه الصور، على التوالي. يجب أن تتطابق أرقام إصدارات FCM على أقسام المنتج وsystem_ext مع أرقام الإصدارات على قسم النظام. على غرار إصدارات FCM في قسم النظام، تعكس مصفوفة التوافق في إصدار FCM F في أقسام المنتج وsystem_ext المتطلبات على جهاز بإصدار FCM F المستهدف.
إيقاف إصدار HAL
إيقاف إصدار HAL نهائيًا هو قرار يتخذه المطوّر (أي أنّ Google تتخذ القرار بشأن حزم HAL في AOSP). وقد يحدث ذلك عند طرح إصدار أعلى من HAL (سواء كان إصدارًا ثانويًا أو رئيسيًا).
إيقاف HAL لجهاز نهائيًا
عند إيقاف الإصدار foo@x.y من طبقة تجريد الأجهزة (HAL) لجهاز معيّن في الإصدار F من "المراسلة عبر السحابة الإلكترونية من Firebase"، يعني ذلك أنّه يجب ألا يتضمّن أي جهاز يتم إطلاقه بالإصدار V = F أو إصدار أحدث من "المراسلة عبر السحابة الإلكترونية من Firebase" الإصدار foo من طبقة تجريد الأجهزة (HAL) أو أي إصدار أقدم من x.y.x.y لا يزال إطار العمل يتيح استخدام إصدار قديم من طبقة HAL لترقية الأجهزة.
عند طرح الإصدار F من FCM، يُعد الإصدار foo@x.y من HAL متوقفًا نهائيًا إذا لم يتم ذكر إصدار HAL المحدّد بشكل صريح في أحدث إصدار من FCM للإصدار المستهدف V = F من FCM. بالنسبة إلى الأجهزة التي يتم إطلاقها مع V = F، يجب استيفاء أحد الشروط التالية:
- يتطلّب إطار العمل إصدارًا أحدث (إصدارًا رئيسيًا أو ثانويًا).
- لم يعُد الإطار يتطلّب طبقة تجريد الأجهزة.
على سبيل المثال، في الإصدار 9 من نظام التشغيل Android، تم تقديم health@2.0 كترقية رئيسية للإصدار 1.0 من طبقة HAL. تمت إزالة health@1.0 من compatibility_matrix.3.xml، ولكنّه متوفّر في compatibility_matrix.legacy.xml وcompatibility_matrix.1.xml وcompatibility_matrix.2.xml.
وبالتالي، تُعتبر السمة health@1.0 متوقفة نهائيًا.
إيقاف طبقة تجريد الأجهزة (HAL) لإطار عمل نهائيًا
عند إيقاف إحدى طبقات HAL foo@x.y في إطار العمل نهائيًا في الإصدار F من FCM، يعني ذلك أنّه يجب ألا يتوقّع أي جهاز يتم إطلاقه بالإصدار V = F أو إصدار أحدث من FCM أن يوفّر إطار العمل foo في الإصدار x.y أو أي إصدار أقدم من x.y. لا يزال إطار العمل يوفّر إصدارًا قديمًا من طبقة تجريد الأجهزة (HAL) لترقية الأجهزة.
عند طرح الإصدار F من FCM، يُعد الإصدار foo@x.y من طبقة تجريد الأجهزة (HAL) إصدارًا قديمًا إذا كان بيان إطار العمل يحدّد max-level="F - 1" للإصدار foo@x.y. بالنسبة إلى الأجهزة التي تعمل بالإصدار V = F، لا يوفّر إطار العمل foo@x.y من طبقة تجريد الأجهزة (HAL). يجب ألا تتضمّن مصفوفة توافق الأجهزة التي يتم طرحها مع V = F وحدات HAL للإطار التي تتضمّن max-level < V.
على سبيل المثال، في Android 12، تم إيقاف schedulerservice@1.0 نهائيًا. تم ضبط السمة max-level على 5، وهو إصدار "المراسلة عبر السحابة الإلكترونية من Firebase" الذي تم طرحه في Android 11. اطّلِع على ملف بيان إطار عمل Android 12.
إزالة إمكانية استهداف إصدارات معيّنة من "المراسلة عبر السحابة الإلكترونية من Firebase"
نستخدم عملية تستند إلى جدول زمني لتحديد موعد إزالة إصدار FCM المستهدف، وذلك للحفاظ على التوافق لفترات زمنية مطلوبة وتلبية متطلبات الشركاء للأجهزة التي تدوم لفترة أطول.
عندما نزيل إصدارًا مستهدفًا من FCM من المجموعة SF للإصدار التالي من إطار العمل، ننفّذ الخطوتَين التاليتَين:
أزِل
compatibility_matrix.V.xmlمن قواعد الإنشاء (كي لا يتم تثبيته على صورة النظام)، واحذف أي رمز برمجي نفّذ الإمكانات التي تمت إزالتها أو اعتمد عليها.إزالة طبقات HAL الخاصة بإطار العمل التي تكون قيمة
max-levelفيها أقل من أو تساويVمن بيان إطار العمل، وحذف أي رمز برمجي ينفّذ طبقات HAL الخاصة بإطار العمل التي تمت إزالتها
إيقاف تدريجي لإعدادات الإصدار
تتطلّب استراتيجية التفرّع في Trunk Stable، حيث يتم أخذ إصدارات المنصة الفصلية (QPR) مباشرةً من git_main بدلاً من فروع release-dev منفصلة، عملية إيقاف تدريجية. قد تتم إزالة إصدار من FCM من إصدارات trunk_staging المبكرة، مع إبقائه متاحًا في فرع الإصدار لاستيعاب الأجهزة التي تتلقّى إصدارات QPR على مدار العام.
عادةً، يتيح إصدار إطار العمل استخدام ستة إصدارات من FCM: إصدار حالي واحد وأربعة إصدارات سابقة وإصدار إضافي واحد لتوفير إصدارات QPR. يمكن أن يزداد هذا الرقم إذا كانت إصدارات معيّنة من FCM (مثل 202404 في Android 15) توفّر دعمًا إضافيًا لإطالة عمر الأجهزة.
لا يمكن ترقية الأجهزة التي تستخدم إصدارًا مستهدفًا من FCM خارج SF لإصدار معيّن من إطار العمل إلى هذا الإصدار.
إزالة طبقات HAL التي تم إيقافها نهائيًا
عند إزالة إصدار من FCM، لن تكون بعض واجهات HAL أو إصدارات واجهات HAL متوفّرة في أي من إصدارات FCM. وهذا يعني أنّ Android لم يعُد يتيح استخدامها على الإطلاق، حتى لترقية الأجهزة.
بعد إيقاف HAL نهائيًا، يزيل المطوّرون الإشارات إلى واجهة HAL هذه من Android، بما في ذلك رمز العميل في إطار العمل والتنفيذ التلقائي وحالات اختبار VTS.
إذا لم تكن هناك أي طبقات HAL متوافقة موروثة من طبقة HAL التي تتم إزالتها، يمكن إزالة تعريف طبقة HAL نفسه باتّخاذ بضع خطوات إضافية.
- أزِل تعريف واجهة HAL من رمز المصدر. ويشمل ذلك ملفات
*.aidlووحدةAndroid.bpaidl_interface. - إذا كان HIDL، أزِل الرمز HASH من
hardware/interfaces/current.txt. - إذا كان AIDL، أزِل الدليل
aidl_apiالذي يحتوي على ملفات AIDL المجمدة. - أزِل الواجهة من
hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.
حالة إصدار طبقة تجريد الأجهزة (HAL)
توضّح الأقسام التالية (بالترتيب الزمني) الحالات المحتملة لإصدار HAL.
لم تُطرح
بالنسبة إلى طبقات تجريد الأجهزة (HAL)، إذا لم يكن إصدار طبقة تجريد الأجهزة (HAL) متوفّرًا في أي من مصفوفات التوافق العامة والثابتة، يُعد هذا الإصدار غير متاح وقد يكون قيد التطوير.
ويشمل ذلك إصدارات طبقة تجريد الأجهزة (HAL) المتوفّرة في compatibility_matrix.F.xml فقط.
أمثلة:
- أثناء تطوير الإصدار 9 من نظام التشغيل Android، تم اعتبار
health@2.0HAL إصدارًا غير متاح من HAL، ولم يكن متوفّرًا إلا فيcompatibility_matrix.3.xml. - لا يتوفّر
teleportation@1.0HAL في أي من مصفوفات التوافق التي تم إصدارها، ويُعد أيضًا من حزم HAL التي لم يتم إصدارها.
بالنسبة إلى حِزم HAL الخاصة بإطار العمل، إذا كان إصدار حزمة HAL متوفّرًا فقط في بيان إطار العمل الخاص بفرع تطوير غير ذي صلة، يُعدّ هذا الإصدار غير متاح.
الإصدار الحالي
بالنسبة إلى طبقات تجريد الأجهزة (HAL)، إذا كان إصدار طبقة تجريد الأجهزة (HAL) متوفّرًا في أي مصفوفة توافق عامة وثابتة، يتم إصداره. على سبيل المثال، بعد تجميد الإصدار 3 من FCM ونشره في مشروع Android مفتوح المصدر (AOSP)، يتم اعتبار health@2.0 HAL إصدارًا حاليًا من HAL.
إذا كان إصدار HAL متوفّرًا في مصفوفة توافق عامة وثابتة تتضمّن أعلى إصدار FCM، يكون إصدار HAL هو الإصدار الحالي (أي غير متوقّف نهائيًا). على سبيل المثال، يتم أيضًا اعتبار إصدارات HAL الحالية (مثل nfc@1.0 التي تم طرحها في compatibility_matrix.legacy.xml) التي لا تزال متوفرة في compatibility_matrix.3.xml إصدارات HAL حالية وتم طرحها.
بالنسبة إلى حِزم HAL الخاصة بإطار العمل، إذا كان إصدار حزمة HAL متوفّرًا في بيان إطار العمل الخاص بأحدث فرع تم إصداره بدون السمة max-level أو (في حالات نادرة) مع السمة max-level بقيمة تساوي أو تزيد عن إصدار FCM الذي تم إصداره في هذا الفرع، يُعدّ إصدار حزمة HAL هذا إصدارًا تم إصداره وهو الإصدار الحالي. على سبيل المثال، تم إصدار
displayservice طبقة HAL وهي الإصدار الحالي في Android
12، كما هو محدّد في
بيان إطار عمل Android 12.
تم إصداره ولكن تم إيقافه نهائيًا
بالنسبة إلى طبقات تجريد الأجهزة (HAL)، يتم إيقاف إصدار طبقة تجريد الأجهزة نهائيًا إذا تم استيفاء جميع الشروط التالية فقط:
- تم طرحها.
- لا يتوفّر في مصفوفة التوافق العامة والثابتة التي تتضمّن أعلى إصدار من FCM.
- وهي متوفّرة في مصفوفة توافق عامة وثابتة لا يزال إطار العمل يتيح استخدامها.
أمثلة:
- تتوفّر واجهة HAL الخاصة بـ
health@1.0فيcompatibility_matrix.legacy.xmlوcompatibility_matrix.1.xmlوcompatibility_matrix.2.xml، ولكنّها غير متوفّرة فيcompatibility_matrix.3.xml. وبالتالي، يُعدّ هذا الإذن متوقفًا نهائيًا في Android 9. - تمت ترقية إصدار بسيط من طبقة تجريد الأجهزة (HAL) الخاصة بالطاقة في Android 9، ولكن
power@1.0لا يزال فيcompatibility_matrix.3.xml. -
power@1.0compatibility_matrix.legacy.xmlوcompatibility_matrix.1.xmlوcompatibility_matrix.2.xml - يحتوي
compatibility_matrix.3.xmlعلىpower@1.0-1.
وبالتالي، فإنّ power@1.0 هي الإصدار الحالي، ولكن لم يتم إيقافها نهائيًا في نظام التشغيل Android 9.
بالنسبة إلى حِزم HAL الخاصة بإطار العمل، إذا كان إصدار حزمة HAL متوفّرًا في بيان إطار العمل الخاص بأحدث فرع تم إصداره مع السمة max-level التي تقل عن إصدار FCM في هذا الفرع، يُعد إصدار حزمة HAL هذا متوفّرًا ولكنّه متوقف نهائيًا. على سبيل المثال، تم إصدار واجهة schedulerservice HAL ولكن تم إيقافها نهائيًا في Android 12، كما هو موضّح في بيان إطار عمل Android 12.
تمّت الإزالة
بالنسبة إلى طبقات تجريد الأجهزة (HAL)، تتم إزالة إصدار طبقة تجريد الأجهزة إذا تحققت الشروط التالية فقط:
- تم إصداره سابقًا.
- وهو غير مدرَج في أي مصفوفة توافق علنية وثابتة يتوافق معها إطار العمل.
يتم الاحتفاظ في قاعدة الرموز بمصفوفات التوافق المتاحة للجميع والمجمّدة وغير المتوافقة مع إطار العمل، وذلك لتحديد مجموعة إصدارات HAL التي تمت إزالتها، ما يتيح كتابة اختبارات VTS لضمان عدم توفّر وحدات HAL التي تمت إزالتها على الأجهزة الجديدة.
بالنسبة إلى حِزم HAL الخاصة بإطار العمل، تتم إزالة إصدار حزمة HAL إذا تم استيفاء الشروط التالية فقط:
- تم إصداره سابقًا.
- لا يتوفّر في أي بيان إطار عمل لأحدث فرع تم إصداره.
رسائل FCM القديمة
Target FCM Version legacy هي قيمة خاصة بجميع الأجهزة غير المتوافقة مع Treble. تسرد
إصدارات FCM القديمة، compatibility_matrix.legacy.xml، متطلبات
الإطار على الأجهزة القديمة (أي الأجهزة التي تم طرحها قبل Android 8.0).
إذا كان هذا الملف متوفّرًا لإصدار F من FCM، يمكن ترقية أي جهاز غير متوافق مع Treble إلى الإصدار F، شرط أن يكون بيان الجهاز متوافقًا مع هذا الملف. تتم إزالة هذه الخدمة باتّباع الإجراء نفسه المتّبع مع رسائل FCM المخصّصة لإصدارات FCM المستهدَفة الأخرى (تتم إزالتها بعد أن ينخفض عدد الأجهزة النشطة التي تعمل بإصدارات أقدم من 8.0 إلى ما دون حدّ معيّن).
إصدارات FCM التي تم طرحها
يمكنك الاطّلاع على قائمة بإصدارات "المراسلة عبر السحابة الإلكترونية من Firebase" التي تم طرحها ضمن
hardware/interfaces/compatibility_matrices.
للعثور على إصدار FCM الذي تم إصداره مع إصدار معيّن من Android، راجِع
Level.h.