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

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

إيقاع إصدار GKI

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

إصدار Android 13 و14 GKI

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

إصدارات GKI الشهرية المعتمدة	تاريخ قطع تسجيل الوصول	تاريخ جاهزية التحميل المسبق لـ GKI	مؤكد؟
اكتوبر	14 أكتوبر 2022	31 أكتوبر 2022	نعم
شهر نوفمبر	14 نوفمبر 2022	30 نوفمبر 2022	نعم
ديسمبر	9 ديسمبر 2022	21 ديسمبر 2022	نعم
يناير	17 يناير 2023	31 يناير 2023	نعم
شهر فبراير	15 فبراير 2023	28 فبراير 2023	نعم
يمشي	15 مارس 2023	31 مارس 2023	نعم
أبريل	13 أبريل 2023	28 أبريل 2023	نعم
يمكن	17 مايو 2023	31 مايو 2023	نعم
يونيو	15 يونيو 2023	30 يونيو 2023	نعم
يوليو	18 يوليو 2023	31 يوليو 2023	نعم
أغسطس	16 أغسطس 2023	31 أغسطس 2023	نعم
سبتمبر	14 سبتمبر 2023	29 سبتمبر 2023	نعم
اكتوبر	18 أكتوبر 2023	31 أكتوبر 2023	نعم
شهر نوفمبر	10 نوفمبر 2023	30 نوفمبر 2023	نعم
ديسمبر	7 ديسمبر 2023	22 ديسمبر 2023	نعم
يناير	16 يناير 2024	31 يناير 2024	نعم
شهر فبراير	13 فبراير 2024	29 فبراير 2024	نعم
يمشي	13 مارس 2024	29 مارس 2024	نعم
أبريل	16 أبريل 2024	30 أبريل 2024	نعم
يمكن	14 مايو 2024	31 مايو 2024	نعم
يونيو	12 يونيو 2024	28 يونيو 2024	نعم
يوليو	16 يوليو 2024	31 يوليو 2024	نعم
أغسطس	15 أغسطس 2024	30 أغسطس 2024	نعم
سبتمبر	17 سبتمبر 2024	30 سبتمبر 2024	نعم
اكتوبر	15 أكتوبر 2024	31 أكتوبر 2024	نعم
شهر نوفمبر	11 نوفمبر 2024	27 نوفمبر 2024	نعم
ديسمبر	6 ديسمبر 2024	23 ديسمبر 2024	نعم

اعتبارًا من يناير 2024، سنستأنف الإصدارات الشهرية من android14-5.15 وفقًا للإيقاع الشهري المحدد الموضح في الجدول أدناه.

إصدارات GKI الشهرية المعتمدة	تاريخ قطع تسجيل الوصول	تاريخ جاهزية التحميل المسبق لـ GKI	مؤكد؟
يناير	16 يناير 2024	31 يناير 2024	نعم
شهر فبراير	13 فبراير 2024	29 فبراير 2024	نعم
يمشي	4 مارس 2024	15 مارس 2024	نعم
أبريل	1 أبريل 2024	17 أبريل 2024	نعم
يمكن	1 مايو 2024	17 مايو 2024	نعم
يونيو	3 يونيو 2024	17 يونيو 2024	نعم
يوليو	1 يوليو 2024	15 يوليو 2024	نعم
أغسطس	1 أغسطس 2024	16 أغسطس 2024	نعم
سبتمبر	2 سبتمبر 2024	16 سبتمبر 2024	نعم
اكتوبر	1 أكتوبر 2024	14 أكتوبر 2024	نعم
شهر نوفمبر	1 نوفمبر 2024	15 نوفمبر 2024	نعم
ديسمبر	2 ديسمبر 2024	16 ديسمبر 2024	نعم

إصدار أندرويد 12 جي كي آي

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

إصدارات GKI الشهرية المعتمدة	تاريخ قطع تسجيل الوصول	تاريخ جاهزية التحميل المسبق لـ GKI	مؤكد؟
يوليو	3 يوليو 2023	14 يوليو 2023	نعم
سبتمبر	1 سبتمبر 2023	15 سبتمبر 2023	نعم
شهر نوفمبر	3 نوفمبر 2023	17 نوفمبر 2023	نعم
يناير	5 يناير 2024	19 يناير 2024	نعم
يمشي	4 مارس 2024	15 مارس 2024	نعم
يمكن	1 مايو 2024	17 مايو 2024	نعم

صلاحية بناء GKI لمصنعي المعدات الأصلية

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

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

باستخدام الحبار للتأكد من أنها تجتاز الحد الأدنى من الجودة .

تتوفر ثنائيات GKI للخدمة الذاتية من ci.android.com حيث يتم دمج التغييرات. لن يتم اعتماد الإصدارات الأسبوعية، على الرغم من أنه يمكن استخدامها كخط أساس للتطوير والاختبار. لا يمكن استخدام الإصدارات الأسبوعية لإصدارات أجهزة الإنتاج للمستخدمين النهائيين.

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

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

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

الشكل 1. الجدول الزمني لإصدار GKI

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

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

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

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

قبل طلب إعادة التشغيل، لاحظ الإرشادات التالية:

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

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

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

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

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

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

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

  أولوية	إسرت
  ص0	2 أيام عمل
  ص1	5 أيام عمل
  ص2	10 أيام عمل
  ص3	15 يوم عمل

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

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

• لكل CL قيد النظر، قم بإضافة العلامات التالية. يتم حظر التقدم في طلب إعادة التشغيل بدون هذه المعلومات.

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

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

تقديم طلب respin

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

الشكل 2. عملية إعادة الدوران

للدخول في عملية respin:

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

مؤهلات GKI

أنواع بنيات GKI	إنفاذ الجودة	ملحوظات
أسبوعي	اختبار الحبار حذاء طويل مجموعة فرعية من VTS مجموعة فرعية من CTS	غير معتمد. فقط للاختبار و إحضار الجهاز. لا يمكن استخدامها لإطلاق الأجهزة.
شهري (معتمد)	اختبار الحبار حذاء طويل VTS CTS اختبار الأجهزة المرجعية حذاء طويل VTS CTS
الإجابات (معتمدة)	اختبار الحبار حذاء طويل VTS مجموعة فرعية من CTS اختبار الجهاز المرجعي حذاء طويل VTS	مبني على هيكل معتمد من GKI. يتم اعتماد البناء بعد التأهيل.

أين يمكن الحصول على قطع أثرية للبناء

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

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

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

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

نعم، هذا هو المعروف باسم respin. يتم دعم عملية إعادة التشغيل طالما أن إصدار 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.

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

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

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

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

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