عملية إصدار صورة النواة (GKI) العامة

توضّح هذه الصفحة كيفية طرح "مؤشر جودة البحث من Google"، بما في ذلك الإصدارات الأسبوعية والشهرية والإصدارات خارج النطاق الزمني المعتاد في حالات الطوارئ. يهدف هذا المستند إلى منح المصنّعين الأصليّين للأجهزة إرشادات حول كيفية الحصول على GKI، بالإضافة إلى عملية حلول الصعوبات الملحّة خارج النطاق المعتاد. يمكن لمصنّعي المعدّات الأصلية أيضًا استخدام تطوير GKI للتعرّف على مزيد من المعلومات حول كيفية العمل مع فريق Android Kernel لتحسين النواة GKI لمنتجاتهم.

وتيرة إصدار GKI

يتم إصدار مؤشر GKI بشكل شهري بعد تجميد مؤشر KMI.

إصدار GKI لنظام التشغيل Android 13 و14 و15

لا ينطبق الجدول التالي إلا على android13-5.10 وandroid13-5.15 وandroid14-5.15.

لا ينطبق الجدول التالي إلا على android14-6.1 و android15-6.6.

إصدار GKI لنظام التشغيل Android 12

بعد أيار (مايو) 2024، يتم نشر إصدارات android12-5.10 GKI بوتيرة ربع سنوية ويتم نشرها في منتصف الشهر. لا ينطبق الجدول التالي إلا على android12-5.10 فقط.

إصدار GKI صالح للمصنّعين الأصليين

يمكن للمصنّعين الأصليين للأجهزة استخدام GKI إصدار Android GKI الذي تم إصداره مؤخرًا. يمكن للمصنّعين الأصليين للأجهزة طرح إصدارات حاصلة على اعتماد GKI شرط أن تكون متوافقة مع متطلبات LTS الواردة في ملف Android Security Bulletin (ASB).

إصدارات التطوير الأسبوعية

تتوفّر ملفات GKI الثنائية للاستخدام الذاتي من خلال Android CI أثناء دمج التغييرات. لن يتم اعتماد الإصدارات الأسبوعية، ولكن يمكن استخدامها كأحد المرجعات للتطوير والاختبار. لا يمكن استخدام الإصدارات الأسبوعية لإصدارات أجهزة الإنتاج للمستخدمين النهائيين.

الإصدارات المعتمَدة الشهرية

تحتوي الإصدارات الشهرية من GKI على boot.img تم اختباره ويتضمّن شهادة أدرجتها Google لإثبات أنّه تم إنشاء الملفات الثنائية من قاعدة رمز برمجي معروفة لمصدره.

كل شهر، يتم اختيار إصدار مرشح شهري لبرنامج GKI (غير معتمَد) بعد تاريخ الإيقاف النهائي لعمليات تسجيل الدخول، والذي يكون عادةً الإصدار الأسبوعي الثاني لشهر ذلك. بعد اختيار الإصدار التجريبي الشهري، لن يتم قبول التغييرات الجديدة في إصدار ذلك الشهر. وخلال فترة النافذة المغلقة، لا يمكن معالجة سوى إصلاحات الأخطاء التي تؤدي إلى إخفاق الاختبار. يخضع المرشح لإصدار التطبيق لعملية ضمان الجودة، كما هو موضّح في قسم تأهيل GKI، لضمان اجتياز اختبارات الامتثال في إصدار GKI+GKI باستخدام جهاز مرجعي بالإضافة إلى الحبار.

الشكل 1. المخطط الزمني لإصدار GKI

عملية إعادة التقديم في حالات الطوارئ

يشير إعادة التشغيل إلى عملية إعادة دمج ملف ثنائي وإعادة بنائه وإعادة اختباره و إعادة اعتماده بعد إصدار عام لنظام التشغيل GKI. يمكنك طلب إعادة إرسال ملف ثنائي معتمَد في أيّ من الظروف التالية:

• لتعديل قائمة الرموز
• لتطبيق حلّ على خطأ، بما في ذلك الأخطاء التي تم رصدها أثناء الموافقة على الإصدار في مختبر مشغّل شبكة الجوّال
• لإضافة مخطّط عمل المورّد.
• لتطبيق تصحيح على ميزة حالية
• لتطبيق تصحيح أمان (بعد 6 أشهر).

يتم دمج الرقع الأمنية تلقائيًا في فرع الإصدار لمدة تصل إلى 6 أشهر بعد إصدار الفرع. بعد انقضاء فترة الـ 6 أشهر، عليك طلب إعادة إرسال لتطبيق رموز تصحيح الأمان على فرع.

إرشادات طلب إعادة التدوير

قبل طلب إعادة فحص، يُرجى مراعاة الإرشادات التالية:

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

• لا يتم قبول طلبات إعادة التقييم إلا لفرع إصدار معيّن ولمدّة مناقشة لا تتجاوز ستة أشهر بعد الإصدار العلني الأولي. بعد ستة أشهر، تصبح الفروع مؤهّلة لإعادة الطرح فقط لإصلاحات الأمان المُشار إليها في نشرة أمان Android.

