از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
برای پیادهسازی بهروزرسانیهای هوایی (OTA) ، بوتلودر باید بتواند به دیسک RAM بازیابی در هنگام بوت دسترسی داشته باشد. اگر دستگاه از یک تصویر بازیابی AOSP اصلاح نشده استفاده کند، بوت لودر 32 بایت اول پارتیشن misc را می خواند. اگر دادههای موجود با boot-recovery مطابقت داشته باشند، بوت لودر به تصویر recovery میشود. این روش هر کار بازیابی معلق (مثلاً اعمال OTA یا حذف داده ها) را قادر می سازد تا تکمیل شود.
برای پشتیبانی از بهروزرسانیهای OTA در دستگاههایی که از بهروزرسانیهای A/B استفاده میکنند، مطمئن شوید که بوتلودر دستگاه دارای معیارهای زیر است.
معیارهای عمومی
تمام پارتیشنهایی که از طریق OTA بهروزرسانی میشوند باید در زمانی که سیستم اصلی بوت میشود (و در بازیابی بهروزرسانی نمیشوند) قابل بهروزرسانی باشند.
برای بوت کردن پارتیشن system ، بوت لودر مقدار زیر را در خط فرمان هسته ارسال می کند: ro root=/dev/[node] rootwait init=/init .
فراخوانی markBootSuccessful از HAL بر عهده چارچوب Android است. بوت لودر هرگز نباید پارتیشنی را به عنوان بوت شده با موفقیت علامت گذاری کند.
پشتیبانی از کنترل بوت HAL
بوت لودر باید از boot_control HAL همانطور که در hardware/libhardware/include/hardware/boot_control.h تعریف شده است، پشتیبانی کند. بهروزرسانیکننده کنترل راهاندازی HAL را پرس و جو میکند، شکاف راهاندازی را که استفاده نمیشود بهروزرسانی میکند، شکاف فعال را با استفاده از HAL تغییر میدهد و در سیستم عامل بهروزرسانیشده راهاندازی مجدد میشود. برای جزئیات، به پیاده سازی کنترل بوت HAL مراجعه کنید.
پشتیبانی از اسلات
بوت لودر باید از عملکردهای مربوط به پارتیشن ها و اسلات ها پشتیبانی کند، از جمله:
نام پارتیشن ها باید دارای پسوندی باشد که مشخص کند کدام پارتیشن ها به یک اسلات خاص در بوت لودر تعلق دارند. برای هر یک از این پارتیشن ها، یک متغیر متناظر has-slot: partition base name با مقدار yes . اسلات ها بر اساس حروف الفبا به صورت a، b، c و غیره نامگذاری می شوند که مربوط به پارتیشن هایی با پسوند _a ، _b ، _c ، و غیره است. بوت لودر باید با استفاده از ویژگی خط فرمان androidboot.slot_suffix به سیستم عامل اطلاع دهد که کدام اسلات بوت شده است. این ویژگی از طریق bootconfig برای دستگاه هایی که با Android 12 یا بالاتر راه اندازی می شوند تنظیم می شود.
مقدار slot-retry-count به یک مقدار مثبت (معمولاً 3 ) بازنشانی میشود، یا توسط کنترل راهانداز HAL از طریق پاسخ تماس setActiveBootSlot یا از طریق دستور fastboot set_active . هنگام اصلاح پارتیشنی که بخشی از یک اسلات است، بوت لودر «با موفقیت راهاندازی شده» را پاک میکند و تعداد تلاش مجدد را برای اسلات بازنشانی میکند.
بوت لودر باید تعیین کند که کدام اسلات بارگذاری شود. شکل نمونه ای از فرآیند تصمیم گیری را نشان می دهد.
شکل 1. جریان شکاف بوت لودر
تعیین کنید که کدام شکاف را امتحان کنید. سعی نکنید شکافی را که با علامت slot-unbootable مشخص شده است، بارگیری نکنید. این اسلات باید با مقادیر بازگردانده شده توسط fastboot مطابقت داشته باشد و به آن اسلات فعلی می گویند.
اگر شکاف فعلی بهعنوان slot-successful علامتگذاری نشده است و دارای slot-retry-count = 0 است، شکاف فعلی را بهعنوان slot-unbootable علامتگذاری کنید. سپس یک اسلات متفاوت را انتخاب کنید که unbootable نیست و بهعنوان slot-successful علامتگذاری شده است. این اسلات اکنون اسلات انتخاب شده است. اگر هیچ اسلات فعلی در دسترس نیست، برای بازیابی راهاندازی کنید یا یک پیام خطای معنیدار برای کاربر نمایش دهید.
boot.img مناسب را انتخاب کنید و مسیر تصحیح پارتیشن سیستم را در خط فرمان هسته قرار دهید.
پارامتر خط فرمان هسته slot_suffix را پر کنید.
چکمه. اگر slot-successful علامتگذاری نشد، slot-retry-count کاهش دهید.
ابزار fastboot تعیین می کند که هنگام اجرای هر دستور فلش، کدام پارتیشن فلش شود. برای مثال، اجرای دستور fastboot flash system system.img ابتدا متغیر current-slot را پرس و جو می کند و سپس نتیجه را به سیستم الحاق می کند تا نام پارتیشنی را که باید فلش شود ( system_a ، system_b و غیره) تولید کند.
هنگام تنظیم شکاف فعلی با استفاده از دستور fastboot set_active یا فرمان بوت کنترل HAL setActiveBootSlot ، بوت لودر باید شکاف فعلی را بهروزرسانی کند، slot-unbootable و slot-successful را پاک کند، و تعداد تلاش مجدد را بازنشانی کند (این تنها راه برای پاک کردن slot-unbootable است).
دستگاههای بدون بهروزرسانی A/B
برای پشتیبانی از بهروزرسانیهای OTA در دستگاههایی که از بهروزرسانیهای A/B استفاده نمیکنند (به دستگاههای غیرقابل بهروزرسانی A/B مراجعه کنید)، مطمئن شوید که بوتلودر دستگاه دارای معیارهای زیر است.
پارتیشن recovery باید حاوی تصویری باشد که قادر به خواندن تصویر سیستم از برخی پارتیشن های پشتیبانی شده ( cache ، userdata ) و نوشتن آن در پارتیشن system باشد.
بوت لودر باید از بوت شدن مستقیم به حالت بازیابی پشتیبانی کند.
اگر بهروزرسانیهای تصویر رادیویی پشتیبانی میشوند، پارتیشن recovery نیز باید بتواند رادیو را فلش کند. این را می توان به یکی از دو روش انجام داد:
بوت لودر رادیو را فلش می کند. در این حالت، باید امکان راه اندازی مجدد از پارتیشن بازیابی به بوت لودر برای تکمیل به روز رسانی وجود داشته باشد.
تصویر بازیابی رادیو را چشمک می زند. این قابلیت می تواند به عنوان یک کتابخانه باینری یا ابزار ارائه شود.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# Implement OTA updates\n\nTo implement the [over-the-air (OTA) updates](/docs/core/ota), the\nbootloader must be able to access a recovery RAM disk during boot. If the device\nuses an unmodified AOSP recovery image, the bootloader reads the first 32 bytes\non the `misc` partition; if the data there matches `boot-recovery`, the\nbootloader boots into the `recovery` image. This method enables any pending\nrecovery work (for example, applying an OTA or removing data) to continue to\ncompletion.\n\nFor details on the content of a block in flash used for communications by\nrecovery and the bootloader, refer to\n[bootable/recovery/bootloader_message/bootloader_message.h](https://android.googlesource.com/platform/bootable/recovery/+/android16-release/bootloader_message/include/bootloader_message/bootloader_message.h#64).\n\nDevices with A/B updates\n------------------------\n\nTo support OTA updates on devices that use [A/B\nupdates](/docs/core/ota/ab), ensure that the device bootloader meets\nthe following criteria.\n\n### General criteria\n\n- All partitions updated through an OTA should be updatable while the main\n system is booted (and not updated in recovery).\n\n- To boot the `system` partition, the bootloader passes the following value on\n kernel command line: `ro root=/dev/[node] rootwait init=/init`.\n\n- It's the responsibility of the Android framework to call `markBootSuccessful`\n from the HAL. The bootloader should never mark a partition as successfully\n booted.\n\n### Support for boot control HAL\n\nThe bootloader must support the `boot_control` HAL as defined in\n`hardware/libhardware/include/hardware/boot_control.h`. The updater queries the\n[boot control\nHAL](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/boot/1.0/IBootControl.hal),\nupdates the boot slot not in use, changes the active slot using the\nHAL, and reboots into the updated operating system. For details, see\n[Implementing the boot control\nHAL](/docs/core/ota/ab/ab_implement#bootcontrol).\n\n### Support for slots\n\nThe bootloader must support functionality related to partitions and slots,\nincluding:\n\n- Partition names must include a suffix that identifies which partitions\n belong to a particular slot in the bootloader. For each such partition,\n there's a corresponding variable\n `has-slot:`\u003cvar translate=\"no\"\u003epartition base name\u003c/var\u003e with a value of\n `yes`. Slots are named alphabetically as a, b, c, etc. corresponding to\n partitions with the suffix `_a`, `_b`, `_c`, etc. The bootloader should inform\n the operating system which slot was booted using the command line property\n `androidboot.slot_suffix`. This property is set through bootconfig for devices\n launching with Android 12 or higher.\n\n- The `slot-retry-count` value is reset to a positive value (usually `3`),\n either by the boot control HAL through the `setActiveBootSlot` callback or\n through the `fastboot set_active` command. When modifying a partition that's\n part of a slot, the bootloader clears \"successfully booted\" and resets the\n retry count for the slot.\n\nThe bootloader should also determine which slot to load. The figure shows an\nexample decision process.\n**Figure 1.** Bootloader slotting flow\n\n1. Determine which slot to attempt. Don't attempt to load a slot marked\n `slot-unbootable`. This slot should be consistent with the values returned by\n fastboot, and is referred to as the current slot.\n\n2. If the current slot isn't marked as `slot-successful` and has a\n `slot-retry-count = 0`, mark the current slot as `slot-unbootable`. Then\n select a different slot that is not marked `unbootable` and is marked as\n `slot-successful`; this slot is now the selected slot. If no current slot is\n available, boot to recovery or display a meaningful error message to the\n user.\n\n3. Select the appropriate `boot.img` and include the path to correct system\n partition on the kernel command line.\n\n4. Populate the kernel command line `slot_suffix` parameter.\n\n5. Boot. If not marked `slot-successful`, decrement `slot-retry-count`.\n\nThe `fastboot` utility determines which partition to flash when running any\nflash commands. For example, running the `fastboot flash system system.img`\ncommand first queries the `current-slot` variable then concatenates the result\nto system to generate the name of the partition that should be flashed\n(`system_a`, `system_b`, etc.).\n\nWhen setting the current slot using the fastboot `set_active` command or the\nboot control HAL `setActiveBootSlot` command, the bootloader should update\nthe current slot, clear `slot-unbootable` and `slot-successful`, and reset the\nretry count (this is the only way to clear `slot-unbootable`).\n\nDevices without A/B updates\n---------------------------\n\nTo support OTA updates on devices that don't use A/B updates (see [Non-A/B\nupdatable devices](/docs/core/ota/nonab)), ensure that the device\nbootloader meets the following criteria.\n\n- The `recovery` partition should contain an image that is capable of reading a\n system image from some supported partition (`cache`, `userdata`) and writing\n it to the `system` partition.\n\n- The bootloader should support booting directly into recovery mode.\n\n- If radio image updates are supported, the `recovery` partition should also be\n able to flash the radio. This can be accomplished in one of two ways:\n\n - The bootloader flashes the radio. In this case, it should be possible to\n reboot from the recovery partition back into the bootloader to complete the\n update.\n\n - The recovery image flashes the radio. This functionality can be provided as\n a binary library or utility."]]