Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Системные обновления без A/B
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Обновления без AB — это устаревшая методика OTA, используемая на старых устройствах Android (Android 6 и более ранних версий). Эти устройства имеют специальный раздел восстановления, содержащий программное обеспечение, необходимое для распаковки загруженного пакета обновления и применения обновления к другим разделам.
На старых устройствах Android без разделов A/B флэш-пространство обычно содержит следующие разделы:
- ботинок
- Содержит ядро Linux и минимальную корневую файловую систему (загружаемую на RAM-диск). Он монтирует системный и другие разделы и запускает среду выполнения, расположенную в системном разделе.
- система
- Содержит системные приложения и библиотеки, исходный код которых доступен в Android Open Source Project (AOSP). При нормальной работе этот раздел монтируется только для чтения; его содержимое меняется только во время OTA-обновления.
- продавец
- Содержит системные приложения и библиотеки, исходный код которых отсутствует в Android Open Source Project (AOSP). При нормальной работе этот раздел монтируется только для чтения; его содержимое меняется только во время OTA-обновления.
- данные пользователя
- Хранит данные, сохраненные приложениями, установленными пользователем, и т. д. Этот раздел обычно не затрагивается процессом обновления OTA.
- кэш
- Область временного хранения, используемая несколькими приложениями (для доступа к этому разделу требуются специальные разрешения приложений) и для хранения загруженных пакетов обновлений OTA. Другие программы используют это пространство в расчете на то, что файлы могут исчезнуть в любой момент. Некоторые установки пакетов OTA могут привести к полному удалению этого раздела. Кэш также содержит журналы обновлений OTA-обновлений.
- восстановление
- Содержит вторую полную систему Linux, включая ядро и специальный двоичный файл восстановления, который считывает пакет и использует его содержимое для обновления других разделов.
- разное
- Небольшой раздел, используемый программой восстановления для хранения некоторой информации о том, что он делает, на случай, если устройство будет перезагружено во время применения пакета OTA.
Жизнь ОТА-обновлений
Типичное OTA-обновление состоит из следующих шагов:
- Устройство выполняет регулярную проверку на серверах OTA и получает уведомление о доступности обновления, включая URL-адрес пакета обновления и строку описания, которую можно показать пользователю.
- Обновление загружается в кэш или раздел данных, а его криптографическая подпись проверяется по сертификатам в
/system/etc/security/otacerts.zip . Пользователю будет предложено установить обновление. - Устройство перезагружается в режим восстановления, в котором вместо ядра в загрузочном разделе загружаются ядро и система из раздела восстановления.
- Бинарный файл восстановления запускается командой init. Он находит аргументы командной строки в
/cache/recovery/command , которые указывают на загруженный пакет. - Восстановление проверяет криптографическую подпись пакета по открытым ключам в
/res/keys (часть RAM-диска, содержащаяся в разделе восстановления). - Данные извлекаются из пакета и используются для обновления загрузочного, системного раздела и/или раздела поставщика по мере необходимости. Один из новых файлов, оставшихся в системном разделе, содержит содержимое нового раздела восстановления.
- Устройство перезагружается нормально.
- Недавно обновленный загрузочный раздел загружается, монтируется и начинает выполнять двоичные файлы в недавно обновленном системном разделе.
- В рамках обычного запуска система проверяет содержимое раздела восстановления на соответствие желаемому содержимому (которое ранее хранилось в виде файла в
/system ). Они разные, поэтому раздел восстановления перепрошивается с нужным содержимым. (При последующих загрузках раздел восстановления уже содержит новое содержимое, поэтому перепрошивка не требуется.)
Обновление системы завершено! Журналы обновлений можно найти в /cache/recovery/last_log. # .
Обновление пакетов
Пакет обновления представляет собой .zip файл, содержащий исполняемый двоичный META-INF/com/google/android/update-binary . После проверки подписи пакета recovery извлекает этот двоичный файл в /tmp и запускает его, передавая следующие аргументы:
- Обновить номер версии двоичного API . Если аргументы, переданные в двоичный файл обновления, изменяются, это число увеличивается.
- Файловый дескриптор командного канала . Программа обновления может использовать этот канал для отправки команд обратно в двоичный файл восстановления, в основном для изменений пользовательского интерфейса, например для указания прогресса пользователю.
- Имя
.zip файла пакета обновления .
Пакет обновления может использовать любой статически связанный двоичный файл в качестве двоичного файла обновления. Инструменты создания пакетов OTA используют программу обновления ( bootable/recovery/updater ), которая предоставляет простой язык сценариев, позволяющий выполнять множество задач по установке. Вы можете заменить любой другой бинарный файл, работающий на устройстве.
Подробную информацию о двоичном файле средства обновления, синтаксисе edify и встроенных функциях см. в разделе Внутри пакетов OTA .
Миграция с предыдущих выпусков
При переходе с версии Android 2.3/3.0/4.0 основным изменением является преобразование всей специфичной для устройства функциональности из набора функций C с предопределенными именами в объекты C++. В следующей таблице перечислены старые функции и новые методы, которые служат примерно эквивалентной цели:
| Функция C | метод С++ |
|---|
| устройство_recovery_start() | Устройство::RecoveryStart() |
device_toggle_display()
device_reboot_now()
| RecoveryUI::CheckKey()
(также RecoveryUI::IsKeyPressed())
|
| device_handle_key() | Устройство::HandleMenuKey() |
| устройство_perform_action() | Устройство::InvokeMenuItem() |
| устройство_wipe_data() | Устройство::WipeData() |
| устройство_ui_init() | ScreenRecoveryUI::Init() |
Преобразование старых функций в новые методы должно быть достаточно простым. Не забудьте добавить новую функцию make_device() для создания и возврата экземпляра вашего нового подкласса Device.
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 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-29 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."]]
