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

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

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

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

• التوقيت: يمكنك طلب إعادة تدوير المحتوى فقط على فروع الإصدارات بعد إطلاق إصدار عام أولي من إصدار ربع سنوي. يمكنك طلب إعادة إنشاء رموز لخطافات المورّد أو ميزات أخرى لفرع إصدار معيّن لمدة 6 أشهر كحد أقصى بعد الإصدار العلني الأولي.
• الأمان وقناة الدعم الطويل الأمد (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.
• في حال عدم الردّ خلال أسبوعَين، يتم وضع العلامة لن يتم حلّها (قديمة) على الخطأ.

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

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

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

   • الإصدار:

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