• عندما تؤدي متطلبات الإصدارات الطويلة المدى (LTS) ، المحدّدة في نشرة أمان Android (ASB) ، إلى عدم امتثال الإصدار الفرعي، يتم إيقافه نهائيًا. لا يتم قبول طلبات إعادة نشر الإصدارات للفروع التي سيتم إيقافها نهائيًا. يتم تضمين تاريخ إيقاف استخدام فرع إصدار معيّن من GKI في ملاحظات الإصدار الشهرية من GKI ضمن الإصدارات. وبالنسبة إلى التخطيط المستقبلي، يتم تعديل متطلبات الإصدارات الطويلة المدى في شهرَي أيار (مايو) ونوفمبر (تشرين الثاني) سنويًا. على سبيل المثال، لا يمكن استخدام الإصدار android12-5.10-2023-07 (5.10.177) من الفرع android12-5.10-2023-07 (5.10.177) بعد 1 أيار (مايو) 2024، لأنّه لا يتوافق مع متطلبات LTS في ASB-2024-05.

• لا تنطبق عمليات إعادة النشر إلا على إصلاحات الأخطاء العاجلة أو تعديلات قائمة الرموز أو لتطبيق تصحيح لإصلاح ميزة حالية.

• ويجب دمج جميع التصحيحات التي تتم إضافتها إلى فرع الإصدار الشهري داخل الفرع الرئيسي لتطوير GKI. على سبيل المثال، إذا كان مطلوبًا تصحيح برمجي لإعادة نشر الإصدار android12-5.10-2022-09، يجب دمجه في الإصدار android12-5.10.

• عليك اختيار التصحيحات من فرع تطوير GKI الرئيسي وتحميل التصحيح إلى فرع الإصدار الشهري.

• في طلب إعادة النظر، يجب تحديد أولوية (مستوى العجلة) للطلب. تساعد هذه الأولوية فريق GKI في مساعدة الشركاء بشكل أفضل في الوقت المناسب. بالنسبة إلى الطلبات الملحّة أو الحسّاسة للوقت، ضَع علامة على الأولوية P0. بالنسبة إلى طلبات P0 وP1، يجب أيضًا تبرير الحاجة الملحة. يقدّم الجدول التالي جدولاً يوضّح أولوية الخطأ ووقت حلّه (ESRT):

  درجة الأهمية	ESRT
  الأداة 0	يوما عمل
  الأداة 1	‫5 أيام عمل
  الأداة 2	10 أيام عمل
  الأداة 3	15 يوم عمل

• يجب إرسال طلب إعادة إرسال منفصل لكل فرع إصدار. على سبيل المثال، إذا كان يلزم إجراء إعادة فحص لكلّ من android12-5.10-2022-08 و android12-5.10-2022-09، عليك إنشاء طلبَي إعادة فحص.

• بعد تقديم إصدار ووضع علامة "تم إصلاحه" على طلب إعادة الفحص، يجب عدم إعادة فتح طلب إعادة الفحص لإضافة طلبات إعادة فحص أخرى. يجب إرسال طلب إعادة فحص جديد إذا كانت هناك تصحيحات إضافية يجب دمجها.

• لكلّ حملة ناجحة قيد المراجعة، أضِف العلامات التالية.

  • Bug: يجب إضافة رقم تعريف الخطأ إلى رسالة الإضافة لكل طلب ربط.
  • Change-Id: يجب أن يكون مطابقًا لرقم تعريف التغيير في التغيير في الفرع الأساسي.

• إذا كان طلب إعادة النظر يتطلّب ردًا منك ولم تردّ عليه في مهلة ثلاثة أيام عمل، يتم خفض الأولوية بمقدار مستوى واحد (على سبيل المثال، يتم خفض P0 إلى P1). في حال عدم تلقّي ردّ منك خلال أسبوعَين، يتم وضع علامة على الخطأ لن يتم إصلاحه (قديم).

إرسال طلب إعادة فحص

يوضّح المخطّط البياني التالي عملية إعادة التقديم. تبدأ العملية عندما يُرسل شريك المصنّع الأصلي للجهاز (أنت) طلب إعادة الفحص.

الشكل 2: عملية إعادة الطرح

للمشاركة في عملية إعادة التثبيت:

1. يُرجى ملء نموذج طلب إعادة النظر في GKI، ثم التواصل مع مدير حسابك الفني في Google على الفور. يؤدي هذا النموذج إلى حدوث خطأ في طلب إعادة إرسال العينة إلى GKI. تظهر لك أخطاء طلب إعادة النظر (المقدّم للطلب) وفريق GKI وأشخاص محدّدين تضيفهم إلى قائمة النسخة المرسَلة من الرسالة الإلكترونية الخاصة بالخطأ.
   • إذا كان لديك حلّ، يجب أن يشير الطلب إلى تصحيح الرمز المُرسَل في AOSP حتى تتمكّن Google من مراجعته. إذا لم يكن إرسال التصحيح ممكنًا، يجب إرفاق التصحيح كملف نصي بالطلب.
   • إذا لم يكن لديك حل، يجب أن يشتمل الطلب على أكبر قدر ممكن من المعلومات، بما في ذلك رقم إصدار النواة (kernel) وسجلاته، حتى يتمكّن Google من المساعدة في تصحيح المشكلة.
