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

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

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

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

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

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

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

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

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

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

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

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

تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند مصنوعات مربوط به همه نسخه‌ها را از 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) و سناریوهای مشکل ارائه دهد تا تولیدکنندگان اصلی تجهیزات بتوانند تأثیر و ریسک اجرای وصله‌ها را با محصولات خود ارزیابی کنند؟

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