Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Để triển khai bản cập nhật qua mạng không dây (OTA), trình tải khởi động phải có thể truy cập vào ổ RAM khôi phục trong quá trình khởi động. Nếu thiết bị sử dụng hình ảnh khôi phục AOSP chưa sửa đổi, trình tải khởi động sẽ đọc 32 byte đầu tiên trên phân vùng misc; nếu dữ liệu ở đó khớp với boot-recovery, trình tải khởi động sẽ khởi động vào hình ảnh recovery. Phương thức này cho phép mọi công việc khôi phục đang chờ xử lý (ví dụ: áp dụng OTA hoặc xoá dữ liệu) tiếp tục hoàn tất.
Để hỗ trợ bản cập nhật OTA trên các thiết bị sử dụng bản cập nhật A/B, hãy đảm bảo rằng trình tải khởi động của thiết bị đáp ứng các tiêu chí sau.
Tiêu chí chung
Tất cả các phân vùng được cập nhật thông qua OTA đều phải cập nhật được trong khi hệ thống chính khởi động (và không được cập nhật trong chế độ khôi phục).
Để khởi động phân vùng system, trình tải khởi động sẽ truyền giá trị sau đây trên dòng lệnh hạt nhân: ro root=/dev/[node] rootwait init=/init.
Khung Android có trách nhiệm gọi markBootSuccessful từ HAL. Trình tải khởi động không được đánh dấu một phân vùng là đã khởi động thành công.
Hỗ trợ HAL điều khiển khởi động
Trình tải khởi động phải hỗ trợ HAL boot_control như được xác định trong hardware/libhardware/include/hardware/boot_control.h. Trình cập nhật truy vấn HAL điều khiển khởi động, cập nhật khe khởi động không sử dụng, thay đổi khe đang hoạt động bằng HAL và khởi động lại vào hệ điều hành đã cập nhật. Để biết thông tin chi tiết, hãy xem phần Triển khai HAL kiểm soát khởi động.
Hỗ trợ khe
Trình tải khởi động phải hỗ trợ chức năng liên quan đến các phân vùng và khe, bao gồm:
Tên phân vùng phải có hậu tố xác định phân vùng nào thuộc một khe cụ thể trong trình tải khởi động. Đối với mỗi phân vùng như vậy, sẽ có một biến tương ứng has-slot:partition base name có giá trị là yes. Các khe được đặt tên theo thứ tự bảng chữ cái như a, b, c, v.v. tương ứng với các phân vùng có hậu tố _a, _b, _c, v.v. Trình tải khởi động phải thông báo cho hệ điều hành về khe nào đã được khởi động bằng thuộc tính dòng lệnh androidboot.slot_suffix. Thuộc tính này được đặt thông qua bootconfig cho các thiết bị khởi chạy bằng Android 12 trở lên.
Giá trị slot-retry-count được đặt lại thành giá trị dương (thường là 3), do HAL kiểm soát khởi động thông qua lệnh gọi lại setActiveBootSlot hoặc thông qua lệnh fastboot set_active. Khi sửa đổi một phân vùng thuộc một khe, trình tải khởi động sẽ xoá trạng thái "đã khởi động thành công" và đặt lại số lần thử lại cho khe đó.
Trình tải khởi động cũng phải xác định khe nào sẽ tải. Hình này cho thấy một quy trình quyết định mẫu.
Hình 1. Quy trình tạo khe cho trình tải khởi động
Xác định vị trí cần thử. Đừng cố gắng tải một khe được đánh dấu là slot-unbootable. Khe này phải nhất quán với các giá trị do tính năng khởi động nhanh trả về và được gọi là khe hiện tại.
Nếu vị trí hiện tại không được đánh dấu là slot-successful và có slot-retry-count = 0, hãy đánh dấu vị trí hiện tại là slot-unbootable. Sau đó, chọn một khe khác không được đánh dấu là unbootable và được đánh dấu là slot-successful; khe này hiện là khe đã chọn. Nếu không có khe hiện tại, hãy khởi động vào chế độ khôi phục hoặc hiển thị thông báo lỗi có ý nghĩa cho người dùng.
Chọn boot.img thích hợp và đưa đường dẫn để sửa phân vùng hệ thống vào dòng lệnh hạt nhân.
Điền tham số slot_suffix của dòng lệnh hạt nhân.
Khởi động. Nếu không được đánh dấu là slot-successful, hãy giảm slot-retry-count.
Tiện ích fastboot xác định phân vùng cần cài đặt ROM khi chạy bất kỳ lệnh cài đặt ROM nào. Ví dụ: trước tiên, việc chạy lệnh fastboot flash system system.img sẽ truy vấn biến current-slot, sau đó nối kết quả với hệ thống để tạo tên của phân vùng cần được cài đặt ROM (system_a, system_b, v.v.).
Khi đặt khe hiện tại bằng lệnh khởi động nhanh set_active hoặc lệnh kiểm soát khởi động HAL setActiveBootSlot, trình tải khởi động sẽ cập nhật khe hiện tại, xoá slot-unbootable và slot-successful, đồng thời đặt lại số lần thử lại (đây là cách duy nhất để xoá slot-unbootable).
Thiết bị không có bản cập nhật A/B
Để hỗ trợ bản cập nhật OTA trên các thiết bị không sử dụng bản cập nhật A/B (xem phần Thiết bị không thể cập nhật A/B), hãy đảm bảo rằng trình tải khởi động của thiết bị đáp ứng các tiêu chí sau.
Phân vùng recovery phải chứa một hình ảnh có khả năng đọc hình ảnh hệ thống từ một số phân vùng được hỗ trợ (cache, userdata) và ghi hình ảnh đó vào phân vùng system.
Trình tải khởi động phải hỗ trợ khởi động trực tiếp vào chế độ khôi phục.
Nếu hỗ trợ bản cập nhật hình ảnh đài, thì phân vùng recovery cũng phải có thể cài đặt ROM cho đài. Bạn có thể thực hiện việc này theo một trong hai cách:
Trình tải khởi động sẽ cài đặt ROM cho đài. Trong trường hợp này, bạn có thể khởi động lại từ phân vùng khôi phục trở lại trình tải khởi động để hoàn tất quá trình cập nhật.
Hình ảnh khôi phục sẽ truyền nhanh đài phát thanh. Chức năng này có thể được cung cấp dưới dạng thư viện hoặc tiện ích nhị phân.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-27 UTC."],[],[],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."]]
