تطوير بيان الأجهزة

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

تطوير أجهزة جديدة

عند تحديد إصدار FCM المستهدَف للأجهزة الجديدة، اتّبِع الخطوات التالية:

1. اترك السمتَين DEVICE_MANIFEST_FILE وPRODUCT_ENFORCE_VINTF_MANIFEST غير محدّدتين.
2. نفِّذ طبقات تجريد الأجهزة (HAL) لإصدار FCM المستهدَف.
3. كتابة ملف بيان الجهاز الصحيح
4. اكتب إصدار FCM المستهدف في ملف بيان الجهاز.
5. اضبط DEVICE_MANIFEST_FILE.
6. اضبط قيمة PRODUCT_ENFORCE_VINTF_MANIFEST على true.

إصدار أجهزة جديدة

عند طرح جهاز جديد، يجب تحديد إصدار FCM الأولي المستهدف والإفصاح عنه في بيان الجهاز كسمة "target-level" في عنصر <manifest> ذي المستوى الأعلى.

على سبيل المثال، يجب أن تستخدم الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android الإصدار 3 من خدمة FCM (وهو أحدث إصدار متاح في هذا الوقت). لإدراج ذلك في بيان الجهاز، اتّبِع الخطوات التالية:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

ترقية صورة المورّد

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

ترقية طبقات HAL

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

• تم طرح أجهزة Google Pixel 2 وPixel 2 XL مع الإصدار 2 المستهدف من FCM، والذي يتضمّن android.hardware.audio@2.0::IDeviceFactory/defaultHAL 2.0 المطلوب للصوت.
• بالنسبة إلى طبقة تجريد الأجهزة (HAL) الخاصة بالصوت 4.0 التي تم إصدارها مع Android 9، يمكن لأجهزة Google Pixel 2 وPixel 2 XL استخدام تحديث كامل عبر اتصال لاسلكي للترقية إلى طبقة تجريد الأجهزة (HAL) 4.0 التي تنفّذ android.hardware.audio@4.0::IDeviceFactory/default.
• على الرغم من أنّ compatibility_matrix.2.xml يحدّد الإصدار 2.0 من الصوت فقط، تم تخفيف شرط صورة المورّد التي تستخدم الإصدار 2 من FCM، لأنّ إطار عمل Android 9 (الإصدار 3 من FCM) يعتبر الإصدار 4.0 من طبقة HAL للصوت بديلاً عن الإصدار 2.0 من طبقة HAL للصوت من حيث الوظائف.

باختصار، بما أنّ compatibility_matrix.2.xml يتطلّب الإصدار 2.0 من الصوت وcompatibility_matrix.3.xml يتطلّب الإصدار 4.0 من الصوت، تكون المتطلبات على النحو التالي:

ترقية إصدار "مراسلة Firebase السحابية" المستهدف

أثناء ترقية صورة المورّد، يمكن للمورّدين أيضًا زيادة إصدار FCM المستهدف لتحديد إصدار FCM المستهدف الذي يمكن أن تعمل معه صورة المورّد التي تمت ترقيتها. لزيادة إصدار FCM المستهدف لجهاز معيّن، على المورّدين إجراء ما يلي:

1. تنفيذ جميع إصدارات HAL الجديدة المطلوبة لإصدار FCM المستهدف
2. تعديل إصدارات طبقة تجريد الأجهزة (HAL) في ملف بيان الجهاز
3. عدِّل إصدار FCM المستهدَف في ملف بيان الجهاز.
4. إزالة إصدارات HAL المتوقّفة نهائيًا

على سبيل المثال، تم إطلاق أجهزة Google Pixel وPixel XL مع الإصدار 7.0 من نظام التشغيل Android، لذا يجب أن يكون إصدار FCM المستهدف هو الإصدار القديم على الأقل. ومع ذلك، يوضّح ملف البيان الخاص بالجهاز أنّ الإصدار المستهدف من خدمة مراسلة Firebase السحابية هو 2 لأنّه تم تعديل صورة المورّد لتتوافق مع compatibility_matrix.2.xml:

