مراحل النشاط في خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"

يتضمّن إصدار إطار عمل Android العديد من مصفوفة التوافق مع إطار العمل (FCM)، حيث يتم تحديد ما يمكن أن يستخدمه إطار العمل ومتطلبات إصدار هذه الخدمة المستهدفة. كجزء من دورة حياة حزمة FCM، يوقف نظام Android استخدام واجهات HIDL HAL ويزيلها، ثم يعدّل ملفات FCM لتعكس حالة إصدار HAL.

لتفعيل عمليات التحديث عبر الهواء للإطارات الأساسية فقط في الأنظمة المتكاملة الخاصة بهم، على الشركاء الذين يوسّعون واجهات المورّدين أيضًا إيقاف واجهات HIDL HAL نهائيًا وإزالتها باستخدام الطرق نفسها.

المصطلحات

مصفوفة التوافق مع الإطار (FCM)
ملف XML يحدد متطلبات إطار العمل الخاصة بعمليات التنفيذ المطابقة من قِبل المورّد يتم إصدار إصدارات من مصفوفة التوافق ويتم تجميد إصدار جديد لكل إصدار لإطار العمل. يحتوي كل إصدار من إطار العمل على عمليات إرسال متعددة لرسائل FCM.
إصدارات النظام الأساسي لميزة "المراسلة عبر السحابة الإلكترونية من Firebase" (SF)
مجموعة جميع إصدارات "المراسلة عبر السحابة الإلكترونية من Firebase" في إصدار إطار عمل. يمكن أن يعمل إطار العمل مع أيّ عملية تنفيذ من قِبل المورّد تستوفي أحد إطارات عمل إدارة الموافقة هذه.
إصدار "إطار عمل إرسال الرسائل" (F)
أعلى إصدار من بين جميع إصدارات "إطار عمل إدارة الخدمات في السحابة الإلكترونية" في إصدار إطار العمل
الإصدار المستهدَف من "إطار عمل إدارة إشعارات Android" (V)
إصدار ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدف (من SF)، والذي تم الإعلان عنه صراحةً في بيان الجهاز، والذي يستوفيه تنفيذ المورّد. يجب أن يتم إنشاء عملية تنفيذ لدى المورّد استنادًا إلى خدمة FCM المنشورة، على الرغم من أنّه يمكن أن يعلن عن إصدارات HAL أحدث في بيان الجهاز
.
إصدار HAL
يكون إصدار HAL بالتنسيق foo@x.y، حيث يكون foo هو اسم HAL وx.y هو الإصدار المحدّد، مثل nfc@1.0 وkeymaster@3.0 (يتم حذف البادئة الجذر، مثل android.hardware، في جميع أنحاء هذا المستند).
بيان الجهاز
ملفات XML التي تحدّد إصدارات HAL التي يوفّرها جانب الجهاز من واجهة المورّد، بما في ذلك صور المورّد وصور ODM ويتم تقييد محتوى بيان الجهاز من خلال إصدار "المراسلة عبر السحابة الإلكترونية من Firebase المستهدف" من الجهاز، ولكن يمكن أن يدرج بروتوكولات HALs الأحدث مقارنةً بـ FC المقابل لـ V.
واجهات برمجة التطبيقات لأجهزة Android
HALs المدرَجة (المتوفّرة) في بيان الجهاز والمدرَجة (سواء كانت مطلوبة أو اختيارية) في مصفوفة توافق إطار العمل (FCM)
جدول توافق الأجهزة (DCM)
ملف XML يحدّد متطلبات المورّدين بشأن عمليات تنفيذ الإطار المتوافق يحتوي كل جهاز على وحدة DCM واحدة.
بيان إطار العمل
ملف XML يحدِّد إصدارات HAL التي يوفّرها جانب إطار العمل من واجهة المورّد، بما في ذلك نظام التشغيل وsystem_ext وصور المنتجات. يتم إيقاف واجهات HAL في بيان الإطار بشكل ديناميكي وفقًا لإصدار FCM المستهدف على الجهاز.
واجهات برمجة التطبيقات لإطار العمل
HALs المدرَجة على النحو الوارد في بيان إطار العمل والمدرَجة إما على أنّها مطلوبة أو اختيارية في مصفوفة توافق الأجهزة (DCM)

