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.
Ringkasan bootloader
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Bootloader adalah image eksklusif vendor yang bertanggung jawab untuk memunculkan
kernel di perangkat. Bootloader menjaga status perangkat dan bertanggung jawab
untuk melakukan inisialisasi Trusted Execution Environment (TEE)
dan mengikat root of trust-nya. Bootloader juga memverifikasi integritas
partisi boot dan recovery sebelum memindahkan eksekusi ke kernel.
Contoh alur bootloader
Berikut adalah contoh alur bootloader:
Memuat dan melakukan inisialisasi memori.
Verifikasi perangkat sesuai dengan alur Booting Terverifikasi.
Verifikasi partisi booting, termasuk boot, dtbo, init_boot, dan
recovery, sesuai dengan alur Booting Terverifikasi. Sebagai bagian dari langkah ini, periksa
versi header image booting
dan mengurai header dengan sesuai.
Jika update A/B digunakan, tentukan slot saat ini untuk
di-booting.
Menentukan apakah mode pemulihan harus di-booting. Untuk informasi
selengkapnya, lihat
Mendukung Update OTA.
Muat image booting, seperti boot.img, vendor_boot.img,
init_boot.img, dan image booting vendor eksklusif lainnya. Image booting ini
berisi image kernel dan ramdisk.
Muat kernel ke dalam memori sebagai biner terkompresi
yang dapat dieksekusi secara mandiri. Kernel mendekompresi dirinya sendiri dan mulai dieksekusi ke dalam memori.
Muat ramdisk dan bagian bootconfig ke dalam memori
untuk membuat initramfs.
Fitur terkait bootloader tambahan
Berikut adalah daftar fitur terkait bootloader tambahan yang dapat Anda
terapkan:
Overlay hierarki perangkat (DTO).
Overlay hierarki perangkat memungkinkan bootloader
mendukung berbagai konfigurasi hardware. DTO dikompilasi menjadi blob
hierarki perangkat (DTB) yang digunakan oleh bootloader.
Pengacakan alamat virtual image kernel. Bootloader mendukung
pengacakan alamat virtual tempat image kernel dimuat. Untuk
mengacak alamat, tetapkan RANDOMIZE_BASE ke true di konfigurasi kernel.
Bootloader harus menyediakan entropi dengan meneruskan nilai u64 acak di
node hierarki perangkat /chosen/kaslr-seed.
Booting Terverifikasi. Booting Terverifikasi memungkinkan
bootloader untuk memastikan semua kode yang dieksekusi berasal dari sumber tepercaya.
Konfigurasi booting.
Konfigurasi booting
tersedia di Android 12 dan yang lebih tinggi serta merupakan mekanisme untuk meneruskan
detail konfigurasi dari build dan bootloader ke sistem operasi.
Sebelum Android 12, parameter command line kernel dengan awalan
androidboot digunakan.
Update over the air (OTA). Perangkat Android di lapangan dapat menerima dan
menginstal update OTA ke sistem, software aplikasi, dan
aturan zona waktu. Fitur ini memiliki implikasi pada implementasi
bootloader Anda. Untuk informasi umum tentang OTA, lihat
Update OTA. Untuk mengetahui detail penerapan OTA khusus bootloader, lihat Mendukung update OTA.
Pemikatan versi.
Penautan versi mengikat
kunci keamanan ke sistem operasi dan versi tingkat patch. Binding versi
memastikan bahwa penyerang yang menemukan kelemahan dalam versi lama
sistem atau software TEE tidak dapat mengembalikan perangkat ke versi yang rentan
dan menggunakan kunci yang dibuat dengan versi yang lebih baru. Bootloader harus memberikan informasi
tertentu untuk mendukung binding versi. Untuk informasi selengkapnya, lihat
Informasi versi di properti AVB.
Command line kernel
Gabungkan command line kernel dari lokasi berikut:
Command line bootloader: kumpulan parameter statis dan dinamis yang ditentukan oleh bootloader
Hierarki perangkat: dari node chosen/bootargs
defconfig: dari CONFIG_CMDLINE
boot.img: dari command line (untuk offset dan ukuran, lihat
system/core/mkbootimg/bootimg.h
Mulai Android 12, untuk parameter androidboot.* yang
perlu diteruskan ke ruang pengguna Android, kita dapat menggunakan
bootconfig, bukan
command line kernel.
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,["# Bootloader overview\n\nA *bootloader* is a vendor-proprietary image responsible for bringing up the\nkernel on a device. The bootloader guards the device state and is responsible\nfor initializing the [Trusted Execution Environment (TEE)](/docs/security/features/trusty)\nand binding its root of trust. The bootloader also verifies the integrity of the\n`boot` and `recovery` partitions before moving execution to the kernel.\n\nExample bootloader flow\n-----------------------\n\nHere's an example bootloader flow:\n\n1. Load and initialize memory.\n\n2. Verify the device according to [Verified Boot flow](/docs/security/features/verifiedboot).\n\n3. Verify the boot partitions, including `boot`, `dtbo`, `init_boot`, and\n `recovery`, according to the Verified Boot flow. As part of this step, check the\n [boot image header](/docs/core/architecture/bootloader/boot-image-header)\n version and parse the header accordingly.\n\n4. If [A/B updates](/docs/core/ota/ab) are used, determine the current slot to\n boot.\n\n5. Determine if recovery mode should be booted. For more\n information, see\n [Supporting OTA Updates](/docs/core/architecture/bootloader/updating).\n\n6. Load the boot images, such as `boot.img`, `vendor_boot.img`,\n `init_boot.img`, and other proprietary vendor boot images. These boot images\n contain the kernel and ramdisk images.\n\n 1. Load the kernel into memory as a self-executable compressed\n binary. The kernel decompresses itself and starts executing into memory.\n\n 2. Load ramdisks and the bootconfig section into memory\n to create `initramfs`.\n\nAdditional bootloader-related features\n--------------------------------------\n\nFollowing is a list of additional bootloader-related features that you can\nimplement:\n\n- *Device tree overlay (DTO).*\n A [device tree overlay](/docs/core/architecture/dto) lets the bootloader to\n support different hardware configurations. A DTO is compiled into a *device\n tree blob (DTB)* which is used by the bootloader.\n\n- *Kernel image virtual address randomization.* The bootloader supports\n randomizing the virtual address at which the kernel image is loaded. To\n randomize the address, set `RANDOMIZE_BASE` to `true` in the kernel config.\n The bootloader must provide entropy by passing a random u64 value in the\n `/chosen/kaslr-seed` device tree node.\n\n- *Verified Boot.* [Verified Boot](/docs/security/features/verifiedboot) lets\n the bootloader to ensure all executed code comes from a trusted source.\n\n- *Boot config.*\n [Boot config](/docs/core/architecture/bootloader/implementing-bootconfig)\n is available in Android 12 and higher and is a mechanism for passing\n configuration details from the build and bootloader to the operating system.\n Prior to Android 12, kernel command-line parameters with the prefix of\n `androidboot` are used.\n\n- *Over-the-air (OTA) updates.* Android devices in the field can receive and\n install OTA updates to the system, app software, and\n time zone rules. This feature has implications on your bootloader\n implementation. For general information on OTA, see\n [OTA updates](/docs/core/ota). For bootloader-specific OTA implementation\n details, see\n [Supporting OTA updates](/docs/core/architecture/bootloader/updating).\n\n- *Version binding* .\n [Version binding](/docs/security/features/keystore/version-binding) binds\n security keys to the operating system and patch level version. Version binding\n ensures that an attacker who discovers a weakness in an old version of the\n system or the TEE software can't roll a device back to the vulnerable version\n and use keys created with the newer version. The bootloader must provide certain\n information to support version binding. For further information, see\n [Version information in AVB properties](/docs/core/architecture/bootloader/version-info-avb).\n\nKernel command line\n-------------------\n\nConcatenate the kernel command line from the following locations:\n\n- Bootloader command line: set of static and dynamic parameters determined by\n the bootloader\n\n- Device tree: from the `chosen/bootargs` node\n\n- `defconfig`: from `CONFIG_CMDLINE`\n\n- `boot.img`: from the command line (for offsets and sized, refer to\n [`system/core/mkbootimg/bootimg.h`](https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/android16-release/include/bootimg/bootimg.h)\n\nAs of Android 12, for `androidboot.*` parameters that\nwe need to pass to Android userspace, we can use\n[bootconfig](/docs/core/architecture/bootloader/implementing-bootconfig) instead\nof the kernel command line."]]
