ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
การอัปเดตระบบที่ไม่ใช่ A/B
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
การอัปเดตที่ไม่ใช่ AB เป็นวิธีการ OTA ที่เลิกใช้งานแล้วซึ่งอุปกรณ์ Android รุ่นเก่าใช้ (Android 6 และเก่ากว่า) อุปกรณ์เหล่านี้มีพาร์ติชันการกู้คืนเฉพาะที่มีซอฟต์แวร์ที่จำเป็นในการแตกไฟล์แพ็กเกจการอัปเดตที่ดาวน์โหลดมาและใช้การอัปเดตกับพาร์ติชันอื่นๆ
ในอุปกรณ์ Android รุ่นเก่าที่ไม่มีพาร์ติชัน A/B พื้นที่เก็บข้อมูลแฟลชมักจะมีพาร์ติชันต่อไปนี้
- บูต
-
มีเคอร์เนล Linux และระบบไฟล์รูทขั้นต่ำ (โหลดลงในดิสก์ RAM) โดยจะมาต่อเชื่อมระบบและพาร์ติชันอื่นๆ และเริ่มรันไทม์ที่อยู่ในพาร์ติชันระบบ
- ระบบ
-
มีแอปพลิเคชันและไลบรารีของระบบที่มีซอร์สโค้ดอยู่ในโครงการโอเพนซอร์ส Android (AOSP) ในระหว่างการทํางานตามปกติ ระบบจะเมานต์พาร์ติชันนี้แบบอ่านอย่างเดียว เนื้อหาของพาร์ติชันจะเปลี่ยนแปลงเฉพาะระหว่างการอัปเดต OTA
- ผู้จำหน่าย
-
มีแอปพลิเคชันและไลบรารีของระบบที่ไม่มีซอร์สโค้ดในโครงการโอเพนซอร์ส Android (AOSP) ในระหว่างการทํางานตามปกติ ระบบจะเมานต์พาร์ติชันนี้เป็นแบบอ่านอย่างเดียว โดยเนื้อหาจะเปลี่ยนแปลงเฉพาะระหว่างการอัปเดต OTA
- userdata
-
จัดเก็บข้อมูลที่บันทึกโดยแอปพลิเคชันที่ผู้ใช้ติดตั้งไว้ ฯลฯ โดยปกติแล้วกระบวนการอัปเดต OTA จะไม่แตะต้องพาร์ติชันนี้
- แคช
-
พื้นที่เก็บข้อมูลชั่วคราวที่แอปพลิเคชันบางรายการใช้ (การเข้าถึงพาร์ติชันนี้ต้องมีสิทธิ์พิเศษของแอป) และสำหรับจัดเก็บแพ็กเกจการอัปเดต OTA ที่ดาวน์โหลด โปรแกรมอื่นๆ ใช้พื้นที่นี้โดยคาดหวังว่าไฟล์อาจหายไปได้ทุกเมื่อ การติดตั้งแพ็กเกจ OTA บางรายการอาจส่งผลให้พาร์ติชันนี้ถูกล้างออกทั้งหมด แคชยังมีบันทึกการอัปเดตจากการอัปเดต OTA ด้วย
- การกู้คืน
-
มีระบบ Linux ที่สมบูรณ์ระบบที่ 2 ซึ่งรวมถึงเคอร์เนลและไบนารีการกู้คืนพิเศษที่อ่านแพ็กเกจและใช้เนื้อหาของแพ็กเกจเพื่ออัปเดตพาร์ติชันอื่นๆ
- เบ็ดเตล็ด
-
พาร์ติชันขนาดเล็กที่การกู้คืนใช้เพื่อเก็บข้อมูลบางอย่างเกี่ยวกับสิ่งที่กำลังทำไว้ในกรณีที่อุปกรณ์รีสตาร์ทขณะกำลังใช้แพ็กเกจ OTA
ระยะเวลาของการอัปเดต OTA
การอัปเดต OTA โดยทั่วไปมีขั้นตอนต่อไปนี้
-
อุปกรณ์จะตรวจสอบกับเซิร์ฟเวอร์ OTA เป็นประจําและได้รับการแจ้งเตือนเมื่อมีอัปเดต รวมถึง URL ของแพ็กเกจอัปเดตและสตริงคําอธิบายที่จะแสดงต่อผู้ใช้
-
อัปเดตการดาวน์โหลดลงในแคชหรือพาร์ติชันข้อมูล และยืนยันลายเซ็นการเข้ารหัสเทียบกับใบรับรองใน
/system/etc/security/otacerts.zip ระบบจะแจ้งให้ผู้ใช้ติดตั้งการอัปเดต
-
อุปกรณ์จะรีบูตเข้าสู่โหมดการกู้คืน ซึ่งระบบจะบูตเคอร์เนลและระบบในพาร์ติชันการกู้คืนแทนเคอร์เนลในพาร์ติชันการบูต
-
init เริ่มไบนารีการกู้คืน โดยจะค้นหาอาร์กิวเมนต์บรรทัดคำสั่งใน
/cache/recovery/command ที่ชี้ไปยังแพ็กเกจที่ดาวน์โหลด
-
การกู้คืนจะยืนยันลายเซ็นการเข้ารหัสของแพ็กเกจเทียบกับคีย์สาธารณะใน
/res/keys (ส่วนหนึ่งของดิสก์ RAM ที่มีอยู่ในพาร์ติชันการกู้คืน)
-
ระบบจะดึงข้อมูลจากแพ็กเกจและใช้เพื่ออัปเดตพาร์ติชันสำหรับบูต ระบบ และ/หรือผู้ให้บริการตามที่จำเป็น ไฟล์ใหม่ 1 ไฟล์ที่เหลืออยู่ในพาร์ติชันระบบจะมีเนื้อหาของพาร์ติชันการกู้คืนใหม่
-
อุปกรณ์รีบูตตามปกติ
-
ระบบจะโหลดพาร์ติชันสำหรับบูตที่อัปเดตใหม่ จากนั้นจะเมานต์และเริ่มดำเนินการไบนารีในพาร์ติชันระบบที่อัปเดตใหม่
-
ในการเริ่มต้นระบบตามปกติ ระบบจะตรวจสอบเนื้อหาของพาร์ติชันการกู้คืนเทียบกับเนื้อหาที่ต้องการ (ซึ่งก่อนหน้านี้จัดเก็บเป็นไฟล์ใน
/system) หากเนื้อหาไม่ตรงกัน ระบบจะแฟลชพาร์ติชันการกู้คืนอีกครั้งด้วยเนื้อหาที่ต้องการ (ในการบูตครั้งต่อๆ ไป พาร์ติชันการกู้คืนจะมีเนื้อหาใหม่อยู่แล้ว จึงไม่จำเป็นต้องแฟลชอีกครั้ง)
การอัปเดตระบบเสร็จสมบูรณ์แล้ว ดูบันทึกการอัปเดตได้ใน
/cache/recovery/last_log.#
อัปเดตแพ็กเกจ
แพ็กเกจอัปเดตคือไฟล์ .zip ที่มีไบนารีที่ปฏิบัติการได้
META-INF/com/google/android/update-binary หลังจากยืนยันลายเซ็นในแพ็กเกจแล้ว recovery จะแตกไฟล์ไบนารีนี้ไปยัง /tmp และเรียกใช้ไบนารีโดยส่งอาร์กิวเมนต์ต่อไปนี้
-
อัปเดตหมายเลขเวอร์ชันของ API แบบไบนารี หากอาร์กิวเมนต์ที่ส่งไปยังการอัปเดตไบนารีมีการเปลี่ยนแปลง ตัวเลขนี้จะเพิ่มขึ้น
-
ตัวระบุไฟล์ของไปป์คำสั่ง โปรแกรมอัปเดตสามารถใช้ไปป์นี้เพื่อส่งคำสั่งกลับไปที่ไบนารีการกู้คืนได้ โดยส่วนใหญ่จะใช้สำหรับการเปลี่ยนแปลง UI เช่น แสดงความคืบหน้าต่อผู้ใช้
-
ชื่อไฟล์
.zip ของแพ็กเกจอัปเดต
แพ็กเกจอัปเดตสามารถใช้ไบนารีที่ลิงก์แบบคงที่ใดก็ได้เป็นไบนารีอัปเดต เครื่องมือสร้างแพ็กเกจ OTA ใช้โปรแกรมอัปเดต (bootable/recovery/updater) ซึ่งมีภาษาสคริปต์ง่ายๆ ที่ทํางานต่างๆ ของการติดตั้งได้ คุณแทนที่ไบนารีอื่นๆ ที่ทำงานในอุปกรณ์ได้
ดูรายละเอียดเกี่ยวกับไบนารีโปรแกรมอัปเดต ไวยากรณ์ edify และฟังก์ชันในตัวได้ที่ภายในแพ็กเกจ OTA
ย้ายข้อมูลจากรุ่นก่อนหน้า
เมื่อย้ายข้อมูลจากรุ่น Android 2.3/3.0/4.0 การเปลี่ยนแปลงที่สำคัญคือการเปลี่ยนฟังก์ชันการทำงานทั้งหมดที่เจาะจงอุปกรณ์จากชุดฟังก์ชัน C ที่มีชื่อที่กำหนดไว้ล่วงหน้าเป็นออบเจ็กต์ C++
ตารางต่อไปนี้แสดงฟังก์ชันเดิมและเมธอดใหม่ที่ทํางานสําหรับวัตถุประสงค์ที่เทียบเท่ากัน
| ฟังก์ชัน C |
เมธอด C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(หรือ RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
การแปลงฟังก์ชันเก่าเป็นเมธอดใหม่ควรทำได้ง่าย อย่าลืมเพิ่มmake_device()ฟังก์ชันใหม่เพื่อสร้างและแสดงผลอินสแตนซ์ของคลาสย่อย Device ใหม่
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา 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,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
