فرآیند انتشار تصویر هسته عمومی (GKI).

این صفحه نحوه انتشار GKI را شرح می‌دهد، از جمله نسخه‌های اضطراری هفتگی، ماهانه و خارج از باند. هدف این سند ارائه دستورالعملی به OEM ها در مورد مکان دریافت GKI و همچنین فرآیند رفع مشکل اضطراری خارج از باند است. OEM ها همچنین می توانند از توسعه GKI برای کسب اطلاعات بیشتر در مورد نحوه کار با تیم Android Kernel برای بهینه سازی هسته GKI برای محصولات خود استفاده کنند.

آهنگ انتشار GKI

GKI در یک رکود ماهانه پس از توقف KMI منتشر می شود.

اندروید 13، 14 و 15 GKI منتشر شد

جدول زیر فقط برای android13-5.10 ، android13-5.15 و android14-5.15 قابل استفاده است.

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شد؟
نوامبر	11 نوامبر 2024	27 نوامبر 2024	بله
ژانویه	14 ژانویه 2025	31 ژانویه 2025	بله
مارس	14 مارس 2025	31 مارس 2025	بله

جدول زیر فقط برای android14-6.1 و android15-6.6 قابل استفاده است.

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شد؟
اکتبر	1 اکتبر 2024	14 اکتبر 2024	بله
نوامبر	1 نوامبر 2024	15 نوامبر 2024	بله
دسامبر	2 دسامبر 2024	16 دسامبر 2024	بله
ژانویه	6 ژانویه 2025	22 ژانویه 2025	بله

انتشار اندروید 12 GKI

پس از می 2024، نسخه‌های android12-5.10 GKI به صورت سه ماهه منتشر می‌شوند و در اواسط ماه منتشر می‌شوند. جدول زیر فقط برای android12-5.10 قابل استفاده است.

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شد؟
نوامبر	1 نوامبر 2024	15 نوامبر 2024	بله
فوریه	3 فوریه 2025	17 فوریه 2025	بله

اعتبار ساخت GKI برای OEM ها

OEM ها می توانند از اندروید GKI که اخیراً منتشر شده است استفاده کنند. OEM ها تا زمانی که با الزامات LTS در بولتن امنیتی Android (ASB) مطابقت داشته باشند، می توانند با ساخت های دارای گواهی GKI راه اندازی شوند.

انتشار هفتگی توسعه

رهاها با Cuttlefish آزمایش می شوند تا اطمینان حاصل شود که از حداقل کیفیت عبور می کنند.

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

انتشارات تایید شده ماهانه

نسخه‌های ماهانه GKI حاوی یک boot.img آزمایش‌شده است که شامل یک گواهی درج‌شده توسط Google است تا تأیید کند که باینری‌ها از یک منبع کد منبع شناخته‌شده ساخته شده‌اند.

هر ماه، یک نامزد انتشار ماهانه GKI (تایید نشده) پس از تاریخ قطع ورود، که معمولاً دومین ساخت هفتگی آن ماه است، انتخاب می‌شود. پس از انتخاب نامزد انتشار ماهانه، تغییرات جدید در نسخه آن ماه پذیرفته نخواهد شد. در طول دوره پنجره بسته، فقط رفع اشکالاتی که باعث شکست تست می شوند قابل رفع هستند. نامزد انتشار تحت تضمین کیفیت قرار می گیرد - همانطور که در بخش صلاحیت GKI توضیح داده شده است - تا اطمینان حاصل شود که تست های انطباق بر روی ساخت GSI+GKI با یک دستگاه مرجع و همچنین کاتل ماهی انجام می شود.

شکل 1. جدول زمانی انتشار GKI

فرآیند ریسپین اضطراری

یک respin به فرآیند ادغام مجدد، ساخت مجدد، آزمایش مجدد و تأیید مجدد یک باینری پس از انتشار عمومی هسته GKI اشاره دارد. برای هر یک از شرایط زیر می‌توانید یک نسخه باینری تأیید شده را درخواست کنید:

• برای به روز رسانی لیست نمادها.
• برای اعمال یک اصلاح برای یک اشکال، از جمله اشکالاتی که در طول تأیید آزمایشگاه شرکت مخابراتی پیدا شده است.
• برای افزودن قلاب فروشنده
• برای اعمال یک وصله به یک ویژگی موجود.
• برای اعمال وصله امنیتی (پس از 6 ماه).

وصله های امنیتی تا 6 ماه پس از انتشار شعبه به طور خودکار در یک شاخه انتشار ادغام می شوند. پس از قطع 6 ماهه، باید برای اعمال وصله های امنیتی به یک شعبه، یک respin درخواست کنید.

دستورالعمل های درخواست Respin

قبل از درخواست respin، به دستورالعمل های زیر توجه کنید:

• Respin ها فقط در شاخه های انتشار پس از راه اندازی نسخه عمومی اولیه ساخت ماهانه مجاز هستند.

• درخواست Respin فقط برای یک شعبه انتشار معین حداکثر تا شش ماه پس از انتشار عمومی اولیه پذیرفته می شود. پس از شش ماه، شعب فقط برای وصله‌های امنیتی ذکر شده در بولتن امنیتی Android واجد شرایط بازسپین هستند.