دورة حياة المراسلة عبر السحابة الإلكترونية من Firebase في قاعدة البيانات

يصف هذا المستند دورة حياة Firebase Cloud Messaging بشكل موجز. للاطّلاع على الملفات البيانية المتوافقة، يُرجى الرجوع إلى hardware/interfaces/compatibility_matrix.<FCM>.xml حيث يمكن العثور على "المراسلة عبر السحابة الإلكترونية من Firebase" في system/libvintf/include/vintf/Level.h.

من المتوقّع أن يكون لجهاز يعمل بالإصدار المقابل من نظام التشغيل Android قيمة FCM أكبر من أو تساوي المستوى المكافئ. على سبيل المثال، سيتضمّن الجهاز الذي يتم شحنه مع الإصدار 11 من نظام التشغيل Android بشكل عام المستوى 5 من إطار عمل Firebase للرسائل، ولكن يتم تنفيذ المستوى 6 من إطار عمل Firebase للرسائل أو إصدار أحدث، والذي يتضمّن متطلبات إضافية متنوعة محدّدة في مصفوفات التوافق. المستويات المتوافقة هي:

المراسلة عبر السحابة الإلكترونية من Firebase إصدار Android
4 Android 10/Q
5 الإصدار 11/R من نظام التشغيل Android
6 Android 12/S
7 Android 13/T
8 Android 14/U
202404 Android 15/V

أن يكون مستوى FCM مساويًا أو أحدث من مستوى واجهة برمجة التطبيقات الخاصة بالمطوِّر

عندما يوقف Android مستوى ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" نهائيًا، سيظل متاحًا للأجهزة الحالية. يُسمح للأجهزة التي تستهدف مستويات أقل من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" بشكل ضمني باستخدام HALs المُدرَجة في مستويات أحدث من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"، ما دامت متاحة في الفرع.

تطوير تطبيقك باستخدام إصدار جديد من "Firebase Cloud Messaging"

يزيد نظام التشغيل Android من إصدار "إطار عمل إرسال الرسائل" لكل إصدار من إطار العمل (مثل Android 8 و8.1). أثناء التطوير، يتم إنشاء compatibility_matrix.F.xml الجديدة ولن يتم تغيير compatibility_matrix.f.xml الحالي (حيث f < F).

لبدء تطوير تطبيقك باستخدام الإصدار F الجديد من إطار عمل Firebase للرسائل، اتّبِع الخطوات التالية:

  1. يمكنك نسخ آخر compatibility_matrix.<F-1>.xml إلى compatibility_matrix.F.xml.
  2. عدِّل سمة level في الملف إلى F.
  3. أضِف قواعد الإنشاء المقابلة لتثبيت مصفوفة التوافق هذه على الجهاز.

تقديم HAL جديد

أثناء التطوير، عند تقديم HAL جديد (Wi-Fi وNFC وما إلى ذلك) إلى Android على الإصدار الحالي من "المراسلة عبر السحابة الإلكترونية من Firebase" F، أضِف HAL إلى compatibility_matrix.F.xml باستخدام إعدادات optional التالية:

  • optional="false" إذا كان يجب تشغيل الأجهزة التي يتم شحنها مع V = F باستخدام HAL هذا
  • optional="true" إذا كان بإمكان الأجهزة التي يتم شحنها مع V = F تشغيل الأجهزة بدون طبقة تجريد الأجهزة (HAL) هذه.

على سبيل المثال، أدخل نظام التشغيل Android 8.1 cas@1.0 كواجهة HAL اختيارية. لا يُشترَط على الأجهزة التي تعمل بالإصدار 8.1 من نظام التشغيل Android تنفيذ طبقة تجريد الأجهزة (HAL) هذه، لذلك تمت إضافة الإدخال التالي إلى compatibility_matrix.F.xml (الذي كان يُعرف باسم compatibility_matrix.current.xml مؤقتًا أثناء تطوير هذا الإصدار):

<hal format="hidl" optional="true">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

ترقية HAL (إجراء بسيط)

