自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
以區塊為單位的 OTA
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
您可以為搭載 Android 5.0 的新裝置啟用區塊式無線更新 (OTA)。OTA 是原始設備製造商 (OEM) 用於遠端更新裝置系統分區的機制:
-
Android 5.0 以上版本會使用區塊 OTA 更新,確保每部裝置都使用相同的分區。區塊 OTA 會將整個分割區視為一個檔案,並計算單一二進位修補程式,確保產生的分割區確實包含所需位元,而非比較個別檔案和計算二進位修補程式。這樣一來,裝置系統映像檔就能透過 fastboot 或 OTA 達到相同狀態。
-
Android 4.4 以下版本使用檔案 OTA 更新,可確保裝置包含類似的檔案內容、權限和模式,但允許中繼資料 (例如時間戳記和基礎儲存空間的版面配置) 根據更新方法在裝置之間有所不同。
由於區塊 OTA 可確保每部裝置都使用相同的分區,因此可使用 dm-verity 對系統分區進行加密簽署。如要進一步瞭解 dm-verity,請參閱「驗證開機程序」。
注意:您必須先擁有可用的區塊 OTA 系統,才能使用 dm-verity。
建議
如果裝置搭載 Android 5.0 以上版本,請在原廠 ROM 中封鎖 OTA 更新。如要為後續更新產生以區塊為基礎的 OTA,請將 --block
選項傳遞至 ota_from_target_files
。
如果裝置搭載 Android 4.4 以下版本,請使用檔案 OTA 更新。雖然您可以透過傳送 Android 5.0 以上版本的完整區塊 OTA 來轉換裝置,但這需要傳送的完整 OTA 大小會比增量 OTA 大得多 (因此不建議使用)。
由於 dm-verity 需要啟動載入器支援,而這項支援僅適用於搭載 Android 5.0 以上版本的新裝置,因此無法為現有裝置啟用 dm-verity。
開發人員可訂閱 android-ota@googlegroups.com 的電子報,以便掌握 Android OTA 系統 (復原映像檔和產生 OTA 的指令碼) 的變更。
檔案與區塊 OTA
在檔案型 OTA 期間,Android 會嘗試在檔案系統層級 (逐一處理檔案) 變更系統分區的內容。更新作業不保證會以一致的順序寫入檔案、擁有一致的最後修改時間或超級區塊,甚至不會將區塊放在區塊裝置上的相同位置。因此,檔案型 OTA 在支援 dm-verity 的裝置上會失敗;在 OTA 嘗試後,裝置不會啟動。
在以區塊為基礎的 OTA 期間,Android 會為裝置提供兩個區塊映像檔 (而非兩組檔案) 之間的差異。更新會使用下列其中一種方法,在區塊層級 (位於檔案系統下方) 檢查裝置版本與對應的建構伺服器是否相符:
-
完整更新。複製完整系統映像檔很簡單,而且可以輕鬆產生修補程式,但也會產生大型映像檔,導致套用修補程式時的成本高昂。
-
增量更新。使用二進位差異工具可產生較小的映像檔,並簡化修補程式的套用程序,但產生修補程式本身時會大量使用記憶體。
注意: adb fastboot
會將與完整 OTA 相同的位元放置在裝置上,因此閃燈作業與區塊 OTA 相容。
更新未經修改的系統
對於搭載 Android 5.0 且系統分區未經修改的裝置,區塊 OTA 的下載和安裝程序與檔案 OTA 相同。不過,OTA 更新本身可能包含下列一或多項差異:
-
下載大小。
完整區塊 OTA 更新的大小與完整檔案 OTA 更新大致相同,而增量更新的大小可能只比前者大上幾 MB。
圖 1. 比較 Nexus 6 OTA 在 Android 5.0 和 Android 5.1 版本之間的大小 (不同目標版本變更)
一般來說,遞增區塊 OTA 更新的大小會大於遞增檔案 OTA 更新,原因如下:
-
資料保存。以區塊為基礎的 OTA 比以檔案為基礎的 OTA 保留更多資料 (檔案中繼資料、dm-verity 資料、ext4 版面配置等)。
-
運算演算法差異。在檔案 OTA 更新中,如果兩個版本的檔案路徑相同,OTA 套件就不會包含該檔案的資料。在區塊 OTA 更新中,要判斷檔案是否有少量或完全沒有變更,取決於來源和目標系統中修補程式運算演算法和檔案資料版面配置的品質。
-
對閃光燈和 RAM 故障的敏感度。如果檔案已損毀,只要檔案 OTA 未觸及損毀的檔案,就會成功;但如果系統分區偵測到任何損毀情形,則會導致區塊 OTA 失敗。
更新已修改的系統
如果裝置的系統分區已修改,且搭載 Android 5.0:
-
增量區塊 OTA 更新失敗。系統分區可能會在
adb remount
期間或受到惡意軟體影響而遭到修改。檔案 OTA 可容許分區進行部分變更,例如新增非來源或目標版本的檔案。不過,區塊 OTA 不允許新增分割區,因此使用者必須安裝完整的 OTA (覆寫任何系統分割區修改內容),或刷新新的系統映像檔,以便日後啟用 OTA。
-
嘗試變更已修改的檔案會導致更新失敗。無論是檔案還是區塊 OTA 更新,如果 OTA 嘗試變更已修改的檔案,OTA 更新就會失敗。
-
嘗試存取已修改的檔案會產生錯誤 (僅限 dm-verity)。無論是檔案和封鎖 OTA 更新,如果啟用 dm-verity,且 OTA 嘗試存取系統檔案系統的修改部分,OTA 就會產生錯誤。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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-27 (世界標準時間)。"],[],[],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."]]