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.
Aktualizacje systemu inne niż A/B
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Aktualizacje inne niż AB to wycofana metoda OTA używana przez starsze urządzenia z Androidem (Android 6 i starsze). Te urządzenia mają specjalną partycję odzyskiwania, na której znajduje się oprogramowanie potrzebne do rozpakowania pobranego pakietu aktualizacji i zastosowania aktualizacji do innych partycji.
Na starszych urządzeniach z Androidem bez partycji A/B przestrzeń flash zwykle zawiera te partycje:
- rozruch
-
Zawiera jądro Linuxa i minimalny system plików głównych (załadowany na dysk RAM). Zamontuj system i inne partycje oraz uruchom środowisko uruchomieniowe znajdujące się na partycji systemowej.
- system
-
Zawiera aplikacje systemowe i biblioteki, których kod źródłowy jest dostępny w ramach Projektu Android Open Source (AOSP). Podczas normalnej pracy ta partycja jest montowana tylko do odczytu; jej zawartość zmienia się tylko podczas aktualizacji OTA.
- firma
-
Zawiera aplikacje i biblioteki systemowe, których nie można uruchomić w ramach Projektu Android Open Source (AOSP). Podczas normalnej pracy ten partycja jest zamontowana tylko do odczytu; jej zawartość zmienia się tylko podczas aktualizacji OTA.
- userdata
-
Przechowuje dane zapisane przez aplikacje zainstalowane przez użytkownika. Ta partycja nie jest zwykle modyfikowana przez proces aktualizacji OTA.
- Pamięć podręczna
-
Tymczasowa partycja używana przez kilka aplikacji (dostęp do tej partycji wymaga specjalnych uprawnień aplikacji) oraz do przechowywania pobranych pakietów aktualizacji OTA. Inne programy korzystają z tego miejsca, zakładając, że pliki mogą zniknąć w każdej chwili. Niektóre instalacje pakietów OTA mogą spowodować całkowite wyczyszczenie tej partycji. Pamięć podręczna zawiera też logi aktualizacji z aktualizacji OTA.
- dojście do siebie
-
Zawiera drugi kompletny system Linux, w tym jądro i specjalny binarny obraz odzyskiwania, który odczytuje pakiet i użyje jego zawartości do zaktualizowania innych partycji.
- misc
-
Mała partycja używana przez funkcję odzyskiwania do przechowywania informacji o tym, co robi, na wypadek, gdyby urządzenie zostało ponownie uruchomione podczas instalowania pakietu OTA.
Cykl życia aktualizacji OTA
Typowa aktualizacja OTA obejmuje te kroki:
-
Urządzenie regularnie sprawdza serwery OTA i jest powiadamiane o dostępności aktualizacji, w tym adres URL pakietu aktualizacji i ciąg znaków opisu, który można wyświetlić użytkownikowi.
-
Aktualizacje są pobierane do pamięci podręcznej lub partycji danych, a ich podpis kryptograficzny jest weryfikowany na podstawie certyfikatów w
/system/etc/security/otacerts.zip. Użytkownik zostaje poproszony o zainstalowanie aktualizacji.
-
Urządzenie uruchamia się ponownie w trybie odzyskiwania, w którym rdzeń i system na partycji odzyskiwania są uruchamiane zamiast rdzenia na partycji rozruchowej.
-
Binarny plik odzyskiwania jest uruchamiany przez init. Znajduje w
/cache/recovery/command argumenty wiersza poleceń, które wskazują na pobrany pakiet.
-
Odzyskiwanie weryfikuje podpis kryptograficzny pakietu za pomocą kluczy publicznych w
/res/keys (część dysku RAM zawarta w partycji odzyskiwania).
-
Dane są pobierane z opakowania i używane do aktualizacji partycji rozruchowej, systemowej lub dostawcy w razie potrzeby. Jeden z nowych plików znajdujących się na partycji systemowej zawiera zawartość nowej partycji odzyskiwania.
-
Urządzenie uruchamia się normalnie.
-
Ładuje się nowo zaktualizowana partycja rozruchu, która jest montowana i rozpoczyna wykonywanie plików binarnych na nowo zaktualizowanej partycji systemowej.
-
Podczas normalnego uruchamiania system porównuje zawartość partycji odzyskiwania z pożądaną zawartością (która była wcześniej zapisana jako plik w
/system). Jeśli są różne, partycja odzyskiwania jest ponownie zapisywana za pomocą pożądanej zawartości. (podczas kolejnych rozruchów partycja odzyskiwania zawiera już nowe treści, więc nie trzeba ponownie instalować oprogramowania).
Aktualizacja systemu została zakończona. Dzienniki aktualizacji znajdziesz w /cache/recovery/last_log.#.
Aktualizowanie pakietów
Pakiet aktualizacji to plik .zip zawierający plik binarny META-INF/com/google/android/update-binary. Po zweryfikowaniu podpisu pakietu recovery wyodrębnia plik binarny do /tmp i uruchamia go, przekazując te argumenty:
-
Zaktualizuj numer wersji interfejsu API binarnego. Jeśli argumenty przekazane do funkcji aktualizacji powodują zmianę binarną, ta liczba wzrasta.
-
Deskryptor pliku rury poleceń. Program aktualizacji może używać tego kanału do wysyłania poleceń do binarnego pliku odzyskiwania, głównie w celu wprowadzania zmian w interfejsie, takich jak wyświetlanie postępu użytkownikowi.
-
Nazwa pliku pakietu aktualizacji
.zip.
Pakiet aktualizacji może używać dowolnego statycznie połączonego binarnego pliku binarnego jako binarnego pliku aktualizacji. Narzędzia do tworzenia pakietów OTA korzystają z programu aktualizacyjnego (bootable/recovery/updater), który zapewnia prosty język skryptowy umożliwiający wykonywanie wielu zadań związanych z instalacją. Możesz zastąpić dowolny inny binarny plik wykonywalny na urządzeniu.
Szczegółowe informacje o binarnym pliku aktualizatora, edycji składni i wbudowanych funkcjach znajdziesz w artykule Informacje o pakietach OTA.
Migracja z poprzednich wersji
Podczas migracji z wersji 2.3, 3.0 lub 4.0 Androida główną zmianą jest przekształcenie wszystkich funkcji związanych z danym urządzeniem z zestawu funkcji C z wstępnie zdefiniowanymi nazwami w obiekty C++.
W tabeli poniżej znajdziesz stare funkcje i nowe metody, które służą do mniej więcej tego samego celu:
| Funkcja C |
Metoda w C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(także RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
Przekształcenie starych funkcji w nowe metody powinno być stosunkowo proste. Pamiętaj, aby dodać nową funkcję make_device(), która utworzy i zwróci instancję nowej podklasy Device.
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,["# 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."]]