أثناء التطوير، عندما يتم ترقية HAL إلى إصدار ثانوي من x.z إلى x.(z+1) في الإصدار الحالي من "المراسلة من خلال السحابة الإلكترونية من Firebase" F، إذا كان هذا الإصدار:

  • مطلوب على الأجهزة التي يتم تشغيلها باستخدام V = F، compatibility_matrix.F.xml يجب أن يشير إلى x.(z+1) وoptional="false".
  • هذا الإجراء غير مطلوب على الأجهزة التي يتم إطلاقها مع V = F، على "compatibility_matrix.F.xml" نسخ x.y-z والاختيارية من compatibility_matrix.<F-1>.xml وتغيير الإصدار إلى x.w-(z+1) (على جهاز w >= y).

على سبيل المثال، طرح نظام التشغيل Android 8.1 broadcastradio@1.1 كإصدار تكميلي ترقية لـ 1.0 HAL. الإصدار الأقدم، broadcastradio@1.0، اختياري للأجهزة التي تعمل بالإصدار 8.0 من Android، بينما الإصدار الأحدث، broadcastradio@1.1، اختياري للأجهزة التي تعمل بالإصدار 8.1 من Android. في compatibility_matrix.1.xml:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

تم نسخ هذا الإدخال إلى compatibility_matrix.F.xml وتعديله على النحو التالي:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

ترقية HAL (إجراء رئيسي)

أثناء التطوير، عندما يتم ترقية HAL إلى إصدار رئيسي في الإصدار الحالي من FCM F، تتم إضافة الإصدار الرئيسي الجديد x.0 إلى compatibility_matrix.F.xml باستخدام إعدادات optional التالية:

  • optional="false" بالإصدار x.0 فقط، إذا كانت الأجهزة التي يتم شحنها مزوّدة بنظام التشغيل V = F يجب أن يتم تشغيلها بالإصدار x.0.
  • optional="false" ولكن مع الإصدارات الرئيسية القديمة في علامة <hal> المعينة نفسها، إذا كان يجب تشغيل الأجهزة التي يتم شحنها مع V = F باستخدام HAL هذا، ولكن يمكن تشغيلها باستخدام إصدار رئيسي أقدم.
  • optional="true" إذا لم يكن على الأجهزة التي يتم شحنها مع V = F تشغيل HAL.

على سبيل المثال، يقدّم Android 9 health@2.0 كأحد الإصدارات الرئيسية التي تم ترقيتها من HAL 1.0، كما يوقف استخدام HAL 1.0 نهائيًا. الإصدار الأقدم health@1.0 هو اختياري للأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android و Android 8.1. يجب أن تشمل الأجهزة التي تعمل بنظام التشغيل Android 9 الإصدار 2.0 الجديد. على سبيل المثال، لنفترض أنّه compatibility_matrix.legacy.xml و compatibility_matrix.1.xml و compatibility_matrix.2.xml تتضمن هذا الإدخال:

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>;
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

انسخ هذا الإدخال إلى compatibility_matrix.F.xml وعدِّله على النحو التالي:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

التقييدات:

  • بما أنّ حزمة HAL 2.0 متوفّرة في compatibility_matrix.3.xml مع optional="false"، يجب أن تكون الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android مزوّدة بحزمة HAL 2.0.
  • بما أنّ HAL 1.0 غير متوفر في compatibility_matrix.3.xml، يجب ألا توفّر الأجهزة التي تعمل بالإصدار 9 من Android HAL 1.0 (لأنّه تم إيقاف هذا HAL نهائيًا).
  • بما أنّ حزمة HAL 1.0 متوفّرة في legacy/1/2.xml (إصدارات FCM القديمة التي يمكن لنظام التشغيل Android 9 العمل معها) كحزمة HAL اختيارية، يمكن لإطار عمل Android 9 العمل مع حزمة HAL 1.0 (التي لا تُعدّ إصدارًا تمت إزالته من حِزم HAL).

إصدارات المراسلة عبر السحابة الإلكترونية من Firebase الجديدة

