ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
OTA ตามบล็อก
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
คุณเปิดใช้การอัปเดตแบบ OTA (Over-the-Air) ตามบล็อกสำหรับอุปกรณ์ใหม่ที่ใช้ Android 5.0 ได้ OTA เป็นกลไกที่ OEM ใช้อัปเดตพาร์ติชันระบบของอุปกรณ์จากระยะไกล ดังนี้
-
Android 5.0 ขึ้นไปใช้การบล็อกการอัปเดต OTA เพื่อให้อุปกรณ์แต่ละเครื่องใช้พาร์ติชันเดียวกัน แทนที่จะเปรียบเทียบไฟล์แต่ละไฟล์และคำนวณแพตช์ไบนารี บล็อก OTA จะจัดการทั้งพาร์ติชันเป็นไฟล์เดียวและคำนวณแพตช์ไบนารีเดียว เพื่อให้มั่นใจว่าพาร์ติชันที่ได้จะมีบิตที่ต้องการอย่างแน่นอน ซึ่งจะช่วยให้อิมเมจระบบของอุปกรณ์มีสถานะเดียวกันผ่าน Fastboot หรือ OTA
-
Android 4.4 และเวอร์ชันก่อนหน้าใช้การอัปเดต OTA ของไฟล์ ซึ่งช่วยให้อุปกรณ์มีเนื้อหา สิทธิ์ และโหมดไฟล์ที่คล้ายกัน แต่อนุญาตให้ข้อมูลเมตา เช่น การประทับเวลาและเลย์เอาต์ของพื้นที่เก็บข้อมูลที่เกี่ยวข้องแตกต่างกันไปในแต่ละอุปกรณ์ตามวิธีการอัปเดต
เนื่องจาก OTA แบบบล็อกช่วยให้มั่นใจได้ว่าอุปกรณ์แต่ละเครื่องใช้พาร์ติชันเดียวกัน จึงเปิดใช้ dm-verity เพื่อเซ็นชื่อพาร์ติชันระบบด้วยการเข้ารหัส โปรดดูรายละเอียดเกี่ยวกับ dm-verity ที่หัวข้อการเปิดเครื่องที่ได้รับการยืนยัน
หมายเหตุ: คุณต้องมีระบบ OTA การบล็อกที่ใช้งานได้ก่อนจึงจะใช้ dm-verity ได้
คำแนะนำ
สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 5.0 ขึ้นไป ให้ใช้การบล็อกการอัปเดต OTA ใน ROM ของโรงงาน หากต้องการสร้าง OTA ตามบล็อกสําหรับการอัปเดตครั้งต่อๆ ไป ให้ส่งตัวเลือก --block
ไปยัง ota_from_target_files
สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 4.4 หรือเวอร์ชันก่อนหน้า ให้ใช้การอัปเดต OTA ของไฟล์ แม้ว่าจะเปลี่ยนอุปกรณ์ได้โดยการส่ง OTA แบบเต็มบล็อกของ Android 5.0 ขึ้นไป แต่จะต้องส่ง OTA แบบเต็มซึ่งมีขนาดใหญ่กว่า OTA แบบเพิ่มข้อมูลอย่างมาก (จึงไม่แนะนำ)
เนื่องจาก dm-verity ต้องใช้การรองรับ Bootloader ที่มีเฉพาะในอุปกรณ์ใหม่ที่ใช้ Android 5.0 ขึ้นไป คุณจึงไม่สามารถเปิดใช้ dm-verity สำหรับอุปกรณ์ที่มีอยู่
นักพัฒนาซอฟต์แวร์ที่ทำงานเกี่ยวกับระบบ OTA ของ Android (รูปภาพการกู้คืนและสคริปต์ที่สร้าง OTA) สามารถติดตามการเปลี่ยนแปลงได้โดยสมัครรับจดหมายข่าวจากอีเมล android-ota@googlegroups.com
ไฟล์กับ OTA ของบล็อก
ในระหว่าง OTA แบบไฟล์ Android จะพยายามเปลี่ยนเนื้อหาของพาร์ติชันระบบที่ชั้นระบบไฟล์ (ทีละไฟล์) การอัปเดตไม่ได้รับประกันว่าจะเขียนไฟล์ตามลำดับที่สอดคล้องกัน มีเวลาแก้ไขล่าสุดหรือซุปเปอร์บล็อกที่สอดคล้องกัน หรือแม้แต่วางบล็อกไว้ในตำแหน่งเดียวกันในอุปกรณ์บล็อก ด้วยเหตุนี้ OTA แบบไฟล์จึงดำเนินการไม่สำเร็จในอุปกรณ์ที่เปิดใช้ DM-Verity หลังจากพยายาม OTA แล้ว อุปกรณ์จะไม่บูต
ในระหว่าง OTA ตามบล็อก Android จะส่งความแตกต่างระหว่างรูปภาพบล็อก 2 รูป (แทนที่จะเป็นไฟล์ 2 ชุด) ไปยังอุปกรณ์ การอัปเดตจะตรวจสอบบิลด์อุปกรณ์กับเซิร์ฟเวอร์บิลด์ที่เกี่ยวข้องที่ระดับบล็อก (ใต้ระบบไฟล์) โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
-
การอัปเดตเต็มรูปแบบ การคัดลอกอิมเมจระบบทั้งหมดนั้นง่ายและทำให้การสร้างแพตช์เป็นเรื่องง่าย แต่ก็สร้างอิมเมจขนาดใหญ่ที่อาจทำให้การใช้แพตช์มีค่าใช้จ่ายสูง
-
การอัปเดตแบบเพิ่ม การใช้เครื่องมือเปรียบเทียบไบนารีจะสร้างรูปภาพที่มีขนาดเล็กลงและทำให้การติดตั้งแพตช์เป็นเรื่องง่าย แต่จะใช้หน่วยความจำมากเมื่อสร้างแพตช์
หมายเหตุ: adb fastboot
จะวางบิตเดียวกันทั้งหมดลงในอุปกรณ์เหมือนกับ OTA แบบเต็ม ดังนั้นการแฟลชจึงเข้ากันได้กับ OTA แบบบล็อก
อัปเดตระบบที่ไม่ได้แก้ไข
สำหรับอุปกรณ์ที่มีพาร์ติชันระบบไม่มีการแก้ไขซึ่งใช้ Android 5.0 กระบวนการดาวน์โหลดและติดตั้ง OTA แบบบล็อกจะยังคงเหมือนเดิมกับ OTA แบบไฟล์ อย่างไรก็ตาม การอัปเดต OTA เองอาจมีความแตกต่างอย่างน้อย 1 ข้อต่อไปนี้
-
ขนาดการดาวน์โหลด
การอัปเดต OTA แบบบล็อกทั้งหมดจะมีขนาดใกล้เคียงกับการอัปเดต OTA แบบไฟล์ทั้งหมด และการอัปเดตแบบเพิ่มอาจใหญ่ขึ้นเพียงไม่กี่เมกะไบต์
รูปที่ 1 เปรียบเทียบขนาด OTA ของ Nexus 6 ระหว่างรุ่น Android 5.0 กับ Android 5.1 (การเปลี่ยนแปลงบิลด์เป้าหมายที่ต่างกัน)
โดยทั่วไป การอัปเดต OTA แบบเพิ่มบล็อกจะมีขนาดใหญ่กว่าการอัปเดต OTA แบบเพิ่มไฟล์ เนื่องจากสาเหตุต่อไปนี้
-
การเก็บรักษาข้อมูล OTA แบบบล็อกจะเก็บรักษาข้อมูลได้มากกว่า (ข้อมูลเมตาของไฟล์ ข้อมูล dm-verity เลย์เอาต์ ext4 ฯลฯ) เมื่อเทียบกับ OTA แบบไฟล์
-
ความแตกต่างของอัลกอริทึมการประมวลผล ในการอัปเดต OTA ของไฟล์ หากเส้นทางไฟล์เหมือนกันในทั้ง 2 บิลด์ แพ็กเกจ OTA จะไม่มีข้อมูลสำหรับไฟล์นั้น ในการอัปเดต OTA แบบบล็อก การระบุว่าไฟล์มีการเปลี่ยนแปลงเพียงเล็กน้อยหรือไม่มีการเปลี่ยนแปลงเลยนั้นขึ้นอยู่กับคุณภาพของอัลกอริทึมการคำนวณแพตช์และเลย์เอาต์ของข้อมูลไฟล์ทั้งในระบบต้นทางและระบบปลายทาง
-
ความไวต่อข้อบกพร่องของแฟลชและ RAM หากไฟล์เสียหาย OTA ของไฟล์จะดำเนินการสำเร็จ ตราบใดที่ 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 UTC
[[["เข้าใจง่าย","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 UTC"],[],[],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."]]