• وقتی الزامات LTS تعریف شده توسط بولتن امنیتی Android (ASB) باعث عدم انطباق شعبه شود، شعبه منسوخ می شود. درخواست Respin برای شاخه های منسوخ پذیرفته نمی شود. تاریخ منسوخ شدن برای یک شاخه انتشار GKI مشخص در یادداشت‌های ساخت ماهانه انتشار GKI در قسمت Releases گنجانده شده است. برای برنامه ریزی آینده، الزامات LTS در ماه مه و نوامبر سالانه به روز می شود. به عنوان مثال، شاخه android12-5.10-2023-07 (5.10.177) برای چرخش پس از 1 مه 2024 پشتیبانی نمی شود، زیرا شاخه android12-5.10-2023-07 (5.10.177) با این قوانین مطابقت ندارد. الزامات LTS ASB-2024-05.

• Respin ها فقط برای رفع اشکال فوری، به روز رسانی لیست نمادها، یا برای اعمال یک وصله برای رفع یک ویژگی موجود قابل اجرا هستند.

• همه وصله‌هایی که به شاخه انتشار ماهانه می‌روند باید از قبل در شاخه اصلی توسعه GKI ادغام شوند. به عنوان مثال، اگر برای یک respin android12-5.10-2022-09 به یک پچ نیاز است، باید قبلاً در android12-5.10 ادغام شده باشد.

• شما باید وصله های cherry-pick را از شاخه اصلی توسعه GKI و آپلود وصله در شعبه انتشار ماهانه آپلود کنید.

• در درخواست respin باید اولویت (فوریت) را به درخواست اختصاص دهید. این اولویت به تیم GKI کمک می کند تا به موقع به شرکای بهتر کمک کند. برای درخواست های حساس یا حساس به زمان، اولویت را به عنوان P0 علامت گذاری کنید. برای درخواست های P0 و P1، باید فوریت را نیز توجیه کنید. جدول زیر نگاشت اولویت باگ و زمان حل آن (ESRT) را ارائه می دهد:

  اولویت	ESRT
  P0	2 روز کاری
  P1	5 روز کاری
  P2	10 روز کاری
  P3	15 روز کاری

• شما باید یک درخواست respin جداگانه در هر شاخه انتشار ارسال کنید. برای مثال، اگر برای android12-5.10-2022-08 و android12-5.10-2022-09 به یک respin نیاز است، باید دو درخواست respin ایجاد کنید.

• پس از ارائه یک ساخت و علامت گذاری درخواست respin به عنوان ثابت، شما نباید درخواست respin را برای افزودن CL های اضافی دوباره باز کنید. اگر وصله های اضافی وجود دارد که باید ادغام شوند، باید یک درخواست respin جدید ارسال کنید.

• برای هر CL مورد بررسی، تگ های زیر را اضافه کنید.

  • Bug : شناسه اشکال باید به پیام commit برای هر CL اضافه شود.
  • Change-Id : باید با Change-Id تغییر شاخه پایه یکسان باشد.

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

درخواست Respin ارسال کنید

نمودار زیر فرآیند ریسپین را نشان می دهد. این فرآیند زمانی شروع می شود که شریک OEM (شما) درخواست respin را ارسال کند.

شکل 2. فرآیند ریسپین

برای ورود به فرآیند ریسپین:

1. فرم درخواست GKI Respin را پر کنید . و فوراً با مدیر حساب فنی Google خود تماس بگیرید. این فرم یک اشکال درخواست پاسخ GKI ایجاد می کند. اشکالات درخواست Respin برای شما (درخواست کننده)، تیم GKI و افراد خاصی که به لیست CC اشکال اضافه می کنید قابل مشاهده است.
   • اگر قبلاً راه حلی دارید، درخواست باید به وصله ارسالی در AOSP اشاره کند تا Google بتواند آن را بررسی کند. اگر ارسال پچ امکان پذیر نیست، وصله باید به عنوان یک فایل متنی به درخواست پیوست شود.
   • اگر راه حلی ندارید، درخواست باید تا حد امکان حاوی اطلاعات بیشتری از جمله شماره نسخه هسته و گزارش‌ها باشد، بنابراین Google می‌تواند به رفع اشکال کمک کند.
2. تیم Google GKI درخواست را بررسی می‌کند و آن را تأیید می‌کند یا در صورت نیاز به اطلاعات بیشتر، آن را به شما باز می‌گرداند.
3. پس از توافق بر سر راه‌حل، کد تیم Google GKI (CR+2) تغییر را بررسی می‌کند. بررسی بازه زمانی ESRT را آغاز می کند. تیم GKI ادغام می‌شود، می‌سازد، رگرسیون را آزمایش می‌کند و تغییرات را تأیید می‌کند.
4. باینری به ci.android.com منتشر شد. بازه زمانی ESRT به پایان می رسد و تیم Google GKI درخواست را به عنوان ثابت علامت گذاری می کند و به ساخت respin ارجاع می دهد. ساخت respin همچنین در صفحه ساخت نسخه Generic Kernel Image (GKI) پست شده است.

