نسخه GKI

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

خلاصه اصطلاحات

جدول زیر اصطلاحات مهم مورد استفاده در این صفحه و برای به‌روزرسانی‌های GKI را خلاصه می‌کند.

نام	سمبل	مثال	شرح
انتشار هسته	پسوند wxy-zzz-k	5.4.42-android12-0-foo	شناسه منحصر به فرد برای انتشار GKI. این مقداری است که توسط uname برگردانده شده است.
نسخه KMI	wx-zzz-k	5.4-اندروید12-0	رابط ماژول هسته (KMI) بین GKI و ماژول های هسته قابل بارگذاری پویا (DLKM) را توصیف می کند.
سطح فرعی	y	42	ترتیب انتشار نسخه های هسته را در همان نسخه KMI شرح می دهد.

جدول زیر سایر اصطلاحات مرتبط را به عنوان مرجع فهرست می کند.

نام	سمبل	مثال	شرح
wxy	wxy	5.4.42	برای جزئیات، فایل‌های Makefiles هسته لینوکس (جستجوی "KERNELRELEASE") را ببینید. wxy به طور مستقیم در سراسر این سند استفاده می شود. معمولاً به این شماره نسخه سه قسمتی نیز گفته می شود. اصطلاح مورد استفاده در VINTF، نسخه هسته ، ممکن است با اصطلاحات دیگر، به ویژه w ، اشتباه شود. این متغیر در libkver به عنوان kernel_version_tuple نامیده می شود. این تاپل نباید با هیچ به روز رسانی، از جمله OTA یا خط اصلی، کاهش یابد.
شاخه هسته	zzz-wx	اندروید 12-5.4	این اصطلاح در انواع شاخه های هسته مشترک استفاده می شود.
نسخه	w	5	این اصطلاح در این سند استفاده نشده است. این متغیر در libkver به عنوان نسخه نامیده می شود.
سطح پچ	ایکس	4	این اصطلاح در این سند استفاده نشده است. این متغیر در libkver به عنوان patch_level نامیده می شود.
انتشار اندروید	zzz	اندروید 12	این شماره انتشار اندروید (دسر) است که هسته با آن مرتبط است. هنگام مقایسه فیلد AndroidRelease ، قسمت عددی برای مقایسه از رشته استخراج می شود. شماره نسخه اندروید نباید با هیچ به‌روزرسانی، از جمله OTA یا خط اصلی، کاهش یابد.
نسل KMI	ک	0	این یک عدد اضافی است که برای مقابله با رویدادهای بعید اضافه شده است. اگر رفع اشکال امنیتی نیاز به تغییراتی در KMI در همان نسخه اندروید داشته باشد، نسل KMI افزایش می‌یابد. شماره نسل KMI با 0 شروع می شود.

طراحی نسخه

انتشار هسته

تعریف

برای دستگاه هایی که با GKI عرضه می شوند، انتشار هسته به صورت زیر تعریف می شود:

KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w      .x         .y       -zzz           -k            -something

برای اطلاعات بیشتر، به تعیین انتشار هسته از دستگاه مراجعه کنید.

در زیر نمونه ای از انتشار هسته است.

5.4.42-android12-0-00544-ged21d463f856

شرح

انتشار هسته شناسه منحصر به فرد نسخه GKI است. اگر دو باینری GKI دارای هسته یکسانی باشند، باید از نظر بایت یکسان باشند.

یک نسخه هسته شامل یک نسخه KMI، یک سطح فرعی و یک پسوند است. برای اهداف این سند، پسوند پس از تولید KMI نادیده گرفته شده است.

نسخه KMI

تعریف

نسخه KMI به صورت زیر تعریف شده است:

KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w      .x         -zzz           -k

توجه داشته باشید که سطح فرعی، y بخشی از نسخه KMI نیست. برای مثال در نسخه کرنل ، نسخه KMI به صورت زیر است:

5.4-android12-0

شرح

نسخه KMI رابط ماژول هسته (KMI) بین GKI و ماژول های هسته قابل بارگذاری پویا (DLKM) را توصیف می کند.