<manifest version="1.0" type="device" target-level="2">

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

على سبيل المثال، يتضمّن جهازا Google Pixel 2 وPixel 2 XL الإصدار 2 المستهدف من FCM. وعلى الرغم من أنّها تنفّذ بعض طبقات تجريد الأجهزة (HAL) التي تتطلّبها compatibility_matrix.3.xml (مثل الإصدار 4.0 من الصوت والإصدار 2.0 من الصحة وما إلى ذلك)، إلا أنّها لا تزيل android.hardware.radio.deprecated@1.0، الذي تم إيقافه نهائيًا في الإصدار 3 من FCM (الإصدار 9 من نظام التشغيل Android). وبالتالي، لا يمكن لهذه الأجهزة ترقية إصدار FCM المستهدَف إلى الإصدار 3.

فرض متطلبات النواة أثناء التحديث عبر الهواء

تحديث الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم

على الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم، تأكَّد من اختيار CLs التالية:

• CL 722283
• CL 722284
• CL 722345

تتضمّن هذه التغييرات علامة الإنشاء PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS وتترك العلامة بدون ضبط للأجهزة التي تم إطلاقها باستخدام الإصدار 9 من نظام التشغيل Android أو إصدار أقدم.

• عند التحديث إلى Android 10، لا تتحقّق برامج OTA على الأجهزة التي تعمل بنظام التشغيل Android 9 أو الإصدارات الأقدم من متطلبات النواة بشكل صحيح في حزمة OTA. هذه التغييرات مطلوبة لإزالة متطلبات النواة من حزمة OTA التي تم إنشاؤها.
• عند التحديث إلى Android 11، يكون من الاختياري ضبط علامة الإنشاء PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS للتحقّق من توافق VINTF عند إنشاء حزمة التحديث.

لمزيد من المعلومات حول علامة الإصدار هذه، يُرجى الاطّلاع على تحديث الأجهزة من Android 10.

تحديث الأجهزة التي تعمل بالإصدار Android 10

يقدّم نظام التشغيل Android 10 علامة إنشاء جديدة، وهي PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. بالنسبة إلى الأجهزة التي تم طرحها مع نظام التشغيل Android 10، يتم ضبط هذه العلامة تلقائيًا على true. عند ضبط العلامة على true، يستخرج نص برمجي إصدار النواة وإعدادات النواة من صورة النواة المثبَّتة.

• عند التحديث إلى Android 10، تحتوي حزمة التحديث عبر شبكة غير سلكيّة (OTA) على إصدار النواة والإعدادات. تستند برامج OTA على الأجهزة التي تعمل بنظام التشغيل Android 10 إلى هذه المعلومات للتحقّق من التوافق.
• عند التحديث إلى Android 11، تقرأ عملية إنشاء حِزم التحديث عبر الأثير إصدار النواة والإعدادات للتحقّق من التوافق.

إذا لم يتمكّن النص البرمجي من استخراج هذه المعلومات لصورة النواة، يمكنك اتّخاذ أحد الإجراءَين التاليَين:

• عدِّل النص البرمجي ليتوافق مع تنسيق النواة وساهم في مشروع AOSP.
• اضبط BOARD_KERNEL_VERSION على إصدار النواة وBOARD_KERNEL_CONFIG_FILE على مسار ملف إعداد نواة الإصدار .config. يجب تعديل المتغيّرَين كليهما عند تعديل صورة النواة.
• بدلاً من ذلك، اضبط PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS على false لتخطّي التحقّق من متطلبات النواة. لا يُنصح بذلك لأنّ أي عدم توافق يكون مخفيًا ولا يتم اكتشافه إلا عند إجراء اختبارات VTS بعد التحديث.

يمكنك الاطّلاع على رمز المصدر لبرنامج استخراج معلومات النواة extract_kernel.py.