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

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

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

عند تحديد إصدار "المراسلة عبر السحابة الإلكترونية من Firebase" الذي يستهدف الجهاز للأجهزة الجديدة:

1. مغادرة DEVICE_MANIFEST_FILE و السمة PRODUCT_ENFORCE_VINTF_MANIFEST غير محددة.
2. تنفيذ HALs لإصدار "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدف.
3. اكتب ملف بيان الجهاز الصحيح.
4. اكتب إصدار FCM المستهدف في ملف بيان الجهاز.
5. ضبط DEVICE_MANIFEST_FILE
6. اضبط السمة PRODUCT_ENFORCE_VINTF_MANIFEST على true.

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

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

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

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

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

عند ترقية صورة البائع لجهاز قديم، يمكن للبائعين اختيار تنفيذ إصدارات HAL جديدة وزيادة إصدار ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدف

ترقية HALs

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

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

للتلخيص، لأنّ السمة compatibility_matrix.2.xml تتطلّب الصوت 2.0 وcompatibility_matrix.3.xml يتطلب الصوت 4.0، ويجب والمتطلبات هي على النحو التالي:

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

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

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

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

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

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

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

ربط متطلبات النواة أثناء النقل عبر الهواء

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

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

• CL 722283
• CL 722284
• CL 722345

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

• عند التحديث إلى الإصدار 10 من Android، عملاء OTA على الأجهزة التي تعمل بنظام Android 9 أو الأقل لا تتحقق من متطلبات النواة في حزمة 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 على الأجهزة التي تعمل بنظام Android 10 اقرأ هذه المعلومات للتحقق التوافق.
• عند التحديث إلى الإصدار Android 11، تصنيف حزمة التحديث عبر الهواء قراءة إصدار النواة والتهيئة للتحقق من التوافق.

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

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

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