Восстановление и низкоуровневые операции

[android_roman]

Эта глава про ситуации, в которых обычный adb shell заканчивается: система не загружается, нужно вручную накатить OTA, перепрошить раздел или спасти файлы с телефона с разбитым экраном. Здесь сходятся три инструмента: adb, режим recovery и fastboot. Перед стартом обновите platform-tools до свежей ветки (в 2026 это 36.x), старые версии fastboot не умеют работать с динамическими разделами и валятся на современных устройствах с невнятными ошибками.

Код: Выделить всё

$ fastboot --version
fastboot version 36.0.0-13206524
Installed as /opt/platform-tools/fastboot

Карта режимов и переходы:

У устройства на Android 14/15 четыре состояния, между которыми придется перемещаться. Из загруженной системы:

Код: Выделить всё

adb reboot                  # обычная перезагрузка в систему
adb reboot recovery         # режим восстановления
adb reboot bootloader       # загрузчик, он же режим fastboot
adb reboot fastboot         # fastbootd, userspace fastboot (Android 10+)
adb reboot sideload         # recovery сразу в режиме приема пакета (работает не на всех прошивках)

Из загрузчика обратно:

Код: Выделить всё

fastboot reboot             # в систему
fastboot reboot bootloader  # перезапуск самого загрузчика
fastboot reboot recovery    # в recovery (на современных загрузчиках)
fastboot reboot fastboot    # в fastbootd

Кто сейчас на проводе, проверяется двумя разными командами, и путать их не надо:

Код: Выделить всё

$ adb devices
List of devices attached
29051FDH3000WV  recovery

$ fastboot devices
29051FDH3000WV  fastboot

adb видит систему, recovery и sideload. fastboot видит только загрузчик и fastbootd. Пустой adb devices при телефоне в bootloader, это не поломка, просто не тот инструмент.

ADB в recovery:

Стоковый recovery после загрузки часто показывает лежащего робота с надписью "No command". Меню вызывается так: зажмите кнопку питания и коротко нажмите громкость вверх. Внутри стокового recovery работает урезанный adbd: adb devices устройство покажет, но adb shell и pull/push обычно недоступны. Его единственная практическая задача, прием обновления через sideload. Кастомные recovery (TWRP, OrangeFox) поднимают полноценный adbd с шеллом и root, к ним вернемся в разделе про спасение данных.

Sideload, установка обновления:

Типовой сценарий: после неудачного OTA телефон уходит в бутлуп, система не грузится, recovery живой. Скачиваете полный OTA-образ строго для своей модели (для Pixel они выложены на официальной странице образов для разработчиков, у других вендоров на сайтах поддержки), дальше:

В меню recovery кнопками громкости выбираете пункт "Apply update from ADB" и подтверждаете питанием. Устройство переключается в режим sideload:

Код: Выделить всё

$ adb devices
List of devices attached
29051FDH3000WV  sideload

Отправляете пакет:

Код: Выделить всё

$ adb sideload shiba-ota-bp1a.250505.005.zip
serving: 'shiba-ota-bp1a.250505.005.zip'  (~47%)
Total xfer: 1.00x

Важная деталь: процент в терминале показывает передачу файла, а не установку. На Pixel прогресс стабильно замирает на 47% или 94%, при этом установка идет дальше, смотреть надо на экран телефона. Кабель не дергать, дождаться надписи об успехе на устройстве и только потом перезагружаться.

Частые проблемы sideload. Первая:

Код: Выделить всё

adb: sideload connection failed: no devices/emulators found

В режиме sideload устройство меняет USB-конфигурацию. На Windows откройте диспетчер устройств и переустановите Google USB Driver, на Linux сделайте adb kill-server и проверьте udev-правила. Вторая проблема видна на экране телефона:

Код: Выделить всё

E: footer is wrong
E: Signature verification failed
Installation aborted.

Стоковый recovery принимает только пакеты, подписанные производителем, и только полные OTA для этой модели и региона. ZIP с Magisk или кастомной прошивкой он не поставит, для такого нужен кастомный recovery, где sideload работает с любыми пакетами.

Fastboot и fastbootd:

