بعد از انتخاب Slot و Verify کردن chain، Bootloader باید Kernel و محیط اولیه userspace را در RAM قرار دهد. اینجا boot.img، init_boot، vendor_boot، dtbo و vbmeta را باید از هم جدا کنیم.

ساختار با نسخه Android تغییر کرده

دستورالعمل‌های قدیمی را نباید روی دستگاه جدید تعمیم داد. AOSP می‌گوید در دستگاه‌هایی که با Android 13+ Launch می‌شوند generic ramdisk از boot جدا و داخل init_boot قرار می‌گیرد؛ دستگاه‌هایی که Upgrade شده‌اند ممکن است layout نسل قبلی را حفظ کنند.

boot

در معماری GKI جدید، boot عمدتاً Generic Kernel Image را حمل می‌کند. در دستگاه‌های Android 12-style generic ramdisk نیز ممکن است داخل boot باشد.

init_boot

برای launch با Android 13+، generic ramdisk و first-stage init در init_boot قرار می‌گیرند.

Android 12 launch:
boot = kernel + generic ramdisk

Android 13+ launch:
boot = GKI kernel
init_boot = generic ramdisk

vendor_boot

vendor_boot داده‌های Boot وابسته به Vendor را حمل می‌کند، از جمله vendor ramdiskها و Device Tree-related data طبق header version. در نسخه‌های جدید می‌تواند چند vendor ramdisk fragment داشته باشد تا Bootloader بر اساس mode آنها را انتخاب کند.

DTB / DTBO

Device Tree ساختار Hardware را برای Kernel توصیف می‌کند. DTBO تفاوت variantهای Board را به شکل Overlay اعمال می‌کند. این جداسازی برای GKI مهم است چون Kernel core genericتر می‌شود.

vbmeta

vbmeta executable نیست؛ metadata امنیتی AVB را نگه می‌دارد و قبل از اجرای OS توسط Bootloader استفاده می‌شود.

recovery

بعضی دستگاه‌ها recovery partition مستقل دارند و بعضی layoutها Recovery ramdisk را در boot/vendor_boot organization ادغام می‌کنند. پس وجود فایل recovery.img یا partition recovery قانون ثابت همه نسل‌ها نیست.

Dynamic Partitions و super

از Android 10، partitionهایی مثل system/vendor/product می‌توانند Logical Partition داخل super باشند. first-stage init بعداً mapping این partitionها را می‌سازد.

Physical storage
 ├─ boot_a / boot_b
 ├─ init_boot_a / init_boot_b
 ├─ vendor_boot_a / vendor_boot_b
 ├─ vbmeta_a / vbmeta_b
 └─ super
      ├─ system (logical)
      ├─ vendor (logical)
      └─ product (logical)

GKI

Generic Kernel Image هسته مشترک‌تر Android است. Driverهای Vendor تا حد امکان به Moduleها و interfaceهای پایدار منتقل می‌شوند تا Kernel core کمتر device-specific باشد.

ramdisk

Ramdisk یک filesystem کوچک در RAM است که ابزارهای early userspace را قبل از mount شدن filesystemهای اصلی فراهم می‌کند. /init از همین محیط شروع می‌شود.

Bootloader در آخر چه می‌کند؟

verify images
   ↓
load kernel → RAM
assemble generic + vendor ramdisks
load DTB/DTBO
prepare bootconfig/cmdline
   ↓
jump to kernel entry

Magisk چرا گاهی boot و گاهی init_boot را Patch می‌کند؟

چون محل generic ramdisk با launch architecture فرق دارد. روی نسل قدیمی ممکن است داخل boot باشد؛ روی بعضی دستگاه‌های Android 13+ داخل init_boot است. این یک مثال عملی از اهمیت فهم layout واقعی دستگاه است.

منابع رسمی برای مطالعه بیشتر

قبلی: AVBبعدی: Kernel تا initبازگشت به مقالاتصفحه اصلی