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

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

آهنگ آزادسازی GKI

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

ماه انتشار		a12-5.10	a13-5.10	a13-5.15	a14-5.15	a14-6.1	a15-6.6	a16-6.12
ژوئن ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI	۱۶ ژوئن 30 ژوئن				۲ ژوئن ۱۶ ژوئن	۲ ژوئن ۱۶ ژوئن	۲ ژوئن ۱۸ ژوئن
جولای ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI		۱۶ ژوئیه ۳۱ ژوئیه	۱۶ ژوئیه ۳۱ ژوئیه	۱۶ ژوئیه ۳۱ ژوئیه	۱ ژوئیه ۱۵ ژوئیه	۱ ژوئیه ۱۵ ژوئیه	۱ ژوئیه ۱۵ ژوئیه
مرداد ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI					۱ آگوست ۱۵ آگوست	۱ آگوست ۱۵ آگوست	۱ آگوست ۱۵ آگوست
سپتامبر ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI	۱۶ سپتامبر* ۳۰ سپتامبر*		۱۶ سپتامبر ۳۰ سپتامبر		۱ سپتامبر ۱۵ سپتامبر	۱ سپتامبر ۱۵ سپتامبر	۱ سپتامبر ۱۵ سپتامبر
اکتبر ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI		۱۶ اکتبر ۳۱ اکتبر		۱ اکتبر ۱۵ اکتبر		۱ اکتبر ۱۵ اکتبر
نوامبر ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI
دسامبر ۲۰۲۵	ورود قطع شد آماده پیش بارگذاری GKI	۱ دسامبر ۱۵ دسامبر		۱ دسامبر* ۱۵ دسامبر*		۱ دسامبر ۱۵ دسامبر		۱ دسامبر ۱۵ دسامبر

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

اعتبارسنجی GKI برای OEMها

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

نسخه‌های تایید شده سه ماهه

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

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

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

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

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

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

وصله‌های امنیتی تا ۶ ماه پس از انتشار یک شاخه، به‌طور خودکار در آن ادغام می‌شوند. پس از پایان ۶ ماه، برای اعمال وصله‌های امنیتی روی یک شاخه، باید درخواست تجدید نظر (respin) بدهید.

دستورالعمل‌های درخواست ریسپین

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

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

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

• وقتی الزامات LTS که توسط بولتن امنیتی اندروید (ASB) تعریف شده است باعث عدم انطباق شاخه شود، شاخه منسوخ می‌شود. درخواست‌های Respin برای شاخه‌های منسوخ شده پذیرفته نمی‌شوند. تاریخ منسوخ شدن برای یک شاخه انتشار GKI مشخص در یادداشت‌های ساخت انتشار GKI فصلی در بخش Releases گنجانده شده است. برای برنامه‌ریزی‌های آینده، الزامات LTS سالانه در ماه مه و نوامبر به‌روزرسانی می‌شوند. به عنوان مثال، شاخه android12-5.10-2023-07 (5.10.177) برای respins پس از 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 ادغام شده باشد.

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

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

  اولویت	ESRT
  پ0	۲ روز کاری
  پی۱	۵ روز کاری
  پی۲	۱۰ روز کاری
  پ3	۱۵ روز کاری

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

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

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

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

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

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

ارسال درخواست ریسپین

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

شکل ۲. فرآیند ریسیدن مجدد

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

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

مدارک تحصیلی GKI

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

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

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

می‌توانید اطلاعات بیشتر در مورد CI، از جمله نتایج آزمایش را در داشبورد Android Continuous Integration بیابید.

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

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

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

بله، این به عنوان respin شناخته می‌شود. فرآیند respin تا زمانی پشتیبانی می‌شود که نسخه GKI منتشر شده (که respin روی آن درخواست شده است) با الزامات LTS در بولتن امنیتی اندروید (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ها فقط شامل وصله‌هایی هستند که روی هسته‌های تأیید شده فصلی انتخاب شده قرار دارند. این respinها شامل تمام رفع اشکالات مسدودکننده راه‌اندازی هستند که تا هر زمان معینی توسط OEMها با استفاده از نسخه پایه فصلی مربوطه گزارش شده‌اند. به مثال زیر که نشان می‌دهد این نوع سناریو چگونه اتفاق می‌افتد، توجه کنید.

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

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

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

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

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

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