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

این صفحه طرح نسخه‌بندی «تصاویر هسته عمومی» (GKI) را شرح می‌دهد. ‫A تصویر هسته عمومی (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 نیست. برای مثال در انتشار هسته، نسخه 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 از git commit باشد.

libkver

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

بررسی‌های VINTF

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

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

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

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

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

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

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

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

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