از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
OTAهای مبتنی بر بلوک
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
میتوانید بهروزرسانیهای مبتنی بر بلوک (OTA) را برای دستگاههای جدید دارای Android نسخه 5.0 فعال کنید. OTA مکانیزمی است که توسط آن OEM ها از راه دور پارتیشن سیستم یک دستگاه را به روز می کنند:
- Android نسخه 5.0 و نسخههای جدیدتر از بهروزرسانیهای OTA بلوک استفاده میکنند تا اطمینان حاصل شود که هر دستگاه دقیقاً از یک پارتیشن استفاده میکند. به جای مقایسه فایلهای مجزا و محاسبه وصلههای باینری، بلوک OTA کل پارتیشن را به عنوان یک فایل مدیریت میکند و یک پچ باینری را محاسبه میکند، و مطمئن میشود که پارتیشن حاصل دقیقاً حاوی بیتهای مورد نظر است. این اجازه می دهد تا تصویر سیستم دستگاه از طریق فست بوت یا OTA به همان حالت برسد.
- Android 4.4 و نسخههای قبلی از بهروزرسانیهای OTA فایل استفاده میکردند، که تضمین میکرد دستگاهها حاوی محتویات فایل، مجوزها و حالتهای مشابه هستند، اما اجازه میداد ابردادههایی مانند مُهرهای زمانی و چیدمان فضای ذخیرهسازی زیربنایی بین دستگاهها بر اساس روش بهروزرسانی متفاوت باشد.
از آنجا که بلوک OTA تضمین می کند که هر دستگاه از یک پارتیشن استفاده می کند، استفاده از dm-verity را برای امضای رمزنگاری پارتیشن سیستم امکان پذیر می کند. برای جزئیات بیشتر در مورد dm-verity، به بوت تایید شده مراجعه کنید.
توجه: قبل از استفاده از dm-verity باید یک سیستم OTA بلاک کار داشته باشید.
توصیه ها
برای دستگاههایی که با Android 5.0 یا بالاتر راهاندازی میشوند، از بروزرسانیهای OTA بلوک در رام کارخانه استفاده کنید. برای ایجاد OTA مبتنی بر بلوک برای بهروزرسانیهای بعدی، گزینه --block
را به ota_from_target_files
منتقل کنید.
برای دستگاههایی که با Android نسخه 4.4 یا قبل از آن راهاندازی شدهاند، از بهروزرسانیهای OTA فایل استفاده کنید. در حالی که میتوان دستگاهها را با ارسال یک بلوک کامل OTA اندروید 5.0 یا جدیدتر انتقال داد، اما نیاز به ارسال یک OTA کامل دارد که به طور قابلتوجهی بزرگتر از OTA افزایشی است (و بنابراین توصیه نمیشود).
از آنجایی که dm-verity به پشتیبانی بوتلودر نیاز دارد که فقط در دستگاههای جدیدی که با Android نسخه ۵.۰ یا بالاتر ارسال میشوند، یافت میشود، نمیتوانید dm-verity را برای دستگاههای موجود فعال کنید.
توسعه دهندگانی که روی سیستم Android OTA کار می کنند (تصویر بازیابی و اسکریپت هایی که OTA تولید می کنند) می توانند با عضویت در لیست پستی android-ota@googlegroups.com با تغییرات همراه شوند.
فایل در مقابل OTAهای بلوک
در طی یک OTA مبتنی بر فایل، اندروید سعی می کند محتویات پارتیشن سیستم را در لایه سیستم فایل (بر اساس فایل به فایل) تغییر دهد. بهروزرسانی تضمینی برای نوشتن فایلها به ترتیب ثابت، داشتن آخرین زمان اصلاح شده یا بلوک فوقالعاده ثابت، یا حتی قرار دادن بلوکها در همان مکان در دستگاه بلوک نیست. به همین دلیل، OTAهای مبتنی بر فایل در دستگاههای دارای dm-verity با شکست مواجه میشوند. پس از تلاش OTA، دستگاه بوت نمی شود.
در طول OTA مبتنی بر بلوک، Android تفاوت بین دو تصویر بلوک (به جای دو مجموعه فایل) را به دستگاه ارائه می دهد. بهروزرسانی، ساخت دستگاه را در برابر سرور ساخت مربوطه در سطح بلوک (زیر سیستم فایل) با استفاده از یکی از روشهای زیر بررسی میکند:
- به روز رسانی کامل . کپی کردن تصویر کامل سیستم ساده است و تولید پچ را آسان می کند، اما همچنین تصاویر بزرگی تولید می کند که می تواند اعمال وصله ها را گران کند.
- به روز رسانی افزایشی . استفاده از ابزار تفاوت باینری تصاویر کوچکتری تولید میکند و کاربرد وصله را آسان میکند، اما هنگام تولید خود پچ، حافظه فشردهای دارد.
توجه: adb fastboot
دقیقا همان بیت های OTA کامل را روی دستگاه قرار می دهد، بنابراین فلش با بلوک OTA سازگار است.
به روز رسانی سیستم های اصلاح نشده
برای دستگاههایی با پارتیشنهای سیستمی اصلاحنشده دارای Android نسخه 5.0، فرآیند دانلود و نصب برای یک بلوک OTA مانند یک فایل OTA باقی میماند. با این حال، بهروزرسانی OTA ممکن است شامل یک یا چند مورد از تفاوتهای زیر باشد:
- اندازه دانلود .
بهروزرسانیهای OTA بلوک کامل تقریباً به اندازه بهروزرسانیهای OTA فایل کامل هستند و بهروزرسانیهای تدریجی میتوانند فقط چند مگابایت بزرگتر باشند.

