دورة حياة إف سي إم

يحتوي إصدار إطار عمل Android على مصفوفات توافق إطار عمل متعددة (FCMs)، واحدة لكل إصدار Target FCM قابل للترقية، والتي تحدد ما قد يستخدمه إطار العمل ومتطلبات إصدار Target FCM. كجزء من دورة حياة FCM، يقوم Android بإهمال وإزالة HIDL HALs، ثم يقوم بتعديل ملفات FCM لتعكس حالة إصدار HAL .

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

المصطلح

مصفوفة توافق الإطار (FCM)
ملف XML يحدد متطلبات إطار العمل بشأن تطبيقات البائعين المطابقة. يتم إصدار مصفوفة التوافق، ويتم تجميد إصدار جديد لكل إصدار إطار عمل. يحتوي كل إصدار إطاري على عدة FCMs.
إصدارات منصة FCM (S F )
مجموعة جميع إصدارات FCM في إصدار الإطار. يمكن أن يعمل إطار العمل مع أي تطبيق بائع يرضي أحد هذه FCMs.
نسخة FCM (F)
أعلى إصدار بين جميع FCMs في إصدار الإطار.
إصدار FCM المستهدف (V)
تم الإعلان عن إصدار FCM المستهدف (من S F )، بوضوح في بيان الجهاز، أن تنفيذ البائع يرضي. يجب إنشاء تطبيق البائع وفقًا لـ FCM المنشور، على الرغم من أنه قد يعلن عن إصدارات HAL أحدث في بيان الجهاز الخاص به.
نسخة هال
إصدار HAL له التنسيق foo@xy ، حيث foo هو اسم HAL و xy هو الإصدار المحدد؛ على سبيل المثال nfc@1.0 و keymaster@3.0 (تم حذف البادئة الجذرية، على سبيل المثال android.hardware ، في هذا المستند.)
بيان الجهاز
ملفات XML التي تحدد إصدارات HAL التي يوفرها جانب الجهاز من واجهة البائع، بما في ذلك صور المورد وODM. تكون محتويات بيان الجهاز مقيدة بإصدار Target FCM الخاص بالجهاز، ولكن يمكن أن تدرج HALs الأحدث تمامًا بالنسبة لـ FC المطابق لـ V.
أجزاء طبقة الأجهزة (HALs) الخاصة بالجهاز
شرائح HALs المدرجة (المقدمة) في بيان الجهاز والمدرجة (إما مطلوبة أو اختيارية) في مصفوفة توافق إطار العمل (FCM).
مصفوفة توافق الأجهزة (DCM)
ملف XML يحدد متطلبات البائع بشأن تطبيقات إطار العمل المطابقة. يحتوي كل جهاز على DCM واحد.
بيان الإطار
ملف XML يحدد إصدارات HAL التي يوفرها جانب إطار العمل لواجهة البائع، بما في ذلك صور النظام وsystem_ext وصور المنتج. يتم تعطيل HALs الموجودة في بيان إطار العمل ديناميكيًا وفقًا لإصدار Target FCM الخاص بالجهاز.
HALs الإطار
HALs المدرجة كما هو منصوص عليه في بيان إطار العمل والمدرجة على أنها مطلوبة أو اختيارية في مصفوفة توافق الجهاز (DCM).

دورة حياة FCM في قاعدة التعليمات البرمجية

تصف هذه الوثيقة دورة حياة FCM بشكل ملخص. لرؤية البيانات المدعومة حاليًا، ارجع إلى hardware/interfaces/compatibility_matrix.<FCM>.xml حيث يمكن العثور على FCM في system/libvintf/include/vintf/Level.h .

اعتبارًا من Android 14، المستويات المدعومة هي:

إف سي إم نسخة أندرويد
4 أندرويد 10/س
5 أندرويد 11/ر
6 أندرويد 12/س
7 أندرويد 13/ت
8 أندرويد 14/يو

التطوير في إصدار FCM جديد

يقوم Android بزيادة إصدار FCM لكل إصدار إطار عمل (مثل Android 8، 8.1، وما إلى ذلك). أثناء التطوير، يتم إنشاء compatibility_matrix.F.xml الجديد ولم يعد compatibility_matrix.f.xml الموجود (حيث f < F ) يتغير.

لبدء التطوير في إصدار FCM جديد F :

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

تقديم HAL جديد

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

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

على سبيل المثال، قدم Android 8.1 cas@1.0 باعتباره HAL اختياريًا. الأجهزة التي يتم تشغيلها باستخدام Android 8.1 ليست مطلوبة لتنفيذ طبقة 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 ترقية إصدار ثانوي من xz إلى x.(z+1) في إصدار FCM الحالي F ، إذا كان هذا الإصدار هو:

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