تُجري Google وحدها عملية طرح إصدار من إطار عمل Firebase Cloud Messaging على قسم النظام كجزء من إصدار AOSP، وتتضمّن هذه العملية الخطوات التالية:

  1. تأكَّد من أنّ compatibility_matrix.F.xml يحتوي على السمة level="F".
  2. تأكَّد من إنشاء جميع الأجهزة وتشغيلها.
  3. عدِّل اختبارات VTS للتأكّد من أنّ الأجهزة التي يتم تشغيلها باستخدام أحدث إطار عمل (استنادًا إلى مستوى واجهة برمجة التطبيقات لإصدار التطبيق) تتضمّن الإصدار V >= F من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدَف.
  4. انشر الملف في AOSP.

على سبيل المثال، تتأكّد اختبارات VTS من أنّ الأجهزة التي يتم إطلاقها تعمل بالإصدار Android 9 تتضمّن إصدار "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدَف >= 3.

بالإضافة إلى ذلك، قد يُدرج كلّ من "النظام الأساسي" و"النظام_الإضافي" في إطار عمل Firebase Cloud Messaging أيضًا متطلبات كلّ إصدار من إصدارات "النظام الأساسي" في إطار عمل Firebase Cloud Messaging. يتولى مالك هذه الصور إصدار نُسخ "المراسلة عبر السحابة الإلكترونية من Firebase" على قسمَي المنتج وsystem_ext على التوالي. يجب أن تتطابق أرقام إصدار FCM في قسمَي product وsystem_ext مع الأرقام في قسم system. مثل إصدارات المراسلة عبر السحابة الإلكترونية من Firebase في قسم النظام، تعكس مصفوفة التوافق عند الإصدار F في قسمَي المنتج وsystem_ext المتطلبات على الجهاز الذي يستخدم الإصدار F المستهدَف من هذه الخدمة.

إيقاف إصدار HAL نهائيًا

إنّ إيقاف إصدار HAL هو قرار للمطوّرين (أي بالنسبة إلى AOSP HALs، تتخذ Google هذا القرار). وقد يحدث ذلك عند إصدار إصدار أحدث من HAL (سواء كان ثانويًا أو رئيسيًا).

إيقاف طبقة تجريد الأجهزة (HAL) للجهاز نهائيًا

عند إيقاف HAL foo@x.y لجهاز معيّن نهائيًا في الإصدار F من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"، يعني ذلك أنّ أي جهاز يتم تشغيله بالإصدار V = F من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدَف أو إصدار أحدث يجب ألا يستخدم foo في الإصدار x.y أو أي إصدار أقدم من x.y. لا يزال إطار عمل ترقية الأجهزة متوافقًا مع إصدار HAL المهجور.

عند طرح الإصدار F من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"، يُعدّ الإصدار foo@x.y من بروتوكول HAL متوقفًا إذا لم يتم ذكر إصدار HAL المحدّد بشكل صريح في أحدث إصدار من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" (FCM) المستهدَف V = F. بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل V = F، يجب استيفاء أحد الشروط التالية:

  • يتطلّب إطار العمل إصدارًا أعلى (رئيسيًا أو ثانويًا).
  • لم يعُد إطار العمل يتطلّب HAL.

على سبيل المثال، في Android 9، يتم تقديم 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 من "المراسلة عبر السحابة الإلكترونية من Firebase"، يعني ذلك أنّ أي جهاز يتم تشغيله بالإصدار المستهدَف V = F من "المراسلة عبر السحابة الإلكترونية من Firebase" أو الإصدارات الأحدث يجب ألا يتوقّع من إطار العمل توفير foo في الإصدار x.y أو أي إصدار أقدم من x.y. لا يزال إطار العمل يوفّر إصدار HAL متوقفًا لترقية الأجهزة.

عند طرح الإصدار F من Firebase Cloud Messaging، يتم اعتبار الإصدار foo@x.y من HAL متوقّفًا نهائيًا إذا كان ملف بيان إطار العمل يحدّد max-level="F - 1" للإصدار foo@x.y. بالنسبة إلى الأجهزة التي يتم إطلاقها باستخدام V = F، لا يوفّر إطار العمل رمز HAL foo@x.y. يجب ألا تُدرج مصفوفة توافق الأجهزة على الأجهزة التي يتم تشغيلها باستخدام V = F إطار العمل HALs مع max-level < V.