2. يراجع فريق Google GKI الطلب ويوافق عليه أو يحوّله إليك إذا احتاج إلى مزيد من المعلومات.
3. بعد الاتفاق على حلّ، يراجع فريق Google GKI (CR+2) التغيير. تبدأ عملية المراجعة الإطار الزمني لـ ESRT. يُدمج فريق GKI التغييرات وينشئها ويختبرها ويُجري اختبار التراجع ويُعتمد التغيير.
4. يتم إصدار الملف الثنائي على ci.android.com. وينتهي الإطار الزمني لـ ESRT ويضع فريق Google GKI علامة على الطلب بأنّه تم إصلاحه ويُشير إلى إصدار إعادة الطرح. سيتم أيضًا نشر إصدار إعادة الطرح على صفحة إصدارات "صورة النواة العامة" (GKI).

مؤهلات GKI

مكان الحصول على عناصر الإنشاء

يمكن الحصول على عناصر جميع الإصدارات من ci.android.com.

يمكنك العثور على مزيد من المعلومات حول عملية الدمج المستمر، بما في ذلك نتائج الاختبار في لوحة بيانات دمج Android المستمر.

الأسئلة الشائعة

في ما يلي بعض الأسئلة الشائعة حول عملية إصدار "شركاء المحتوى في Google".

هل من الممكن إنشاء ملف ثنائي جديد لـ GKI استنادًا إلى ملف GKI تم إصداره من قبل؟

نعم، يُعرف ذلك باسم إعادة اللف. تتوفّر عملية إعادة التثبيت طالما أنّ إصدار GKI المنشور (الذي يُطلب عليه إعادة التثبيت) يمتثل لمتطلبات قناة الدعم الطويل الأمد (LTS) في نشرة أمان Android (ASB).

هل من الممكن إعادة إنشاء ملفات GKI الثنائية؟

نعم، في ما يلي مثال:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

لإعادة إنتاج المثال، نزِّل manifest_$id.xml ونفِّذ العبارة التالية:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

يمكنك استرداد نسخة عناصر GKI من "out/.../dist".

هل تم إنشاء برنامج GKI الثنائي (بما في ذلك رمز التصحيح الدوّار في حالات الطوارئ) استنادًا إلى أحدث قاعدة رموز برمجية؟

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

• قرّر المصنّع الأصلي للجهاز والمصنّع الأصلي 2 استخدام إصدار GKI الثنائي اعتبارًا من تشرين الثاني (نوفمبر) 2021.
• يرصد كلّ من المصنّع الأصلي للجهاز (OEM1) والمصنّع الأصلي للجهاز (OEM2) مشاكل تتطلّب تصحيحات لتقديم الدعم. قد تكون هذه الرموز البرمجية مختلفة أو متماثلة.
• إنّ عمليات إعادة الطرح التي تم إجراؤها على الإصدار الثنائي لشهر تشرين الثاني (نوفمبر) 2021 تتضمّن إصلاحات لمشاكل حظر التشغيل التي أبلغ عنها كل من OEM1 وOEM2 خلال فترة إعادة الطرح، ولكن ليس هناك مزيد.
• يتم أيضًا تضمين المشاكل المذكورة في الفقرة الثانية في الإصدارات الشهرية اللاحقة من مؤشر GKI.

تتضمّن عملية إعادة الفحص في تشرين الأول (أكتوبر) جميع الرقع التي أرسلتها الشركة المصنّعة الأصلية للجهاز، ولكن تؤثر الرقع الأخرى التي أرسلتها الشركة المصنّعة الأصلية للجهاز في منتجاتنا، لأنّه لم يتم اختبارها على وجه التحديد مع منتجاتنا. هل من الممكن تضمين التصحيح فقط؟

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

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

هل هناك حالات تقدّم فيها Google معلومات محدّدة عن تصحيحات المصنّعين الأصليّين للأجهزة وسيناريوهات المشاكل، حتى يتمكّن المصنّعون الأصليّون للأجهزة من تقييم تأثير تصحيحات البرامج ومخاطرها عند تطبيقها على منتجاتهم؟

لن تُضيف Google أي تغيير إلى إصدار إعادة الطرح إلا بعد فهم المشكلة وجمع كل التفاصيل. يظهر ذلك في سجل التغييرات (commit message). لا تكشف Google عن الجهاز المحدّد الذي تتأثّر به المشكلة، ولكن يمكن لصنّاع المعدّات الأصلية العثور على وصف المشكلة وحلها في سجلّ التغييرات في أي وقت.