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

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

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

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

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

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

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

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

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

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

مدارک تحصیلی 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) همیشه می‌توانند شرح مشکل و راه‌حل آن را در گزارش تغییرات پیدا کنند.