شکل 1. اندازههای Nexus 6 OTA را بین نسخههای Android 5.0 و Android 5.1 مقایسه کنید (تغییرات ساخت هدف متفاوت)
به طور کلی، بهروزرسانیهای OTA بلوک افزایشی بزرگتر از بهروزرسانی OTA فایل افزایشی هستند به دلیل:
- حفظ داده ها . OTAهای مبتنی بر بلوک نسبت به OTA مبتنی بر فایل، دادههای بیشتری را حفظ میکنند (فراداده فایل، دادههای dm-verity، طرحبندی ext4 و غیره).
- تفاوت های الگوریتم محاسباتی در آپدیت OTA فایل، اگر مسیر فایل در هر دو بیلد یکسان باشد، بسته OTA حاوی داده ای برای آن فایل نیست. در بروزرسانی بلوک OTA، تعیین تغییر اندک یا بدون تغییر در یک فایل به کیفیت الگوریتم محاسباتی وصله و چیدمان دادههای فایل در سیستم منبع و هدف بستگی دارد.
- حساسیت به فلاش و رم معیوب اگر فایلی خراب باشد، یک فایل OTA تا زمانی که فایل خراب را لمس نکند موفق می شود، اما بلوک OTA اگر هر گونه خرابی را در پارتیشن سیستم تشخیص دهد با شکست مواجه می شود.
به روز رسانی سیستم های اصلاح شده
برای دستگاههایی با پارتیشنهای سیستم اصلاحشده دارای Android نسخه ۵.۰:
- به روز رسانی OTA بلوک افزایشی با شکست مواجه می شود . یک پارتیشن سیستم ممکن است در حین
adb remount
یا در نتیجه بدافزار اصلاح شود. File OTA برخی تغییرات را در پارتیشن تحمل می کند، مانند افزودن فایل هایی که بخشی از ساخت منبع یا هدف نیستند. با این حال، بلوک OTA اضافه شدن به پارتیشن را تحمل نمی کند، بنابراین کاربران باید یک OTA کامل را نصب کنند که تغییرات پارتیشن سیستم را بازنویسی کند) یا یک تصویر سیستم جدید را فلش کنند تا OTA های آینده را فعال کنند. - تلاش برای تغییر فایل های اصلاح شده باعث شکست به روز رسانی می شود . هم برای بهروزرسانی OTA فایل و هم برای بلوک، اگر OTA تلاش کند فایلی را تغییر دهد که اصلاح شده است، بهروزرسانی OTA با شکست مواجه میشود.
- تلاش برای دسترسی به فایل های اصلاح شده خطا ایجاد می کند (فقط dm-verity) . برای به روز رسانی OTA فایل و بلوک، اگر dm-verity فعال باشد و OTA تلاش کند به بخش های اصلاح شده سیستم فایل سیستم دسترسی پیدا کند، OTA خطایی ایجاد می کند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# Block-based OTAs\n\nYou can enable block-based over-the-air (OTA) updates for new devices running Android 5.0. OTA\nis the mechanism by which OEMs remotely update the system partition of a device:\n\n- **Android 5.0** and later versions use block OTA updates to ensure that each device uses the exact same partition. Instead of comparing individual files and computing binary patches, block OTA handles the entire partition as one file and computes a single binary patch, ensuring the resultant partition contains exactly the intended bits. This allows the device system image to achieve the same state via fastboot or OTA.\n- **Android 4.4** and earlier versions used file OTA updates, which ensured devices contained similar file contents, permissions, and modes, but allowed metadata such as timestamps and the layout of the underlying storage to vary between devices based on the update method.\n\n\nBecause block OTA ensures that each device uses the same partition, it enables the use of\ndm-verity to cryptographically sign the system partition. For details on dm-verity, see\n[Verified Boot](/docs/security/features/verifiedboot).\n\n\n**Note:** You must have a working block OTA system before using dm-verity.\n\nRecommendations\n---------------\n\n\nFor devices launching with Android 5.0 or later, use block OTA updates in the factory ROM. To\ngenerate a block-based OTA for subsequent updates, pass the `--block` option to\n`ota_from_target_files`.\n\n\nFor devices that launched with Android 4.4 or earlier, use file OTA updates. While it is\npossible to transition devices by sending a full block OTA of Android 5.0 or later, it\nrequires sending out a full OTA that is significantly larger than an incremental OTA (and is\ntherefore discouraged).\n\n\nBecause dm-verity requires bootloader support found only in new devices shipping with Android\n5.0 or later, you *cannot* enable dm-verity for existing devices.\n\n\nDevelopers working on the Android OTA system (the recovery image and the scripts that generate\nOTAs) can keep up with changes by subscribing to the\n[android-ota@googlegroups.com](https://groups.google.com/forum/#!forum/android-ota)\nmailing list.\n\nFile versus block OTAs\n----------------------\n\n\nDuring a file-based OTA, Android attempts to change the contents of the system partition at\nthe filesystem layer (on a file-by-file basis). The update is not guaranteed to write files in\na consistent order, have a consistent last modified time or superblock, or even place the\nblocks in the same location on the block device. For this reason, file-based OTAs fail on a\ndm-verity-enabled device; after the OTA attempt, the device does not boot.\n\n\nDuring a block-based OTA, Android serves the device the difference between the two block\nimages (rather than two sets of files). The update checks a device build against the\ncorresponding build server at the block level (below the filesystem) using one of the\nfollowing methods:\n\n- **Full update**. Copying the full system image is simple and makes patch generation easy but also generates large images that can make applying patches expensive.\n- **Incremental update**. Using a binary differ tool generates smaller images and makes patch application easy, but is memory-intensive when generating the patch itself.\n\n\n**Note:** `adb fastboot` places the exact same bits on the device as a\nfull OTA, so flashing is compatible with block OTA.\n\n### Update unmodified systems\n\n\nFor devices with *unmodified* system partitions running Android 5.0, the download and\ninstall process for a block OTA remains the same as for a file OTA. However, the OTA update\nitself might include one or more of the following differences:\n\n- **Download size** .\n\n\n Full block OTA updates are approximately the same size as full file OTA updates, and\n incremental updates can be just a few megabytes larger.\n\n\n **Figure 1.** Compare Nexus 6 OTA sizes between Android 5.0 and Android 5.1\n releases (varying target build changes)\n\n\n In general, incremental block OTA updates are larger than incremental file OTA updates due\n to:\n - *Data preservation*. Block-based OTAs preserve more data (file metadata, dm-verity data, ext4 layout, etc.) than file-based OTA.\n - *Computation algorithm differences*. In a file OTA update, if a file path is identical in both builds, the OTA package contains no data for that file. In a block OTA update, determining little or no change in a file depends on the quality of the patch computation algorithm and layout of file data in both source and target system.\n- **Sensitivity to faulty flash and RAM**. If a file is corrupted, a file OTA succeeds as long as it doesn't touch the corrupted file, but a block OTA fails if it detects any corruption on the system partition.\n\n### Update modified systems\n\nFor devices with *modified* system partitions running Android 5.0:\n\n- **Incremental block OTA updates fail** . A system partition might be modified during an `adb remount` or as a result of malware. File OTA tolerates some changes to the partition, such as the addition of files that are not part of the source or target build. However, block OTA does not tolerate additions to the partition, so users will need to install a full OTA overwriting any system partition modifications) or flash a new system image to enable future OTAs.\n- **Attempts to change modified files cause update failure**. For both file and block OTA updates, if the OTA attempts to change a file that has been modified, the OTA update fails.\n- **Attempts to access modified files generate errors** *(dm-verity only)*. For both file and block OTA updates, if dm-verity is enabled and the OTA attempts to access modified parts of the system filesystem, the OTA generates an error."]]