مدارک GKI

انواع ساخت های GKI	اجرای کیفیت	یادداشت ها
هفتگی	آزمایش ده ماهی چکمه زیر مجموعه VTS زیر مجموعه CTS	گواهی نشده است. فقط برای تست و دستگاه بالا بیاورد نمی توان برای راه اندازی دستگاه ها استفاده کرد.
ماهانه (گواهی شده)	آزمایش ده ماهی چکمه VTS سی تی اس مرجع تست سخت افزاری چکمه VTS سی تی اس
Respins (تأیید شده)	آزمایش ده ماهی چکمه VTS زیر مجموعه CTS تست دستگاه مرجع چکمه VTS	ساخته شده بر روی یک ساخت دارای گواهی GKI. ساخت پس از صلاحیت تایید می شود.

از کجا می توان مصنوعات ساخت را به دست آورد

مصنوعات همه نسخه‌ها را می‌توانید از ci.android.com دریافت کنید.

می‌توانید اطلاعات بیشتری در مورد CI، از جمله نتایج آزمایش در داشبورد یکپارچه‌سازی مداوم Android بیابید.

سوالات متداول

در اینجا برخی از سوالات متداول مربوط به فرآیند انتشار GKI وجود دارد.

آیا امکان ساخت یک باینری جدید GKI بر اساس یک GKI از قبل منتشر شده وجود دارد؟

بله، این به عنوان respin شناخته می شود. فرآیند respin تا زمانی پشتیبانی می‌شود که ساخت GKI منتشر شده (که در آن Respin درخواست شده است) با الزامات LTS در بولتن امنیتی Android (ASB) مطابقت داشته باشد.

آیا امکان بازتولید باینری های GKI وجود دارد؟

بله، این یک مثال است:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

برای بازتولید مثال، manifest_$id.xml دانلود کرده و دستور زیر را اجرا کنید:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

می توانید کپی مصنوع GKI خود را از out/.../dist بازیابی کنید.

آیا باینری GKI (از جمله پچ چرخش اضطراری) بر اساس آخرین پایگاه کد ساخته شده است؟

نه. Respin ها فقط حاوی وصله هایی هستند که در بالای هسته های تأیید شده ماهانه انتخاب شده قرار دارند. این ریسپین‌ها شامل تمام رفع اشکال‌های مسدودکننده راه‌اندازی هستند که تا هر زمان مشخص توسط OEMها با استفاده از نسخه پایه ماهانه مربوطه گزارش شده‌اند. مثال زیر را ببینید که چگونه این نوع سناریو اتفاق می افتد.

• OEM1 و OEM2 تصمیم گرفتند از نسخه باینری GKI از نوامبر 2021 استفاده کنند.
• OEM1 و OEM2 مشکلاتی را پیدا می کنند که برای پشتیبانی نیاز به وصله دارند. این وصله ها ممکن است متفاوت باشند یا ممکن است یکسان باشند.
• ریسپین‌های بالای باینری نوامبر 2021 دارای رفع‌های مسدودکننده راه‌اندازی هستند که توسط OEM1 و OEM2 در طول پنجره respin گزارش شده‌اند، اما نه بیشتر.
• مسائل ذکر شده در گلوله دوم نیز در نسخه های ماهانه بعدی GKI گنجانده شده است.

ریسپین اکتبر همه وصله‌های OEM ارسال شده را دارد، اما سایر وصله‌های OEM بر ما تأثیر می‌گذارند، زیرا به‌طور خاص با محصولات ما آزمایش نشده‌اند. آیا این امکان وجود دارد که فقط پچ ما را شامل شود؟

این امکان پذیر نیست مسیر ریسپین "در هر OEM" مقیاس پذیر نیست. در عوض، تیم GKI تک تک تغییراتی را که در بیلدهای respin انجام می‌شود، بررسی می‌کند و قبل از ایجاد یک بیلد جدید، تغییرات را با تمام سخت‌افزارهای موجود آزمایش می‌کند. اگر تیم GKI متوجه شود که مشکل مربوط به یک OEM، دستگاه یا مدل است، تیم GKI می‌تواند اطمینان حاصل کند که کد اضافه‌شده توسط این تغییر فقط در دستگاه، مدل یا SKU تحت تأثیر اجرا می‌شود.

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

آیا موقعیت‌هایی وجود دارد که Google اطلاعات خاصی درباره وصله‌های OEM و سناریوهای صدور ارائه می‌کند تا OEMها بتوانند تأثیر و خطر اجرای وصله‌ها را با محصولات خود ارزیابی کنند؟

تا زمانی که مشکل درک نشده و تمام جزئیات جمع آوری نشده باشد، Google هرگز تغییری به یک ساخت respin اضافه نمی کند. این در Changelog (پیام commit) دیده می شود. Google نشان نمی‌دهد که روی چه دستگاه خاصی تأثیر می‌گذارد، اما OEMs همیشه می‌توانند توضیح و راه‌حل مشکل را در تغییرات ثبت پیدا کنند.