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

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

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

الأهلية ومراحل الاستخدام

• التوقيت: يمكنك طلب إعادة تدوير الرموز البرمجية في فروع الإصدارات فقط بعد إطلاق إصدار عام أولي من إصدار ربع سنوي. يجب عدم إرسال طلبات إعادة تدوير لخطافات المورّد أو الميزات الأخرى إلا لفرع إصدار معيّن لمدة أقصاها ستة أشهر بعد الإصدار العلني الأولي.
• الأمان وقناة الدعم الطويل الأمد (LTS): بعد ستة أشهر، تصبح الفروع مؤهَّلة لإعادة الإصدار فقط لرموز تصحيح الأمان الواردة في "نشرة أمان Android" (ASB) أو إصلاحات الأخطاء الحرجة.
• الإيقاف نهائيًا: عندما تؤدي متطلبات LTS المحدّدة في "نشرة أمان Android" (ASB) إلى عدم امتثال الفرع، يتم إيقاف الفرع نهائيًا. لا يتم قبول طلبات إعادة البناء والتصديق للفروع المتوقّفة نهائيًا.
  • يتم تضمين تاريخ الإيقاف النهائي لفرع إصدار GKI معيّن في ملاحظات إصدارات GKI الفصلية ضمن "الإصدارات". على سبيل المثال، يمكن استخدام إصدار سبتمبر 2025 مع عمليات إعادة الدوران حتى مارس 2027. يشير هذا التاريخ إلى مدة توفّر إصدار LTS 2.0 من النواة، وهي 18 شهرًا للإصدارات التي تبدأ في سبتمبر 2025 (كانت مدة توفّر الإصدارات قبل سبتمبر 2025 هي 12 شهرًا).
• النطاق: لا تطلب إعادة تدوير إلا لإصلاح الأخطاء العاجلة أو تحديثات قائمة الرموز أو تطبيق تصحيح لإصلاح ميزة حالية.

معايير إرسال حِزم التصحيح

لاستيفاء "الوقت المتوقّع لحلّ المشكلة" (ESRT) عند معالجة طلب إعادة تدوير العيّنة، يجب أن تلتزم جميع حِزم التصحيح التي يتم إرسالها إلى فرع إصدار بالقواعد الفنية التالية.

المصدر الموثوق والاختيار الانتقائي

• فرع التطوير أولاً: يجب دمج جميع حِزم التصحيح التي سيتم تضمينها في فرع الإصدار الربعي في فرع تطوير GKI الرئيسي. على سبيل المثال، إذا كان هناك رمز تصحيح مطلوب لإعادة البناء والتصديق android15-6.6-2025-08، يجب أن يكون قد تم دمجه في android15-6.6.
• الاختيار الدقيق النظيف: يجب الاختيار الدقيق للتصحيحات مباشرةً من فرع التطوير. لا تختار بشكل انتقائي من فروع إصدار أخرى (على سبيل المثال، لا تختار من 2025-08 إلى 2025-09)، لأنّ ذلك قد يؤدي إلى معلومات غير متسقة حول المؤلف أو عمليات الدمج مع الإصدار في فرع التطوير. لن يتم قبول التصحيحات التي تتضمّن معلومات غير متسقة.
• الاحتفاظ بالبيانات الوصفية: الاحتفاظ بالبيانات الوصفية الأصلية لعملية الإيداع (على سبيل المثال، المؤلف والطابع الزمني الأصلي) استخدِم git cherry-pick -x للحفاظ على البيانات الوصفية.

سلسلة عمليات الإرسال

• السلسلة التسلسلية: إذا كان طلب إعادة البناء والتصديق يتضمّن عدة رموز تصحيح، يجب تحميلها كسلسلة تسلسلية واحدة من عمليات الإتمام.
• موضع ABI وKMI: إذا كانت عملية إعادة البناء والتصديق للرقعات المتعددة تتضمّن تحديثات لواجهة وحدة النواة (KMI) وواجهة التطبيق الثنائية (ABI) (على سبيل المثال، تغييرات في قائمة الرموز أو تحديثات في ملفات تنسيق XML/STG)، ضَع عمليات الإتمام هذه في نهاية سلسلة عمليات الإتمام.
• إعادة الأساس: إذا عدّلت عملية تثبيت رئيسية في السلسلة، عليك إعادة ضبط جميع تصحيحات العناصر التابعة على أحدث نسخة من تصحيح العنصر الرئيسي لتجنُّب حدوث أخطاء في الإنشاء.
• حلّ التعارض: تأكَّد من عدم توفّر أي علامات تعارض في أي حزمة.
• التحقّق من الإصدار: يجب أن يتم إنشاء سلسلة الالتزام بأكملها بنجاح.

