Системные обновления без 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-обновление состоит из следующих шагов:

  1. Устройство выполняет регулярную проверку на серверах OTA и получает уведомление о доступности обновления, включая URL-адрес пакета обновления и строку описания, которую можно показать пользователю.
  2. Обновление загружается в кэш или раздел данных, а его криптографическая подпись проверяется по сертификатам в /system/etc/security/otacerts.zip . Пользователю будет предложено установить обновление.
  3. Устройство перезагружается в режим восстановления, в котором вместо ядра в загрузочном разделе загружаются ядро ​​и система из раздела восстановления.
  4. Бинарный файл восстановления запускается командой init. Он находит аргументы командной строки в /cache/recovery/command , которые указывают на загруженный пакет.
  5. Восстановление проверяет криптографическую подпись пакета по открытым ключам в /res/keys (часть RAM-диска, содержащаяся в разделе восстановления).
  6. Данные извлекаются из пакета и используются для обновления загрузочного, системного раздела и/или раздела поставщика по мере необходимости. Один из новых файлов, оставшихся в системном разделе, содержит содержимое нового раздела восстановления.
  7. Устройство перезагружается нормально.
    1. Недавно обновленный загрузочный раздел загружается, монтируется и начинает выполнять двоичные файлы в недавно обновленном системном разделе.
    2. В рамках обычного запуска система проверяет содержимое раздела восстановления на соответствие желаемому содержимому (которое ранее хранилось в виде файла в /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.