Это два разных режима с одним клиентом. Классический fastboot живет в загрузчике и шьет физические разделы: boot, init_boot, vendor_boot, dtbo, radio, bootloader. fastbootd запускается из recovery-окружения и умеет динамические разделы внутри super: system, vendor, product, system_ext. Попытка прошить system из обычного загрузчика на устройстве с динамическими разделами заканчивается так:

Код: Выделить всё

$ fastboot flash system system.img
FAILED (remote: 'Partition system_a not found')

Лечение: fastboot reboot fastboot и повтор команды уже в fastbootd.

Полезная диагностика перед любой прошивкой:

Код: Выделить всё

$ fastboot getvar all 2>&1 | grep -E "current-slot|slot-count|unlocked|secure"
(bootloader) current-slot:a
(bootloader) slot-count:2
(bootloader) unlocked:yes
(bootloader) secure:yes

slot-count:2 означает A/B-разметку: два комплекта разделов, OTA ставится в неактивный слот, при сбое загрузчик откатывается на старый. Этим можно пользоваться и вручную:

Код: Выделить всё

$ fastboot getvar current-slot
current-slot: a
$ fastboot set_active b
Setting current slot to 'b'                        OKAY [  0.011s]

Если устройство перестало грузиться после обновления, переключение слота нередко возвращает рабочую систему за десять секунд.

Разблокировка загрузчика:

Без нее fastboot откажется шить что-либо. Последовательность:

1. В настройках семь раз тапнуть по номеру сборки, затем в параметрах разработчика включить переключатель "Заводская разблокировка" (OEM unlocking).
2. Перейти в загрузчик: adb reboot bootloader.
3. Дать команду разблокировки:

Код: Выделить всё

$ fastboot flashing unlock
OKAY [ 14.880s]
Finished. Total time: 14.881s

На экране телефона появится предупреждение, выбор подтверждается громкостью и питанием. На старых устройствах команда называется fastboot oem unlock. Разблокировка принудительно стирает все данные, это защита от кражи, а не недоработка: сначала бэкапы (глава 18), потом разблокировка. На части устройств есть второй уровень, fastboot flashing unlock_critical, для разделов самого загрузчика.

Типовая ошибка:

Код: Выделить всё

FAILED (remote: 'flashing unlock is not allowed')

Либо забыли включить OEM unlocking, либо производитель запретил разблокировку этой модели. Реалии рынка СНГ: у Xiaomi разблокировка идет только через фирменный Mi Unlock с привязкой аккаунта и периодом ожидания от недели до месяца, на HyperOS добавились требования к аккаунту и годовые лимиты. У Samsung режима fastboot нет вообще, там Download mode и прошивка через Odin или Heimdall. Huawei перестал выдавать коды разблокировки еще в 2018, эти устройства для кастомов закрыты.

Перепрошивка разделов, правильная последовательность:

Эталон, заводской образ Pixel. Внутри архива лежит скрипт flash-all.sh, и его порядок стоит запомнить:

Код: Выделить всё

fastboot flash bootloader bootloader-shiba-*.img
fastboot reboot bootloader
fastboot flash radio radio-shiba-*.img
fastboot reboot bootloader
fastboot -w update image-shiba-bp1a.250505.005.zip

Сначала загрузчик, затем перезагрузка в него же, чтобы дальше работала уже новая версия, потом радиопрошивка, снова перезагрузка, и только после этого основной образ. Команда update сама перейдет в fastbootd для динамических разделов. Флаг -w стирает userdata; уберите его, если нужно сохранить данные, но при большом скачке версий это может закончиться бутлупом.

Ручная прошивка отдельных разделов:

Код: Выделить всё

fastboot flash boot magisk_patched-28.1.img       # ядро и ramdisk
fastboot flash init_boot magisk_patched-28.1.img  # на Pixel 7+ и многих устройствах 2023+ Magisk шьется сюда
fastboot flash dtbo dtbo.img
fastboot --slot all flash bootloader bootloader-shiba-*.img   # сразу в оба слота

Прошивка не в тот раздел, классика бутлупов: если у модели есть init_boot, патчить и шить для root надо именно его, эксперименты с boot на таких устройствах дают либо отсутствие root, либо бутлуп. Еще нюанс: на большинстве A/B-устройств отдельного раздела recovery нет, он живет внутри ramdisk boot или vendor_boot, поэтому "прошить recovery" там физически некуда.

