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

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

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

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

• التوقيت: لا يمكن طلب إعادة تجميع إلا في فروع الإصدارات بعد إطلاق إصدار علني أولي لإصدار ربع سنوي. لا يمكن طلب إعادة تجميع لـ vendor-hooks أو ميزات أخرى إلا لفرع إصدار معيّن لمدة أقصاها ستة أشهر بعد الإصدار العلني الأولي.
• الأمان والدعم الطويل الأمد (LTS): بعد ستة أشهر، تكون الفروع مؤهّلة لإعادة التجميع فقط من أجل تصحيحات الأمان المذكورة في "نشرة أمان Android" أو إصلاحات الأخطاء الخطيرة.
• الإيقاف: يتم إيقاف الفرع عندما تؤدي متطلبات الدعم الطويل الأمد (LTS) المحدّدة في "نشرة أمان Android" إلى عدم امتثال الفرع. لا يتم قبول طلبات إعادة التجميع للفروع التي تم إيقافها.
  • يتم تضمين تاريخ الإيقاف لفرع إصدار GKI معيّن في ملاحظات بنية إصدارات GKI الربع سنوية ضمن "الإصدارات". على سبيل المثال، يتم دعم إعادة تجميع إصدار سبتمبر 2025 حتى مارس 2027. يعكس هذا التاريخ فترة الدعم الطويل الأمد (LTS) لإصدار نواة 2.0 التي تبلغ 18 شهرًا للإصدارات التي تبدأ في سبتمبر 2025 (كانت الإصدارات قبل سبتمبر 2025 تتوفر لمدة 12 شهرًا).
• النطاق: لا يمكن طلب إعادة تجميع إلا لإصلاحات الأخطاء العاجلة أو تعديلات قائمة الرموز أو لتطبيق تصحيح لإصلاح ميزة حالية.
• إصدارات GKI بحجم 16 كيلوبايت: تتّبع عمليات إعادة التجميع عند الطلب لفروع GKI المتوافقة بحجم 16 كيلوبايت (android15-6.6 و android16-6.12 وandroid17-6.18) نموذج طلب إعادة التجميع نفسه ومعايير إرسال التصحيحات وعملية التأهيل نفسها التي تتّبعها الإصدارات بحجم 4 كيلوبايت. ليس عليك تعديل نواتَي 4 كيلوبايت و16 كيلوبايت معًا، على الرغم من أنّنا ننصحك بذلك.

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

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

المرجع الموثوق وعمليات اختيار التغييرات

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

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

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

• بالنسبة إلى الطلبات الخطيرة أو الحساسة للوقت، يجب وضع علامة الأداة 0 على الأولوية.
• بالنسبة إلى الطلبات ذات الأولوية القصوى والأداة 1، يجب أيضًا تبرير الإلحاح.

يوضّح الجدول التالي ربط أولوية الخطأ ووقت الحلّ (ESRT):

الأولوية	وقت الحلّ المتوقّع (ESRT)
الأداة 0	يومان عمل
الأداة 1	‫5 أيام عمل
الأداة 2	10 أيام عمل
الأداة 3	15 يوم عمل

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

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

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

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

   • الإصدار:

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