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

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

وتيرة إصدار GKI

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

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

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

الإصدارات المعتمَدة الشهرية من GKI تاريخ انتهاء تسجيل الوصول تاريخ جاهزية التحميل المُسبَق لتطبيق GKI هل هذا صحيح؟
نوفمبر 11 تشرين الثاني (نوفمبر) 2024 27 تشرين الثاني (نوفمبر) 2024 نعم
كانون الثاني (يناير) 14 كانون الثاني (يناير) 2025 31 كانون الثاني (يناير) 2025 نعم
مارس 14 آذار (مارس) 2025 31 آذار (مارس) 2025 نعم

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

الإصدارات المعتمَدة الشهرية من GKI تاريخ انتهاء تسجيل الوصول تاريخ جاهزية التحميل المُسبَق لتطبيق GKI هل هذا صحيح؟
تشرين الأول (أكتوبر) 1 تشرين الأول (أكتوبر) 2024 14 تشرين الأول (أكتوبر) 2024 نعم
نوفمبر 1 تشرين الثاني (نوفمبر) 2024 15 تشرين الثاني (نوفمبر) 2024 نعم
ديسمبر 2 كانون الأول (ديسمبر) 2024 16 كانون الأول (ديسمبر) 2024 نعم
كانون الثاني (يناير) 6 كانون الثاني (يناير) 2025 22 كانون الثاني (يناير) 2025 نعم

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

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

الإصدارات المعتمَدة الشهرية من GKI تاريخ انتهاء تسجيل الوصول تاريخ جاهزية التحميل المُسبَق لتطبيق GKI هل هذا صحيح؟
نوفمبر 1 تشرين الثاني (نوفمبر) 2024 15 تشرين الثاني (نوفمبر) 2024 نعم
فبراير 3 شباط (فبراير) 2025 17 شباط (فبراير) 2025 نعم

صلاحية إصدار GKI لشركات المصنّعين الأصليّين للأجهزة

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

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

يتم اختبار الإصدارات باستخدام Cuttlefish لضمان اجتياز الحدّ الأدنى من متطلبات الجودة.

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

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

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

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

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

مؤهّلات GKI

أنواع عمليات إنشاء GKI متطلبات الجودة Notes
أسبوعيًا اختبار Cuttlefish
  • بدء التشغيل
  • مجموعة فرعية من VTS
  • مجموعة فرعية من مجموعة أدوات اختبار التوافق (CTS)
  • غير معتمَد مخصّصة للاختبار وعرض جهاز
    فقط.
  • لا يمكن استخدامها لتشغيل الأجهزة.
شهريًا (معتمد) اختبار Cuttlefish
  • بدء التشغيل
  • VTS
  • CTS
اختبار الأجهزة المرجعية
  • بدء التشغيل
  • VTS
  • CTS
عمليات إعادة الدوران (معتمدة) اختبار Cuttlefish
  • بدء التشغيل
  • VTS
  • مجموعة فرعية من مجموعة أدوات اختبار التوافق (CTS)
اختبار الأجهزة المرجعية
  • بدء التشغيل
  • VTS
  • تم إنشاؤه استنادًا إلى إصدار معتمَد من 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 الذي يتم طرحه شهريًا. اطّلِع على المثال التالي لكيفية حدوث هذا النوع من السيناريوهات.

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

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

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

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

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

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