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

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

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

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

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

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

برای برآورده کردن «زمان استاندارد موردانتظار برای حل مشکل» (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 تغییر شاخه توسعه یکسان باشد.
  • 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. اشکال را ارسال کنید. پس‌از ارسال درخواست، موارد زیر اتفاق می‌افتد:

    • فرایند بازبینی پس‌از ارسال:

      • تیم GKI Google درخواست را بررسی می‌کند و آن را تأیید می‌کند یا اگر اطلاعات بیشتری نیاز باشد، آن را به شما برمی‌گرداند.
      • پس‌از توافق بر سر اصلاح، تیم Google GKI تغییر را بازبینی کد می‌کند. زمان‌سنج ESRT درطول این بررسی فعال است. بااین‌حال، اگر وصله رد شود یا نیاز به بازنگری داشته باشد، زمان‌سنج ESRT بازنشانی می‌شود.
      • تیم GKI تغییر را ادغام، ساخت، و برای رگرسیون آزمایش می‌کند و آن را تأیید می‌کند.

    • انتشار: