فرآیند انتشار تصویر هسته عمومی (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 آره

از ژانویه 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

پس از می 2024، نسخه‌های 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 آره
اوت 1 آگوست 2024 16 آگوست 2024 آره
نوامبر 1 نوامبر 2024 15 نوامبر 2024 آره
فوریه 3 فوریه 2025 17 فوریه 2025 آره

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

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

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

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

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

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

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

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

جدول زمانی آهنگ انتشار 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 روز کاری
  • شما باید یک درخواست 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 همیشه می‌توانند توضیح و راه‌حل مشکل را در تغییرات ثبت پیدا کنند.