درخواست چرخش مجدد

چرخش مجدد فرایند ادغام مجدد، بازسازی، آزمایش مجدد، و صدور گواهی مجدد برای یک باینری پس‌از انتشار عمومی هسته GKI است.

پیش‌از درخواست بازطراحی، به دستورالعمل‌های زیر توجه کنید.

واجدشرایط بودن و چرخه حیات

• زمان‌بندی: فقط پس‌از راه‌اندازی نسخه عمومی اولیه از ساخت سه‌ماهه می‌توانید برای شاخه‌های انتشار درخواست بازچرخش کنید. درخواست‌های درخواست‌های چرخش مجدد برای قلاب‌های فروشنده یا ویژگی‌های دیگر فقط برای شاخه انتشار معین تا حداکثر شش ماه پس‌از انتشار عمومی اولیه.
• امنیت و LTS: پس‌از شش ماه، شاخه‌ها فقط برای وصله‌های امنیتی ذکرشده در «بولتن امنیتی Android» (ASB) یا رفع اشکالات حیاتی واجدشرایط چرخش مجدد هستند.
• منسوخ شدن: وقتی الزامات «پشتیبانی بلندمدت» (LTS) که در «خبرنامه امنیتی Android»‏ (ASB) تعریف شده است باعث شود شاخه با استانداردها مطابقت نداشته باشد، شاخه منسوخ می‌شود. درخواست‌های Respin برای شاخه‌های منسوخ‌شده پذیرفته نمی‌شود.
  • تاریخ منسوخ شدن شاخه انتشار GKI در یادداشت‌های ساخت انتشار GKI سه‌ماهه در بخش «انتشارها» درج شده است. برای مثال، نسخه سپتامبر ۲۰۲۵ تا مارس ۲۰۲۷ برای بازتوزیع پشتیبانی می‌شود. این تاریخ نشان‌دهنده طول عمر ۱۸ ماهه نسخه هسته LTS 2.0 برای نسخه‌های منتشرشده از سپتامبر ۲۰۲۵ است (نسخه‌های منتشرشده قبل‌از سپتامبر ۲۰۲۵ طول عمر ۱۲ ماهه داشتند).
• محدوده: فقط برای رفع اشکال‌های فوری، به‌روزرسانی‌های فهرست نمادها، یا اعمال وصله برای رفع مشکل ویژگی موجود، درخواست بازچرخش کنید.

استانداردهای ارسال وصله

برای برآورده کردن «زمان استاندارد موردانتظار برای حل مشکل» (ESRT) در پردازش درخواست بازچرخش، همه وصله‌های ارسال‌شده به شاخه انتشار باید از قوانین فنی زیر پیروی کنند.

منبع حقیقت و گلچین کردن

• ابتدا شاخه توسعه: همه وصله‌هایی که به شاخه نسخه پخش فصلی می‌روند باید قبلاً در شاخه توسعه اصلی GKI ادغام شده باشند. برای مثال، اگر برای چرخش مجدد android15-6.6-2025-08 وصله‌ای لازم باشد، باید ازقبل در android15-6.6 ادغام شده باشد.
• انتخاب پاک: باید وصله‌ها را مستقیماً از شاخه توسعه انتخاب کنید. از شاخه‌های انتشار دیگر گلچین نکنید (برای مثال، از 2025-08 به 2025-09 گلچین نکنید)، زیرا این کار می‌تواند منجر به اطلاعات نویسنده یا ثبت شود که با نسخه در شاخه توسعه ناسازگار است. وصله‌های دارای اطلاعات ناسازگار پذیرفته نخواهند شد.
• حفظ فراداده: فراداده commit اصلی (برای مثال، نویسنده، مُهر زمان اصلی) را حفظ کنید. برای حفظ فراداده، از 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 را درصورت لزوم به‌روز کنید: هنگام انتخاب گیلاس CL از شاخه توسعه به شاخه انتشار، و اگر CL به‌عنوان UPSTREAM برچسب‌گذاری شده است، سناریوهای زیر را درنظر بگیرید:
  • اگر CL به‌طور کامل روی شاخه انتشار اعمال شود، نیازی به انجام هیچ اقدام اضافی نیست.
  • اگر CL به‌طور کامل اعمال نشد، تعارض‌ها را برطرف کنید، برچسب را به BACKPORT به‌روز کنید، و آنچه را به‌عنوان بخشی از حل تعارض انجام شده است مستند کنید، به الزامات انتقال از Linux اصلی مراجعه کنید.

اولویت و ESRT

برای کمک به تیم GKI در اولویت‌بندی، به درخواست چرخش مجدد اولویت (فوریت) اختصاص دهید. این اولویت به تیم GKI کمک می‌کند تا بهتر و به‌موقع به شرکا کمک کند.

• برای درخواست‌های حیاتی یا حساس به زمان، اولویت را روی P0 تنظیم کنید.
• برای درخواست‌های P0 و P1، باید فوریت را نیز توجیه کنید.

جدول زیر اولویت اشکال و زمان رفع اشکال را (ESRT) نشان می‌دهد:

اولویت	ESRT
اولویت بالا	‫۲ روز کاری
P1	‫۵ روز کاری
P2	۱۰ روز کاری
P3	‫۱۵ روز کاری

خط‌مشی‌های SLA

• برای هر شاخه انتشار، درخواست بازچرخش جداگانه‌ای ارسال کنید.
• اگر تغییراتی در درخواست چرخش مجدد دارید که به‌عنوان اصلاح‌شده علامت‌گذاری شده است، درخواست چرخش مجدد جدیدی ارسال کنید. برای افزودن فهرست‌های تغییر (CL) بیشتر، درخواست را دوباره باز نکنید.
• اگر درخواست چرخش مجدد نیاز به پاسخ شما داشته باشد و ظرف سه روز کاری پاسخ ندهید، اولویت یک سطح تنزل می‌یابد، برای مثال، P0 به P1 تنزل می‌یابد.
• اگر تا دو هفته پاسخ ندهید، اشکال به‌عنوان رفع نمی‌شود (منسوخ) علامت‌گذاری می‌شود.

ارسال درخواست چرخش مجدد

نمودار زیر فرایند چرخش مجدد را نشان می‌دهد. فرایند زمانی شروع می‌شود که شریک OEM (شما) درخواست بازتولید را ارسال می‌کند.

شکل ۱. فرایند چرخش مجدد اضطراری.

برای ارسال درخواست چرخش مجدد:

1. فرم درخواست چرخش مجدد GKI را تکمیل کنید و بلافاصله با نقطه تماس Google خود تماس بگیرید.

   • این فرم اشکال درخواست چرخش مجدد GKI ایجاد می‌کند.

2. وصله‌هایتان را آماده کنید:

   • درستی‌سنجی کنید وصله در شاخه توسعه GKI ادغام شده باشد.
   • وصله را در شاخه انتشار GKI مناسب اعمال کنید.
   • وصله انتخاب‌شده را اصلاح کنید تا برچسب Bug: XYZ با ذکر شناسه درخواست چرخش مجدد را دربرگیرد.

   مثال: برای انتخاب یک CL از 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 درخواست را به‌عنوان رفع‌شده علامت‌گذاری می‌کند و به ساختار respin ارجاع می‌دهد.
     • ساختمان چرخش مجدد نیز در صفحه نسخه‌های پخش «تصویر هسته عمومی» (GKI) منتشر می‌شود.