Самый безопасный прием, загрузка образа без прошивки:

Код: Выделить всё

fastboot boot twrp-3.7.1_12-miatoll.img

Образ исполняется один раз из памяти, разделы не изменяются, после перезагрузки все как было. Так тестируют кастомные recovery и патченные ядра перед записью. Требует разблокированного загрузчика.

Извлечение данных в экстренных ситуациях:

Сценарий первый: экран разбит, система работает, отладка была включена и ваш компьютер авторизован. Тогда все штатно:

Код: Выделить всё

adb pull /sdcard/DCIM ./rescue/DCIM
adb exec-out tar -cf - -C /sdcard Documents Download Pictures > rescue.tar

scrcpy (упоминали в главе 14) даст экран и управление с компьютера даже при мертвом тачскрине. Чаты мессенджеров так не вытащить, их базы лежат в /data и без root недоступны (глава 15).

Сценарий второй: отладка выключена или компьютер не авторизован. Диалог подтверждения RSA-ключа требует работающего экрана, по USB вы ничего не сделаете. Рабочий обход: мышь через OTG-переходник плюс внешний монитор, если устройство умеет DisplayPort через USB-C (Pixel 8 и новее, многие флагманы). Разблокируете, включаете отладку, дальше первый сценарий.

Сценарий третий: система не грузится. Если загрузчик разблокирован, грузите кастомный recovery через fastboot boot и забираете файлы его полноценным adb:

Код: Выделить всё

adb pull /sdcard/ ./rescue/

Здесь главная засада: File-Based Encryption обязателен на всех устройствах, выпущенных с Android 10 и новее. Пока recovery не расшифровал /data (TWRP запросит PIN или пароль экрана, и расшифровка поддерживается далеко не на всех моделях), вместо файлов будут каталоги с именами из случайных символов. Без кода блокировки данные не прочитать, в этом и смысл шифрования.

И честное правило, которое сэкономит время и деньги: заблокированный загрузчик плюс выключенная отладка плюс неизвестный PIN означает, что данные не достанет никто, включая сервисы с программаторами. EDL-режим на чипах Qualcomm (устройство определяется как порт 9008) позволяет вычитать flash-память напрямую, но дамп остается зашифрованным. Лучшая стратегия спасения данных делается заранее: бэкапы и синхронизация, пока телефон жив. Учтите также, что adb backup на Android 12+ почти бесполезен, приложения по умолчанию исключают свои данные из него (разбирали в главе 18).

Если fastboot молчит:

Код: Выделить всё

$ fastboot devices
$ # пусто, хотя телефон в bootloader, или висит < waiting for any device >

На Linux это почти всегда права доступа: добавьте udev-правило для вашего вендора или разово запустите fastboot через sudo. На Windows поставьте Google USB Driver, телефон в диспетчере устройств должен определяться как Android Bootloader Interface. Системной диагностике подключений целиком посвящена глава 29.

[midnightnullptr]

процент в терминале показывает передачу файла, а не установку

вот это надо красным выделять. у меня pixel 7 на 94% висел минут пятнадцать, я уже почти выдернул кабель. добавлю из опыта: если sideload все же упал, в стоковом recovery есть пункт View recovery logs, там видно на чем именно споткнулась установка

[ope2]

про xiaomi все даже мягче написано, чем есть на самом деле. мне на hyperos разблокировку одобрили только после прокачки уровня в приложении сообщества, плюс лимит устройств на аккаунт в год, плюс сам mi unlock работает только под windows. если берете xiaomi специально под кастомы, проверяйте актуальные условия до покупки, они меняются каждые полгода

[BunWhale]

а если загрузчик залочен, fastboot boot twrp.img честно выдаст FAILED или телефон просто перезагрузится в систему? спрашиваю не из любопытства, пытаюсь достать фото с разбитого экрана, отладка выключена. судя по разделу про шифрование шансов у меня ноль, но вдруг

[class78]

не понял момент с ручной прошивкой на a/b. fastboot flash boot пишет в текущий активный слот или в оба? или надо явно fastboot flash boot_b boot.img указывать, когда хочу в неактивный? а то в примере --slot all только для bootloader