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

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

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

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

عند تحديد إصدار FCM المستهدَف للأجهزة الجديدة:

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

طرح أجهزة جديدة

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

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

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

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

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

ترقية HAL

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

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

باختصار، بما أنّ compatibility_matrix.2.xml يتطلب استخدام الإصدار 2.0 من تقنية الترميز الصوتي وcompatibility_matrix.3.xml يتطلب استخدام الإصدار 4.0 من تقنية الترميز الصوتي، فإنّ المتطلبات هي كما يلي:

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

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

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

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

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

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

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

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

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

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

• 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، يستخرج نص برمجي إصدار kernel وملفه العميق true من صورة kernel المثبَّتة.

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

إذا تعذّر على النص البرمجي استخراج هذه المعلومات لصورة نواة النظام، نفِّذ أحد يليه:

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

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