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

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

وتيرة إصدار تحديثات GKI

يتم إصدار GKI بوتيرة ربع سنوية بعد إيقاف KMI.

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

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

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

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

الإصدارات المعتمَدة الربع سنوية

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

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

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

عملية إعادة الفهرسة الطارئة

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

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

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

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

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

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

• لا يتم قبول طلبات إعادة البناء إلا لفرع إصدار معيّن لمدة أقصاها ستة أشهر بعد الإصدار العلني الأولي. بعد ستة أشهر، تكون الفروع مؤهَّلة لإعادة التدوير فقط إذا كانت تتضمّن حِزم أمان مذكورة في نشرة أمان Android.

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

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

• يجب أن يتم دمج جميع حِزم التصحيحات التي سيتم تضمينها في فرع الإصدار الفصلي في فرع تطوير 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، عليك إنشاء طلبَين لإعادة التدوير.

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

• لكلّ CL قيد الدراسة، أضِف العلامات التالية.

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

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

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

يوضّح الرسم البياني التالي عملية إعادة التدوير. تبدأ العملية عندما يرسل شريك OEM (أنت) طلب إعادة التدوير.

الشكل 2. عملية إعادة تدوير المحتوى

للبدء في عملية إعادة التدوير، اتّبِع الخطوات التالية:

1. املأ نموذج طلب إعادة تدوير مفتاح GKI. وتواصَل مع مدير حسابك الفني في Google على الفور. ينشئ هذا النموذج خطأً في طلب إعادة تدوير GKI. تظهر أخطاء طلب إعادة تدوير الرمز لك (مقدّم الطلب) وفريق GKI وأفراد محدّدين تضيفهم إلى قائمة النسخ إلى في الخطأ.
   • إذا كان لديك إصلاح جاهز، يجب أن يشير الطلب إلى عملية إرسال رمز التصحيح في AOSP لكي تتمكّن Google من مراجعته. إذا لم يكن من الممكن إرسال التصحيح، يجب إرفاقه كملف نصي بالطلب.
   • إذا لم يتوفّر لديك حلّ، يجب أن يتضمّن الطلب أكبر قدر ممكن من المعلومات، بما في ذلك رقم إصدار النواة والسجلات، حتى تتمكّن Google من المساعدة في تصحيح الخطأ.
2. يراجع فريق Google GKI الطلب ويوافق عليه أو يعيده إليك إذا كانت هناك حاجة إلى مزيد من المعلومات.
3. بعد الاتفاق على إصلاح، يراجع فريق GKI في Google الرمز (CR+2) الخاص بالتغيير. تبدأ المراجعة في الإطار الزمني لـ ESRT. يدمج فريق GKI التغيير وينشئه ويختبره للتأكّد من عدم حدوث تراجع، ثم يعتمده.
4. يتم إصدار البرنامج الثنائي إلى ci.android.com. تنتهي الفترة الزمنية المحدّدة لـ ESRT، ويضع فريق Google GKI علامة "تم الإصلاح" على الطلب، ويشير إلى إصدار إعادة التدوير. سيتم أيضًا نشر إصدارات respin على صفحة إصدارات Generic Kernel Image (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 الثنائي (بما في ذلك تصحيح الإصدار الطارئ) على أحدث قاعدة رموز؟

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

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

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

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

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

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

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