على سبيل المثال، في Android 12، تم إيقاف schedulerservice@1.0 نهائيًا. تم ضبط سمة max-level على 5، وهو إصدار ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" الذي تم تقديمه في الإصدار Android 11. يمكنك الاطّلاع على بيان إطار العمل Android 12.

إيقاف دعم إصدارات المراسلة عبر السحابة الإلكترونية من Firebase المستهدفة

عندما ينخفض عدد الأجهزة النشطة لإصدار معيّن من "إصدار المراسلة عبر السحابة الإلكترونية من Firebase المستهدف" V إلى ما دون حدّ معيّن ، تتم إزالة إصدار "إصدار المراسلة عبر السحابة الإلكترونية من Firebase المستهدف" من المجموعة SF لإصدار الإطار التالي. يتم ذلك من خلال الخطوتَين التاليتَين:

  1. إزالة compatibility_matrix.V.xml من قواعد الإنشاء (كي لا يتم تثبيته على صورة النظام) وحذف أي رمز برمجي نفَّذ الإمكانات التي تمت إزالتها أو اعتمد عليها

  2. إزالة واجهات برمجة التطبيقات لنظام التشغيل (HAL) ذات max-level أقل من أو يساوي V من بيان إطار العمل، وحذف أي رمز ينفذ واجهات برمجة التطبيقات لنظام التشغيل (HAL) التي تمّت إزالتها

لا يمكن للأجهزة التي تعمل بإصدار مستهدَف من إطار عمل Firebase خارج نطاق SF لإصدار إطار عمل معيّن الترقية إلى هذا الإصدار.

حالة إصدار HAL

توضّح الأقسام التالية (بترتيب زمني) الحالات المحتملة لإصدار HAL.

لم تُطرح

بالنسبة إلى واجهات HAL للأجهزة، إذا لم يكن إصدار HAL مُدرَجًا في أي من ملفّات قاعدة بيانات التوافق المفتوحة والمجمّدة، يُعتبر غير مُصدَر وقد يكون لا يزال قيد التطوير. ويشمل ذلك إصدارات HAL المتوفّرة في compatibility_matrix.F.xml فقط. أمثلة:

  • أثناء تطوير نظام التشغيل Android 9، تم اعتبار HAL health@2.0 ضمن طبقة تجريد الأجهزة (HAL) لم يتم إطلاقها ولم تكن متوفرة إلا في compatibility_matrix.3.xml.
  • لا يتوفّر HAL teleportation@1.0 في أيّ من مصفوفات التوافق التي تم إصدارها، ويُعتبَر أيضًا HAL لم يتم إصداره.

بالنسبة إلى HALs لإطار العمل، إذا كان إصدار HAL ضمن بيان إطار العمل فقط لفرع تطوير غير ذي صلة، يُعتبر هذا الإصدار لم يتم طرحه.

الإصدارات المنشورة والحالية

بالنسبة إلى واجهات HAL للأجهزة، يتم إصدار إصدار HAL إذا كان مدرجًا في أي مصفوفة توافق علني ومجمّدة. على سبيل المثال، بعد تجميد الإصدار 3 من إطار عمل Firebase Cloud Messaging ونشره في AOSP، يُعتبر واجهة برمجة التطبيقات health@2.0 HAL إصدارًا حاليًا تم إصداره من واجهة برمجة التطبيقات.

إذا كان إصدار HAL مُدرَجًا في مصفوفة توافق عامة ومجمدة تتضمّن أعلى إصدار من FCM، يكون إصدار HAL حاليًا (أي لم يتم إيقافه نهائيًا). على سبيل المثال، إنّ إصدارات HAL الحالية (مثل nfc@1.0 التي تم طرحها في compatibility_matrix.legacy.xml) والتي ما زالت متوفّرة في compatibility_matrix.3.xml تُعتبَر أيضًا إصدارات حالية أو صادرة من HAL.

بالنسبة إلى واجهات برمجة التطبيقات لإطار العمل، إذا كان إصدار HAL مضمّنًا في ملف بيان إطار العمل لأحدث إصدار تم طرحه بدون سمة max-level أو (بشكل غير معتاد) max-level يساوي أو أعلى من إصدار FCM الذي تم طرحه في هذا الإصدار، يُعتبر إصدار HAL الذي تم طرحه ويكون حاليًا. على سبيل المثال، تم إصدار ملف برمجة التطبيقات displayservice HAL وأصبح متوفّرًا في الإصدار 12 من نظام التشغيل Android، كما هو محدّد في ملف برمجة التطبيقات إطار عمل Android 12 manifest.

