طرح نسخه سازی GKI

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

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

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

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

طراحی نسخه‌بندی

انتشار هسته

تعریف

برای دستگاه‌هایی که با 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 نیست. برای مثال در نسخه Kernel ، نسخه 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 با عبارت منظم زیر تجزیه می‌شود (با فرض اینکه zzz همیشه با "android" شروع می‌شود):

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

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

لیبکور

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

چک‌های VINTF

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

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

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

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

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

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

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

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

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