Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
Update sistem non-A/B
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Update non-AB adalah metodologi OTA yang tidak digunakan lagi dan digunakan oleh Perangkat Android lama (Android 6 dan
yang lebih lama). Perangkat ini memiliki partisi pemulihan khusus yang berisi software yang diperlukan untuk
mengekstrak paket update yang didownload dan menerapkan update ke partisi lainnya.
Pada perangkat Android lama tanpa partisi A/B, ruang flash biasanya berisi
partisi berikut:
- booting
-
Berisi kernel Linux dan sistem file root minimal (dimuat ke disk RAM). File ini memasang
sistem dan partisi lainnya serta memulai runtime yang terletak di partisi sistem.
- system
-
Berisi aplikasi sistem dan library yang memiliki kode sumber yang tersedia di Project Open
Source Android (AOSP). Selama operasi normal, partisi ini dipasang sebagai hanya baca; kontennya
hanya berubah selama update OTA.
- vendor
-
Berisi aplikasi dan library sistem yang tidak memiliki kode sumber yang tersedia
di Proyek Open Source Android (AOSP). Selama operasi normal, partisi ini dipasang
sebagai hanya baca; kontennya hanya berubah selama update OTA.
- userdata
-
Menyimpan data yang disimpan oleh aplikasi yang diinstal oleh pengguna, dll. Partisi ini biasanya tidak
disentuh oleh proses update OTA.
- cache
-
Area penyimpanan sementara yang digunakan oleh beberapa aplikasi (mengakses partisi ini memerlukan izin
aplikasi khusus) dan untuk penyimpanan paket update OTA yang didownload. Program lain menggunakan
ruang ini dengan harapan bahwa file dapat hilang kapan saja. Beberapa penginstalan paket
OTA dapat menyebabkan partisi ini dihapus sepenuhnya. Cache juga berisi
log update dari update OTA.
- pemulihan
-
Berisi sistem Linux lengkap kedua, termasuk kernel dan biner pemulihan khusus
yang membaca paket dan menggunakan kontennya untuk mengupdate partisi lainnya.
- misc
-
Partisi kecil yang digunakan oleh pemulihan untuk menyimpan beberapa informasi tentang apa yang dilakukannya
jika perangkat dimulai ulang saat paket OTA diterapkan.
Durasi update OTA
Update OTA standar berisi langkah-langkah berikut:
-
Perangkat melakukan check in reguler dengan server OTA dan diberi tahu tentang ketersediaan
update, termasuk URL paket update dan string deskripsi untuk ditampilkan kepada pengguna.
-
Memperbarui download ke cache atau partisi data, dan tanda tangan kriptografisnya diverifikasi
terhadap sertifikat di
/system/etc/security/otacerts.zip. Pengguna diminta untuk menginstal update.
-
Perangkat dimulai ulang ke mode pemulihan, dengan kernel dan sistem di partisi pemulihan
di-booting, bukan kernel di partisi booting.
-
Biner pemulihan dimulai oleh init. Fungsi ini menemukan argumen command line di
/cache/recovery/command yang mengarahkannya ke paket yang didownload.
-
Pemulihan memverifikasi tanda tangan kriptografi paket dengan kunci publik di
/res/keys (bagian dari disk RAM yang terdapat di partisi pemulihan).
-
Data diambil dari paket dan digunakan untuk mengupdate partisi booting, sistem, dan/atau
vendor sesuai kebutuhan. Salah satu file baru yang tersisa di partisi sistem berisi
konten partisi pemulihan baru.
-
Perangkat dimulai ulang seperti biasa.
-
Partisi booting yang baru diupdate dimuat, dan di-mount serta mulai mengeksekusi biner
di partisi sistem yang baru diupdate.
-
Sebagai bagian dari startup normal, sistem akan memeriksa konten partisi pemulihan
dengan konten yang diinginkan (yang sebelumnya disimpan sebagai file di
/system). Keduanya berbeda, sehingga partisi pemulihan di-flash ulang dengan
konten yang diinginkan. (Pada booting berikutnya, partisi pemulihan sudah berisi
konten baru, sehingga tidak perlu melakukan flash ulang.)
Update sistem selesai. Log update dapat ditemukan di
/cache/recovery/last_log.#.
Mengupdate paket
Paket update adalah file .zip yang berisi META-INF/com/google/android/update-binary biner
yang dapat dieksekusi. Setelah memverifikasi tanda tangan pada
paket, recovery mengekstrak biner ini ke /tmp dan menjalankan biner,
dengan meneruskan argumen berikut:
-
Memperbarui nomor versi API biner. Jika argumen yang diteruskan ke update biner berubah, angka ini akan bertambah.
-
Deskriptor file pipa perintah. Program update dapat menggunakan pipe ini untuk mengirim perintah kembali ke biner pemulihan, sebagian besar
untuk perubahan UI, seperti menunjukkan progres kepada pengguna.
-
Nama file
.zip paket update.
Paket update dapat menggunakan biner yang ditautkan secara statis sebagai biner update. Alat pembuatan paket
OTA menggunakan program updater (bootable/recovery/updater), yang
menyediakan bahasa skrip sederhana yang dapat melakukan banyak tugas penginstalan. Anda dapat mengganti
biner lain yang berjalan di perangkat.
Untuk mengetahui detail tentang biner updater, sintaksis edify, dan fungsi bawaan, lihat
Di Dalam Paket OTA.
Bermigrasi dari rilis sebelumnya
Saat bermigrasi dari rilis Android 2.3/3.0/4.0, perubahan utamanya adalah konversi semua
fungsi khusus perangkat dari kumpulan fungsi C dengan nama yang telah ditentukan ke objek C++.
Tabel berikut mencantumkan fungsi lama dan metode baru yang memiliki tujuan yang kurang lebih
setara:
| Fungsi C |
Metode C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(juga RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
Konversi fungsi lama ke metode baru seharusnya cukup mudah. Jangan lupa
untuk menambahkan fungsi make_device()
baru guna membuat dan menampilkan instance subclass Perangkat baru Anda.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