اگر دو نسخه کرنل نسخه KMI یکسانی داشته باشند، رابط ماژول هسته یکسانی را پیاده سازی می کنند. DLKMهایی که با یکی سازگار هستند با دیگری نیز سازگار هستند.

نسخه KMI نباید با هیچ به روز رسانی OTA کاهش یابد.

سطح فرعی

سطح فرعی، y ، ترتیب انتشار نسخه های هسته را در همان نسخه KMI توصیف می کند.

برای دو نسخه هسته که نسخه KMI یکسانی دارند اما به ترتیب دارای سطح فرعی Y1 و Y2 هستند:

• اگر Y1 کمتر یا مساوی Y2 باشد، دستگاهی که Y1 را اجرا می کند می تواند به روز رسانی Y2 را دریافت کند.
• اگر Y1 بزرگتر از Y2 باشد، دستگاهی که Y1 را اجرا می کند نمی تواند به Y2 به روز شود.

یعنی اگر نسخه KMI تغییر نکند، سطح فرعی نباید با هیچ آپدیت OTA کاهش یابد.

تعیین انتشار هسته از یک دستگاه

انتشار کامل هسته را می توان با اجرای uname -r یا uname(2) با قطعه کد زیر پیدا کرد:

std::string get_kernel_release() {
  struct utsname buf;
  return uname(&buf) == 0 ? buf.release : "";
}

یک نمونه خروجی این است:

5.4.42-android12-0-00544-ged21d463f856

برای هدف این سند، هر چیزی پس از تولید KMI هنگام استخراج اطلاعات هسته نادیده گرفته می شود. به طور رسمی تر، خروجی uname -r با regex زیر تجزیه می شود (با فرض اینکه zzz همیشه با "اندروید" شروع می شود):

^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$

اطلاعات نادیده گرفته می‌تواند شامل اطلاعاتی مانند شماره ساخت ci.android.com ، تعداد وصله‌های بالای هسته پایه و هش‌های SHA مربوط به git commit باشد.

libkver

کتابخانه، libkver، یک رابط C++ برای تجزیه نسخه هسته یا یک رشته نسخه KMI فراهم می کند. برای فهرستی از APIهایی که libkver در معرض نمایش قرار می‌دهد، به packages/modules/Gki/libkver/include/kver مراجعه کنید.

چک های VINTF

برای اندروید 11 یا پایین‌تر، بخش انتشار اندروید از نسخه KMI به صورت دستی در مانیفست دستگاه توسط سازندگان دستگاه مشخص می‌شود. برای جزئیات، قوانین مطابقت هسته VINTF را ببینید.

از اندروید S، بخش انتشار اندروید از نسخه KMI را می توان از هسته استخراج کرد و در زمان ساخت به مانیفست دستگاه تزریق کرد.

از آنجا که الزامات پیکربندی هسته معمولاً تغییر نمی کند، نیازی به رمزگذاری k در ماتریس سازگاری وجود ندارد. با این حال، در موارد بعید که نیاز به تنظیمات هسته نیاز به تغییر دارد، از موارد زیر اطمینان حاصل کنید:

• نیاز مربوطه از ماتریس سازگاری حذف می شود.
• تست‌های VTS اضافی برای بررسی الزامات جدید مشروط به تولید KMI اضافه می‌شوند.

نسخه تصویر را در فراداده OTA بوت کنید

حتی اگر تصویر بوت از طریق به‌روزرسانی OTA به‌روزرسانی شود، باید در قالب OTA payload، payload.bin قرار گیرد. بار OTA یک فیلد version برای هر پارتیشن رمزگذاری می کند. هنگامی که update_engine یک بار OTA را مدیریت می کند، این فیلد را با هم مقایسه می کند تا اطمینان حاصل شود که پارتیشن پایین نیامده است.

برای جلوگیری از سردرگمی، فیلد version برای پارتیشن بوت در فراداده OTA boot image version نامیده می‌شود.

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

قبل از به روز رسانی OTA، مشتری OTA نسخه بوت تصویر را به همان روشی که هر پارتیشن دیگری بررسی می کند.