Od 27 marca 2025 r. zalecamy używanie android-latest-release
zamiast aosp-main
do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Omówienie programu rozruchowego
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Program rozruchowy to obraz zastrzeżonego oprogramowania dostawcy, który odpowiada za wczytywanie jądra na urządzeniu. Bootloader chroni stan urządzenia i odpowiada za inicjowanie zaufanego środowiska wykonawczego (TEE) oraz wiązanie jego zaufanego źródła. Bootloader sprawdza integralność partycji boot
i recovery
, zanim przekaże wykonywanie do jądra.
Przykładowy proces uruchamiania
Oto przykładowy proces uruchamiania:
wczytać i inicjializować pamięć;
Zweryfikuj urządzenie zgodnie z procedurą zweryfikowanego rozruchu.
Sprawdź partycje rozruchowe, w tym boot
, dtbo
, init_boot
i recovery
, zgodnie z procesem weryfikacji podczas uruchamiania. W ramach tego kroku sprawdź wersję nagłówka obrazu rozruchu i odpowiednio przeanalizuj nagłówek.
Jeśli używasz aktualizacji A/B, określ aktualny slot, z którego ma być ładowany system.
Określ, czy należy uruchomić tryb odzyskiwania. Więcej informacji znajdziesz w artykule Obsługa aktualizacji OTA.
Załaduj obrazy rozruchowe, takie jak boot.img
, vendor_boot.img
, init_boot.img
i inne obrazy rozruchowe sprzedawców. Te obrazy rozruchu zawierają obrazy jądra i pliku wymiany.
Wczytaj ją do pamięci jako samouruchamiający się skompresowany plik binarny. Jądro dekompresuje się i rozpoczyna wykonywanie w pamięci.
Załaduj do pamięci ramdiski i sekcję bootconfig, aby utworzyć initramfs
.
Dodatkowe funkcje związane z bootloaderem
Oto lista dodatkowych funkcji związanych z bootloaderem, które możesz zaimplementować:
Nakładka drzewa urządzeń (DTO).
Nakładka drzewa urządzenia umożliwia bootloaderowi obsługę różnych konfiguracji sprzętowych. DTO jest kompilowane w pliku danych drzewa urządzenia (DTB), który jest używany przez bootloader.
Losowanie adresów wirtualnych obrazu jądra. Bootloader obsługuje losowanie adresu wirtualnego, pod którym ładowany jest obraz jądra. Aby losować adres, ustaw RANDOMIZE_BASE
na true
w konfiguracji jądra.
Program rozruchowy musi zapewnić entropię, przekazując losową wartość u64 w węźle drzewa urządzenia /chosen/kaslr-seed
.
Weryfikacja podczas uruchamiania. Weryfikacja podczas uruchamiania pozwala ładownikowi zadbać o to, aby cały uruchomiony kod pochodzi z zaufanego źródła.
Konfiguracja rozruchu
Konfiguracja rozruchu jest dostępna w Androidzie 12 i nowszych wersjach. Jest to mechanizm przekazywania szczegółów konfiguracji z kompilacji i ładowarki do systemu operacyjnego.
Przed Androidem 12 używane są parametry wiersza poleceń jądra z prefiksem androidboot
.
Aktualizacje bezprzewodowe. Urządzenia z Androidem w polu mogą otrzymywać i instalować aktualizacje OTA systemu, aplikacji i reguł stref czasowych. Ta funkcja ma wpływ na implementację bootloadera. Ogólne informacje o OTA znajdziesz w artykule Aktualizacje OTA. Szczegółowe informacje o wdrożeniu aktualizacji OTA dotyczące programu rozruchowego znajdziesz w artykule Obsługa aktualizacji OTA.
Powiązanie z wersją.
Powiązanie z wersją łączy klucze zabezpieczeń z systemem operacyjnym i poziomem aktualizacji zabezpieczeń. Powiązanie z wersją zapewnia, że atakujący, który odkryje słabość w starszej wersji systemu lub oprogramowania TEE, nie będzie mógł przywrócić urządzenia do wersji podatnej na ataki i używać kluczy utworzonych w nowszej wersji. Program rozruchowy musi zawierać określone informacje, aby obsługiwać wiązanie wersji. Więcej informacji znajdziesz w artykule Informacje o wersji w właściwościach AVB.
Wiersz poleceń jądra
Połącz wiersz poleceń jądra z tych lokalizacji:
Wiersz poleceń programu rozruchowego: zbiór parametrów statycznych i dynamicznych określonych przez program rozruchowy.
Drzewo urządzeń: z węzła chosen/bootargs
defconfig
: z CONFIG_CMDLINE
boot.img
: z wiersza poleceń (informacje o przesunięciu i rozmiarze znajdziesz w pliku system/core/mkbootimg/bootimg.h
Od Androida 12 w przypadku parametrów androidboot.*
, które musimy przekazać do przestrzeni użytkownika Androida, możemy używać pliku bootconfig zamiast wiersza poleceń jądra.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]