العلامات المطلوبة

يتم حظر التقدّم في طلب إعادة التدوير بدون العلامات التالية في رسالة الالتزام:

• ‫Change-Id: يجب أن يكون مطابقًا لـ Change-Id الخاص بتغيير فرع التطوير.
  • استثناء: إذا تم دمج رمز التصحيح في فرع التطوير كجزء من تحديث الدعم الطويل الأمد (LTS)، يجب أن يكون عبارة عن عملية الاختيار الدقيق من إصدار الدعم الطويل الأمد (LTS) وتنسيقه على أنّه رمز تصحيح UPSTREAM. يمكنك الاطّلاع على كيف يمكنني إرسال تصحيحات إلى "نواة Android الشائعة"؟.
• ‫Bug (الحالية): يجب عدم إزالة علامات Bug: XYZ الحالية من عملية الالتزام بفرع التطوير الأصلي.
• Bug (إعادة تدوير): يجب إضافة علامة Bug: XYZ جديدة، حيث يمثّل XYZ معرّف الخطأ المرتبط بطلب إعادة التدوير الحالي.
• عدِّل علامة الالتزام UPSTREAM إذا لزم الأمر: عند اختيار تغيير من قائمة التغييرات من فرع التطوير إلى فرع الإصدار، وكانت قائمة التغييرات تحمل العلامة UPSTREAM، ضَع في اعتبارك السيناريوهات التالية:
  • إذا تم تطبيق قائمة التغيير بشكل سليم على فرع الإصدار، لن تحتاج إلى اتّخاذ أي إجراء إضافي.
  • إذا لم يتم تطبيق تغيير الرمز بشكل سليم، عليك حلّ التعارضات وتعديل العلامة إلى BACKPORT وتوثيق الإجراءات التي تم اتخاذها كجزء من عملية حلّ التعارض، راجِع متطلبات النقل من إصدار Linux الرئيسي.

الأولوية وESRT

حدِّد أولوية (إلحاح) لطلب إعادة تدوير المفتاح لمساعدة فريق GKI في تحديد الأولويات. تساعد هذه الأولوية فريق GKI في تقديم المساعدة للشركاء بشكل أفضل وفي الوقت المناسب.

• بالنسبة إلى الطلبات المهمة أو التي تتطلّب ردًا سريعًا، حدِّد الأولوية على أنّها P0.
• بالنسبة إلى طلبات P0 وP1، يجب أيضًا تقديم مبرّر للاستعجال.

يوضّح الجدول التالي العلاقة بين أولوية الخطأ والوقت اللازم لحلّه (ESRT):

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

سياسات اتفاقية مستوى الخدمة

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

إرسال طلب إعادة صياغة

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

الشكل 1:عملية إعادة الفهرسة في حالات الطوارئ

لإرسال طلب إعادة تدوير، يُرجى اتّباع الخطوات التالية:

1. املأ نموذج طلب إعادة البناء والتصديق لمفتاح GKI وتواصَل مع جهة التواصل المخصَّصة لك في Google على الفور.

   • ينشئ هذا النموذج خطأ في طلب إعادة تدوير GKI.

2. تجهيز التصحيحات:

   • تأكَّد من دمج التصحيح في فرع تطوير GKI.
   • طبِّق تصحيح الأمان على فرع إصدار GKI المناسب.
   • عدِّل التصحيح الذي تم اختياره يدويًا لتضمين علامة Bug: XYZ تشير إلى رقم تعريف طلب إعادة التدوير.

   مثال: للاختيار الدقيق لتغيير من android16-6.12 إلى android16-6.12-2025-12:

   # 1. Checkout the target release branch
   git checkout android16-6.12-2025-12
   
   # 2. Fetch the upstream development branch (Source of Truth)
   git fetch aosp android16-6.12
   
   # 3. Cherry-pick the commit (Preserving metadata)
   git cherry-pick -x <commit_hash>
   
   # 4. Update the commit message to include the Respin Bug ID
   # (Do not remove existing Bug IDs or change the Change-Id)
   

3. أرسِل الخطأ. يحدث ما يلي بعد إرسال الطلب:

   • عملية المراجعة بعد إرسال الطلب:

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

   • الإصدار:

     • يتم إصدار الملف الثنائي إلى ci.android.com.
     • تنتهي المدة الزمنية لتقرير أخطاء البرامج الثابتة والأخطاء الأمنية، ويصنّف فريق GKI في Google الطلب على أنّه تم إصلاحه ويشير إلى إصدار إعادة التدوير.
     • يتم أيضًا نشر إصدارات respin على صفحة إصدارات Generic Kernel Image (GKI).