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

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

وتيرة إصدار GKI

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

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

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

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

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

الإصدارات المعتمَدة كل ثلاثة أشهر

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

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

الشكل 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) التغيير. تبدأ المراجعة الإطار الزمني لتقييم مدى الامتثال. يُدمج فريق GKI التغييرات وينشئها ويختبرها ويُجري اختبار التراجع ويُعتمد التغيير.
4. يتم إصدار الملف الثنائي على ci.android.com. وينتهي الإطار الزمني لـ ESRT ويضع فريق Google GKI علامة على الطلب بأنّه تم إصلاحه ويُشار إلى إصدار إعادة الطرح. سيتم أيضًا نشر إصدار إعادة الطرح على صفحة إصدارات "صورة النواة العامة" (GKI).

مؤهّلات GKI

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

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

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

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

في ما يلي بعض الأسئلة الشائعة حول عملية إصدار مجموعات أدوات التطوير (GKI).

هل من الممكن إنشاء ملف ثنائي جديد لـ 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 الثنائي (بما في ذلك تصحيح التشغيل في وضع الطوارئ) استنادًا إلى أحدث قاعدة بيانات؟

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

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

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

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

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

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

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