تم إصدارها ولكن تم إيقافها نهائيًا

بالنسبة إلى HALs للجهاز، يتم إيقاف إصدار HAL فقط في حالة استيفاء جميع الشروط التالية:

  • تم طرحه.
  • ولا يُدرج في مصفوفة التوافق العلنية والمجمّدة التي تتضمّن أعلى إصدار من FCM.
  • وهي متوفرة في مصفوفة توافق عامة ومجمدة لا يزال إطار العمل يقبلها.

أمثلة:

وبالتالي، فإنّ power@1.0 متوفّرة حاليًا، ولكن لم يتم إيقافها نهائيًا في Android 9.

بالنسبة إلى واجهات برمجة التطبيقات HAL للإطارات الأساسية، إذا كان إصدار HAL مُدرَجًا في بيان الإطار الأساسي لأحدث مسار تنمية قيد الإصدار مع سمة max-level أقل من إصدار FCM في هذا المسار، يُعتبر إصدار HAL هذا قد تم إصداره ولكن تم إيقافه نهائيًا. على سبيل المثال، تم إصدار schedulerservice HAL ولكن تم إيقافه نهائيًا في Android 12، كما هو موضّح في بيان إطار عمل Android 12.

مُزال

بالنسبة إلى واجهات HAL للأجهزة، تتم إزالة إصدار HAL إذا كان ما يلي صحيحًا فقط:

  • سبق أن تم إصداره.
  • إنه ليس في أي مصفوفة توافق عامة أو مجمّدة يدعمها إطار العمل.

يتم الاحتفاظ بمصفوفات التوافق المتاحة للجميع والمجمّدة، ولكن لا يتوافق معها الإطار العملي، في قاعدة البيانات لتحديد مجموعة إصدارات HAL التي تمّت إزالتها حتى تتمكّن من كتابة اختبارات VTS لضمان عدم توفّر HAL التي تمّت إزالتها على الأجهزة الجديدة.

بالنسبة إلى HALs في إطار العمل، لا تتم إزالة إصدار HAL إلا في حال استيفاء المتطلبات التالية:

  • سبق أن تم إصداره.
  • لا يتوفّر في أي ملف بيان إطار عمل للفرع الذي تم إصداره مؤخرًا.

ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" القديمة

الإصدار القديم من خدمة "إشعارات Google من خادم Firebase" هو قيمة خاصة لجميع الأجهزة غير المزوّدة بنظام التشغيل Treble. يسرد الإصدارcompatibility_matrix.legacy.xml من "إطار عمل إرسال الإشعارات من Google‏ (FCM)" القديم متطلبات استخدام الإطار على الأجهزة القديمة (أي الأجهزة التي تم طرحها قبل Android 8.0).

إذا كان هذا الملف متوفّرًا لخدمة FCM التي تعمل بالإصدار F، يمكن ترقية أي جهاز غير مزوّد بنظام التشغيل Treble إلى الإصدار F شرط أن يكون ملف بيان الجهاز متوافقًا مع هذا الملف. وتتّبع عملية الإزالة الإجراء نفسه المُتّبع في خدمات "إرسال إشعارات Google" لإصدارات "إرسال إشعارات Google" المستهدفة الأخرى (تتم إزالتها بعد انخفاض عدد الأجهزة النشطة التي تعمل بالإصدار 8.0 أو الإصدارات الأقدم عن حدّ معيّن).

إصدارات المراسلة عبر السحابة الإلكترونية من Firebase التي تم طرحها

يمكن العثور على قائمة بإصدارات "المراسلة عبر السحابة الإلكترونية من Firebase" التي تم إصدارها ضمن hardware/interfaces/compatibility_matrices.

للعثور على إصدار المراسلة عبر السحابة الإلكترونية من Firebase الذي تم إصداره مع إصدار Android معيّن، يُرجى الاطّلاع على Level.h.