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

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

آهنگ انتشار GKI

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

اندروید 13 و 14 نسخه GKI

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

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شده؟
اکتبر	14 اکتبر 2022	31 اکتبر 2022	آره
نوامبر	14 نوامبر 2022	30 نوامبر 2022	آره
دسامبر	9 دسامبر 2022	21 دسامبر 2022	آره
ژانویه	17 ژانویه 2023	31 ژانویه 2023	آره
فوریه	15 فوریه 2023	28 فوریه 2023	آره
مارس	15 مارس 2023	31 مارس 2023	آره
آوریل	13 آوریل 2023	28 آوریل 2023	آره
ممکن است	17 مه 2023	31 مه 2023	آره
ژوئن	15 ژوئن 2023	30 ژوئن 2023	آره
جولای	18 جولای 2023	31 جولای 2023	آره
مرداد	16 آگوست 2023	31 آگوست 2023	آره
سپتامبر	14 سپتامبر 2023	29 سپتامبر 2023	آره
اکتبر	18 اکتبر 2023	31 اکتبر 2023	آره
نوامبر	10 نوامبر 2023	30 نوامبر 2023	آره
دسامبر	7 دسامبر 2023	22 دسامبر 2023	آره
ژانویه	16 ژانویه 2024	31 ژانویه 2024	آره
فوریه	13 فوریه 2024	29 فوریه 2024	آره
مارس	13 مارس 2024	29 مارس 2024	آره
آوریل	16 آوریل 2024	30 آوریل 2024	آره
ممکن است	14 مه 2024	31 مه 2024	آره
ژوئن	12 ژوئن 2024	28 ژوئن 2024	آره
جولای	16 جولای 2024	31 جولای 2024	آره
مرداد	15 آگوست 2024	30 آگوست 2024	آره
سپتامبر	17 سپتامبر 2024	30 سپتامبر 2024	آره
اکتبر	15 اکتبر 2024	31 اکتبر 2024	آره
نوامبر	11 نوامبر 2024	27 نوامبر 2024	آره
دسامبر	6 دسامبر 2024	23 دسامبر 2024	آره

توجه: تاریخ ها قابل تغییر هستند. پس از راه‌اندازی اولیه android14-5.15 در ژوئن 2023 ، دیگر برنامه‌ای برای انتشار ماهانه دنبال نمی‌کنیم. در عوض، باینری های تایید شده به روز شده را بر اساس نیاز یا بنا به درخواست شریک منتشر می کنیم. شرکا می توانند با ثبت یک اشکال این را درخواست کنند.

از ژانویه 2024، نسخه های ماهانه android14-5.15 را مطابق با آهنگ ماهانه مشخص شده در جدول زیر از سر خواهیم گرفت.

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شده؟
ژانویه	16 ژانویه 2024	31 ژانویه 2024	آره
فوریه	13 فوریه 2024	29 فوریه 2024	آره
مارس	4 مارس 2024	15 مارس 2024	آره
آوریل	1 آوریل 2024	17 آوریل 2024	آره
ممکن است	1 مه 2024	17 مه 2024	آره
ژوئن	3 ژوئن 2024	17 ژوئن 2024	آره
جولای	1 ژوئیه 2024	15 جولای 2024	آره
مرداد	1 آگوست 2024	16 آگوست 2024	آره
سپتامبر	2 سپتامبر 2024	16 سپتامبر 2024	آره
اکتبر	1 اکتبر 2024	14 اکتبر 2024	آره
نوامبر	1 نوامبر 2024	15 نوامبر 2024	آره
دسامبر	2 دسامبر 2024	16 دسامبر 2024	آره

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

پس از می 2023، نسخه‌های android12-5.10 GKI در یک آهنگ ۲ ماهه هستند و در اواسط ماه منتشر می‌شوند. جدول زیر فقط برای android12-5.10 قابل استفاده است.

ساخت های ماهانه گواهی GKI	تاریخ قطع ورود	تاریخ آماده پیش بارگیری GKI	تایید شده؟
جولای	3 جولای 2023	14 جولای 2023	آره
سپتامبر	1 سپتامبر 2023	15 سپتامبر 2023	آره
نوامبر	3 نوامبر 2023	17 نوامبر 2023	آره
ژانویه	5 ژانویه 2024	19 ژانویه 2024	آره
مارس	4 مارس 2024	15 مارس 2024	آره
ممکن است	1 مه 2024	17 مه 2024	آره

توجه: تاریخ ها قابل تغییر هستند.

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

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

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

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

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

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

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

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

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

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

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

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

وصله های امنیتی تا 6 ماه پس از انتشار شعبه به طور خودکار در یک شاخه انتشار ادغام می شوند. پس از قطع 6 ماهه، باید برای اعمال وصله های امنیتی به یک شعبه، یک 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 روز کاری

توجه: ESRT به عنوان زمان لازم برای ارائه یک باینری GKI تایید شده که حاوی اصلاحیه تایید شده (توسط تیم GKI) و بازبینی (توسط شما) است، تعریف می شود.

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

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

• برای هر CL مورد بررسی، تگ های زیر را اضافه کنید. پیشرفت در درخواست respin بدون این اطلاعات مسدود شده است.

  • 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 از قبل منتشر شده وجود دارد؟

بله، این به عنوان 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 بر ما تأثیر می‌گذارند، زیرا به‌طور خاص با محصولات ما آزمایش نشده‌اند. آیا این امکان وجود دارد که فقط پچ ما را شامل شود؟

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

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

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

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