از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
نمای کلی بوت لودر
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
بوت لودر یک تصویر اختصاصی فروشنده است که مسئول بالا آوردن هسته روی یک دستگاه است. بوت لودر از وضعیت دستگاه محافظت می کند و مسئول تنظیم اولیه محیط اجرای مورد اعتماد (TEE) و اتصال ریشه اعتماد آن است. بوت لودر همچنین یکپارچگی پارتیشن های boot و recovery را قبل از انتقال اجرا به هسته تأیید می کند.
نمونه جریان بوت لودر
در اینجا یک نمونه جریان بوت لودر آورده شده است:
بارگیری و مقداردهی اولیه حافظه
دستگاه را مطابق با جریان بوت تأیید شده تأیید کنید.
پارتیشن‌های بوت، از جمله boot ، dtbo ، init_boot ، و recovery را مطابق با جریان بوت تأیید شده تأیید کنید. به عنوان بخشی از این مرحله، نسخه هدر تصویر بوت را بررسی کنید و هدر را بر اساس آن تجزیه کنید.
اگر از به‌روزرسانی‌های A/B استفاده می‌شود، اسلات فعلی برای بوت شدن را تعیین کنید.
تعیین کنید که آیا حالت بازیابی باید بوت شود یا خیر. برای اطلاعات بیشتر، به پشتیبانی از به‌روزرسانی‌های OTA مراجعه کنید.
تصاویر راه‌اندازی، مانند boot.img ، vendor_boot.img ، init_boot.img ، و سایر تصاویر بوت اختصاصی فروشنده را بارگیری کنید. این تصاویر بوت حاوی تصاویر هسته و ramdisk هستند.
کرنل را به عنوان یک باینری فشرده قابل اجرا در حافظه بارگذاری کنید. هسته خود را از حالت فشرده خارج می کند و شروع به اجرا در حافظه می کند.
ramdisks و بخش bootconfig را در حافظه بارگذاری کنید تا initramfs ایجاد کنید.
ویژگی های اضافی مرتبط با بوت لودر
در زیر لیستی از ویژگی های اضافی مرتبط با بوت لودر که می توانید پیاده سازی کنید آمده است:
پوشش درختی دستگاه (DTO). یک پوشش درختی دستگاه به بوت لودر اجازه می دهد تا از تنظیمات سخت افزاری مختلف پشتیبانی کند. یک DTO در یک حباب درختی دستگاه (DTB) که توسط بوت لودر استفاده می شود، کامپایل می شود.
تصادفی سازی آدرس مجازی تصویر هسته. بوت لودر از تصادفی کردن آدرس مجازی که تصویر هسته در آن بارگذاری می شود پشتیبانی می کند. برای تصادفی کردن آدرس، RANDOMIZE_BASE در پیکربندی هسته روی true تنظیم کنید. بوت لودر باید با ارسال یک مقدار تصادفی u64 در گره درختی دستگاه /chosen/kaslr-seed آنتروپی را فراهم کند.
بوت تایید شده Verified Boot به بوت لودر این امکان را می دهد که مطمئن شود تمام کدهای اجرا شده از یک منبع قابل اعتماد آمده است.
تنظیمات بوت پیکربندی بوت در اندروید 12 و بالاتر موجود است و مکانیزمی برای انتقال جزئیات پیکربندی از بیلد و بوت لودر به سیستم عامل است. قبل از اندروید 12، از پارامترهای خط فرمان هسته با پیشوند androidboot استفاده می شد.
به روز رسانی های خارج از هوا (OTA). دستگاه‌های Android در این زمینه می‌توانند به‌روزرسانی‌های OTA سیستم، نرم‌افزار برنامه و قوانین منطقه زمانی را دریافت و نصب کنند. این ویژگی پیامدهایی بر پیاده سازی بوت لودر شما دارد. برای اطلاعات کلی در مورد OTA، به‌روزرسانی‌های OTA را ببینید. برای جزئیات پیاده‌سازی OTA مخصوص بوت‌لودر، به پشتیبانی از به‌روزرسانی‌های OTA مراجعه کنید.
صحافی نسخه . Version binding کلیدهای امنیتی را به سیستم عامل و نسخه سطح وصله متصل می کند. Version binding تضمین می کند که مهاجمی که ضعفی را در نسخه قدیمی سیستم یا نرم افزار TEE کشف می کند، نمی تواند دستگاه را به نسخه آسیب پذیر برگرداند و از کلیدهای ایجاد شده با نسخه جدیدتر استفاده کند. بوت لودر باید اطلاعات خاصی را برای پشتیبانی از binding نسخه ارائه دهد. برای اطلاعات بیشتر، به اطلاعات نسخه در ویژگی های AVB مراجعه کنید.
خط فرمان هسته
خط فرمان هسته را از مکان های زیر به هم متصل کنید:
خط فرمان بوت لودر: مجموعه ای از پارامترهای استاتیک و پویا که توسط بوت لودر تعیین می شود
درخت دستگاه: از گره chosen/bootargs
defconfig : از CONFIG_CMDLINE
boot.img : از خط فرمان (برای افست و اندازه، به system/core/mkbootimg/bootimg.h مراجعه کنید
از اندروید 12، برای پارامترهای androidboot.* که باید به فضای کاربران اندروید منتقل کنیم، می‌توانیم به جای خط فرمان هسته از bootconfig استفاده کنیم.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Bootloader overview\n\nA *bootloader* is a vendor-proprietary image responsible for bringing up the\nkernel on a device. The bootloader guards the device state and is responsible\nfor initializing the [Trusted Execution Environment (TEE)](/docs/security/features/trusty)\nand binding its root of trust. The bootloader also verifies the integrity of the\n`boot` and `recovery` partitions before moving execution to the kernel.\n\nExample bootloader flow\n-----------------------\n\nHere's an example bootloader flow:\n\n1. Load and initialize memory.\n\n2. Verify the device according to [Verified Boot flow](/docs/security/features/verifiedboot).\n\n3. Verify the boot partitions, including `boot`, `dtbo`, `init_boot`, and\n `recovery`, according to the Verified Boot flow. As part of this step, check the\n [boot image header](/docs/core/architecture/bootloader/boot-image-header)\n version and parse the header accordingly.\n\n4. If [A/B updates](/docs/core/ota/ab) are used, determine the current slot to\n boot.\n\n5. Determine if recovery mode should be booted. For more\n information, see\n [Supporting OTA Updates](/docs/core/architecture/bootloader/updating).\n\n6. Load the boot images, such as `boot.img`, `vendor_boot.img`,\n `init_boot.img`, and other proprietary vendor boot images. These boot images\n contain the kernel and ramdisk images.\n\n 1. Load the kernel into memory as a self-executable compressed\n binary. The kernel decompresses itself and starts executing into memory.\n\n 2. Load ramdisks and the bootconfig section into memory\n to create `initramfs`.\n\nAdditional bootloader-related features\n--------------------------------------\n\nFollowing is a list of additional bootloader-related features that you can\nimplement:\n\n- *Device tree overlay (DTO).*\n A [device tree overlay](/docs/core/architecture/dto) lets the bootloader to\n support different hardware configurations. A DTO is compiled into a *device\n tree blob (DTB)* which is used by the bootloader.\n\n- *Kernel image virtual address randomization.* The bootloader supports\n randomizing the virtual address at which the kernel image is loaded. To\n randomize the address, set `RANDOMIZE_BASE` to `true` in the kernel config.\n The bootloader must provide entropy by passing a random u64 value in the\n `/chosen/kaslr-seed` device tree node.\n\n- *Verified Boot.* [Verified Boot](/docs/security/features/verifiedboot) lets\n the bootloader to ensure all executed code comes from a trusted source.\n\n- *Boot config.*\n [Boot config](/docs/core/architecture/bootloader/implementing-bootconfig)\n is available in Android 12 and higher and is a mechanism for passing\n configuration details from the build and bootloader to the operating system.\n Prior to Android 12, kernel command-line parameters with the prefix of\n `androidboot` are used.\n\n- *Over-the-air (OTA) updates.* Android devices in the field can receive and\n install OTA updates to the system, app software, and\n time zone rules. This feature has implications on your bootloader\n implementation. For general information on OTA, see\n [OTA updates](/docs/core/ota). For bootloader-specific OTA implementation\n details, see\n [Supporting OTA updates](/docs/core/architecture/bootloader/updating).\n\n- *Version binding* .\n [Version binding](/docs/security/features/keystore/version-binding) binds\n security keys to the operating system and patch level version. Version binding\n ensures that an attacker who discovers a weakness in an old version of the\n system or the TEE software can't roll a device back to the vulnerable version\n and use keys created with the newer version. The bootloader must provide certain\n information to support version binding. For further information, see\n [Version information in AVB properties](/docs/core/architecture/bootloader/version-info-avb).\n\nKernel command line\n-------------------\n\nConcatenate the kernel command line from the following locations:\n\n- Bootloader command line: set of static and dynamic parameters determined by\n the bootloader\n\n- Device tree: from the `chosen/bootargs` node\n\n- `defconfig`: from `CONFIG_CMDLINE`\n\n- `boot.img`: from the command line (for offsets and sized, refer to\n [`system/core/mkbootimg/bootimg.h`](https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/android16-release/include/bootimg/bootimg.h)\n\nAs of Android 12, for `androidboot.*` parameters that\nwe need to pass to Android userspace, we can use\n[bootconfig](/docs/core/architecture/bootloader/implementing-bootconfig) instead\nof the kernel command line."]]