على سبيل المثال، قدم Android 8.1 broadcastradio@1.1 كترقية ثانوية للإصدار 1.0 HAL. الإصدار الأقدم، broadcastradio@1.0 ، اختياري للأجهزة التي تعمل بنظام Android 8.0 بينما الإصدار الأحدث، broadcastradio@1.1 ، اختياري للأجهزة التي تعمل بنظام Android 8.1. في 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 كترقية للإصدار الرئيسي لـ 1.0 HAL ويتجاهل 1.0 HAL. الإصدار الأقدم، health@1.0 ، اختياري للأجهزة التي تعمل بنظام التشغيل Android 8.0 وAndroid 8.1. يجب ألا توفر الأجهزة التي تعمل بنظام التشغيل Android 9 الإصدار 1.0 HAL المهمل، ويجب بدلاً من ذلك توفير الإصدار 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>

قيود:

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

إصدارات FCM الجديدة

تتم عملية إصدار إصدار FCM على قسم النظام بواسطة Google فقط كجزء من إصدار AOSP وتتضمن الخطوات التالية:

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

على سبيل المثال، تضمن اختبارات VTS أن الأجهزة التي تعمل بنظام التشغيل Android 9 لديها إصدار FCM المستهدف >= 3.

بالإضافة إلى ذلك، قد يقوم المنتج وsystem_ext FCM أيضًا بإدراج متطلبات كل إصدار من إصدارات FCM للنظام الأساسي. يتم إصدار إصدارات FCM على أقسام المنتج وsystem_ext بواسطة مالك هذه الصور، على التوالي. يجب أن تتم محاذاة أرقام إصدارات FCM الموجودة على المنتج وأقسام system_ext مع الأرقام الموجودة على قسم النظام. على غرار إصدارات FCM الموجودة على قسم النظام، تعكس مصفوفة التوافق في الإصدار FCM F في قسمي المنتج وsystem_ext المتطلبات على جهاز ذي الإصدار FCM المستهدف F.

إهمال إصدار HAL

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

إهمال جهاز HAL

عندما يتم إهمال جهاز معين HAL foo@xy في FCM الإصدار F ، فهذا يعني أن أي جهاز يتم تشغيله باستخدام Target FCM الإصدار V = F أو إصدار أحدث يجب ألا يطبق foo في الإصدار xy أو أي إصدار أقدم من xy . لا يزال إصدار HAL المهمل مدعومًا بواسطة إطار عمل ترقية الأجهزة.

عند إصدار FCM الإصدار F ، يعتبر إصدار HAL foo@xy مهملاً إذا لم يتم ذكر إصدار HAL المحدد صراحةً في أحدث FCM لـ Target FCM Version 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 و التوافق_matrix.2.xml . ومن ثم، يعتبر health@1.0 مهملاً.

إهمال إطار HAL

عندما يتم إهمال إطار عمل معين HAL foo@xy في FCM الإصدار F ، فهذا يعني أن أي جهاز يتم تشغيله باستخدام Target FCM الإصدار V = F أو إصدار أحدث يجب ألا يتوقع أن يوفر إطار العمل foo في الإصدار xy ، أو في أي إصدار أقدم من xy . لا يزال يتم توفير إصدار HAL المهمل بواسطة إطار عمل ترقية الأجهزة.

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

على سبيل المثال، في نظام التشغيل Android 12، تم إهمال schedulerservice@1.0 . تم تعيين سمة max-level على 5 ، وهو إصدار FCM المقدم في Android 11. راجع بيان إطار عمل Android 12 .

إزالة الدعم لإصدارات FCM المستهدفة

عندما تنخفض الأجهزة النشطة لإصدار Target FCM V معين إلى ما دون حد معين، تتم إزالة إصدار Target FCM من مجموعة S F لإصدار إطار العمل التالي. ويتم ذلك من خلال الخطوتين التاليتين:

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

  2. إزالة HALs لإطار العمل max-level أقل من أو يساوي V من بيان إطار العمل، وحذف أي تعليمات برمجية تنفذ HALs لإطار العمل الذي تمت إزالته.

لا يمكن للأجهزة التي تحتوي على إصدار FCM مستهدف خارج S F لإصدار إطار عمل معين الترقية إلى هذا الإصدار.

حالة إصدار HAL

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

غير منشور

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

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

بالنسبة لـ HALs لإطار العمل، إذا كان إصدار HAL موجودًا فقط في بيان إطار العمل لفرع تطوير غير ذي صلة، فسيتم اعتباره غير منشور.

الصادرة والحالية

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

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

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

تم إصداره ولكن تم إهماله

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

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

أمثلة:

ومن ثم power@1.0 هو أمر حالي، ولكن لم يتم إهماله في Android 9.

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

إزالة

بالنسبة لـ HALs للجهاز، تتم إزالة إصدار HAL إذا تحقق ما يلي فقط:

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

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

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

  • تم إصداره سابقًا.
  • إنه ليس في أي بيان إطاري لأحدث فرع تم إصداره.

أجهزة FCM القديمة

يعد الإصدار القديم من إصدار FCM المستهدف قيمة خاصة لجميع الأجهزة التي لا تحتوي على Treble. يسرد FCM القديم، compatibility_matrix.legacy.xml ، متطلبات إطار العمل على الأجهزة القديمة (أي الأجهزة التي تم إطلاقها قبل Android 8.0).

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

تم إصدار إصدارات FCM

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

للعثور على إصدار FCM الذي تم إصداره مع إصدار Android محدد، راجع Level.h .