Команды состояния и перезагрузки

[android_roman]

Перезагрузка устройства из консоли выглядит мелочью, пока не начнешь прошивать телефоны партиями или гонять ночные тесты на стенде из десятка девайсов. Тогда команды этой главы становятся хлебом: они переводят устройство между режимами (система, recovery, bootloader, fastbootd, download), умеют дождаться, пока девайс снова появится на шине, и сообщают скрипту, в каком он сейчас состоянии. Сервер adb и базовый синтаксис мы разобрали в главе 4. Примеры ниже проверены на Platform Tools 35-36 и устройствах с Android 14/15.

adb reboot, обычная перезагрузка:

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

adb reboot

Команда ничего не печатает и сразу возвращает управление. На устройстве adbd выставляет системное свойство sys.powerctl, дальше init корректно останавливает сервисы и перезапускает девайс. Это штатная мягкая перезагрузка, эквивалент перезагрузки из меню питания, только без рук.

Команда идет через adbd, поэтому требует включенной отладки по USB и авторизованного подключения (глава 3). Если устройств несколько, обязателен флаг -s:

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

adb -s R58M45XKWWB reboot

Иначе получите:

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

adb reboot
error: more than one device/emulator

Есть второй путь, через shell:

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

adb shell reboot

Результат тот же, но отрабатывает бинарь toybox внутри устройства, а не reboot-сервис adbd. На кастомных прошивках, где adbd иногда чудит, этот вариант выручает.

Целевые режимы: bootloader и recovery:

adb reboot принимает аргумент, который init передает загрузчику как цель перезагрузки.

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

adb reboot bootloader

Уводит устройство в загрузчик (fastboot mode), на экране обычно меню FASTBOOT MODE с данными о девайсе. Критичный момент: в этом режиме adb устройство больше НЕ видит, оно говорит по другому протоколу. Работать с ним надо утилитой fastboot из тех же Platform Tools:

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

fastboot devices
1A2B3C4D5E6F	fastboot

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

adb reboot recovery

Перезагрузка в рекавери. В стоковом recovery adb работает в урезанном виде: adb devices покажет состояние recovery, доступен минимальный adb shell и adb sideload (последний после выбора пункта Apply update from ADB в меню). В кастомных recovery вроде TWRP или OrangeFox adb почти полноценный, вплоть до adb pull из разделов.

Связка для накатывания OTA-пакета без ковыряния в меню:

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

adb reboot sideload

Устройство уходит в recovery и сразу включает прием пакета. Дальше:

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

adb sideload ota-update.zip
serving: 'ota-update.zip'  (~47%)

Вариант adb reboot sideload-auto-reboot делает то же самое, но после установки пакета девайс сам перезагрузится в систему. Удобно в скриптах массового обновления.

На устройствах с динамическими разделами (Android 10+, то есть почти весь парк 2026 года) есть еще одна цель:

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

adb reboot fastboot

Это fastbootd, юзерспейсный fastboot, живущий в recovery-окружении. Он нужен для работы с логическими разделами (system, vendor, product), классический fastboot в загрузчике их прошивать не умеет, его стихия физические разделы вроде boot и dtbo. Из fastbootd обратно в систему: fastboot reboot.

Про цель system. В официальной справке adb ее нет. Команда adb reboot system на большинстве устройств отработает как обычная перезагрузка, потому что незнакомую причину загрузчик игнорирует и грузит систему. Полагаться на это не надо, пишите просто adb reboot. А вот fastboot reboot system внутри fastbootd вполне легален.

Выключение: adb reboot -p:

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

adb reboot -p

Флаг -p (poweroff) выключает устройство вместо перезагрузки, init на современных Android явно распознает эту цель и превращает ее в shutdown. Эквивалент через shell:

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

adb shell reboot -p

Сценарий из жизни: стенд из 30 телефонов греется впустую на выходных, скрипт перед уходом гасит все разом:

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

for s in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
  adb -s "$s" reboot -p
done

adb wait-for-device, ожидание устройства:

После adb reboot скрипт бежит дальше мгновенно, а устройства на шине нет секунд 30-60. Любая следующая команда упадет с error: no devices/emulators found. Лекарство:

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

adb wait-for-device

Команда блокируется, пока устройство не появится в состоянии device. Полный синтаксис wait-for[-TRANSPORT]-STATE, где STATE одно из device, recovery, rescue, sideload, bootloader, disconnect, а TRANSPORT одно из usb, local, any:

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

adb wait-for-recovery
adb wait-for-usb-device
adb wait-for-disconnect

Подвох номер один: wait-for-bootloader формально есть в справке, но не дождется никогда, потому что в загрузчике устройство для adb-сервера невидимо. Отдельное ожидание тут и не нужно: утилита fastboot сама висит с надписью waiting for any device, пока девайс не появится.

Подвох номер два, классика автоматизации: wait-for-device отпускает скрипт, как только поднялся adbd, а это происходит еще на бутанимации. Ставить пакеты и запускать тесты рано. Правильный паттерн:

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

adb reboot
adb wait-for-device
until [ "$(adb shell getprop sys.boot_completed 2>/dev/null | tr -d '\r')" = "1" ]; do
  sleep 1
done
echo "boot completed"

Свойство sys.boot_completed становится 1, когда система реально догрузилась. tr -d '\r' это страховка от CRLF, актуальная для старых устройств и Windows-окружений.

wait-for-device можно склеить с другой командой в одну строку:

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

adb wait-for-device shell getprop ro.build.version.release
15

adb get-state и adb get-serialno:

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

adb get-state
device

Возможные ответы: device, recovery, sideload, rescue, offline. Состояние bootloader вы отсюда не увидите по уже знакомой причине. Неавторизованное устройство даст ошибку error: device unauthorized, отсутствующее даст error: no devices/emulators found, и в обоих случаях код возврата ненулевой, что удобно для проверок:

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

if adb get-state >/dev/null 2>&1; then
  echo "device online"
fi

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

adb get-serialno
R58M45XKWWB

Печатает серийник подключенного устройства, для эмулятора это будет emulator-5554. Типовое применение: зафиксировать ID в переменную в начале скрипта и дальше везде ходить через -s, чтобы скрипт не развалился, когда кто-то воткнет в стенд второй телефон:

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

SERIAL=$(adb get-serialno)
adb -s "$SERIAL" reboot

Рядом живет adb get-devpath, путь устройства на USB-шине вида usb:1-4.2. Спасает, когда на стенде два дешевых планшета с одинаковыми серийниками, у китайского нонейма такое сплошь и рядом.

Специфика производителей:

Pixel, Motorola, Sony ведут себя эталонно, все цели работают как описано выше. У Xiaomi/Redmi/POCO команды bootloader и recovery работают, но стоковое рекавери сильно урезано. На их Qualcomm-моделях существует adb reboot edl, аварийный режим Emergency Download (черный экран, в диспетчере устройств появляется Qualcomm HS-USB QDLoader 9008), однако на актуальных прошивках команда обычно заблокирована и телефон просто перезагрузится в систему. На многих MediaTek-аппаратах fastboot-режим отключен вендором, adb reboot bootloader выполняется без ошибки, но девайс грузится в систему.

Samsung и Download Mode:

У Samsung нет fastboot в принципе. Роль загрузчика играет Download Mode (он же Odin Mode), и прошивают его не через fastboot, а утилитой Odin под Windows или открытой кроссплатформенной Heimdall. Вход из adb:

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

adb reboot download

Телефон покажет предупреждающий экран и предложит нажать Volume Up для продолжения. В этом режиме устройство не видят ни adb, ни fastboot, только Odin или Heimdall по фирменному протоколу.

Если система не грузится и adb недоступен, вход кнопками на актуальных моделях без кнопки Home (Galaxy S20 и новее, свежие A-серии): выключить телефон, зажать Volume Up + Volume Down и, удерживая их, воткнуть кабель, подключенный к компьютеру. Без кабеля до ПК комбинация не срабатывает, это частая причина паники "у меня сломан Download Mode". На старых моделях с физической кнопкой Home комбинация была Volume Down + Home + Power. Выход из режима, если передумали: удерживать Volume Down + Power около 7 секунд.

Главное предупреждение: прошивка любого неофициального образа через Odin пережигает eFuse Knox, на экране Download Mode появится KNOX WARRANTY VOID 0x1. Это необратимо, отвалятся Samsung Pass, Secure Folder и банковские приложения, проверяющие Knox-аттестацию. Сам по себе вход в Download Mode через adb reboot download ничего не пережигает, заходить и выходить безопасно.

adb reboot recovery на Samsung работает штатно, а вот кнопочная комбинация рекавери на моделях после 2020 года тоже требует подключенного к ПК кабеля: Volume Up + Power при воткнутом USB.

Частые ошибки:

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

adb reboot
error: device unauthorized.

Подтвердите RSA-ключ на экране устройства (глава 3). После заводского сброса ключи слетают, диалог появится заново.

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

error: device offline

Лечится переподключением кабеля, сменой порта или перезапуском сервера через adb kill-server (глава 4).

Скрипт завис на adb wait-for-device навсегда: вы ждете состояние device, а устройство ушло в bootloader или не поднялось вовсе. Оборачивайте ожидание в таймаут:

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

timeout 120 adb wait-for-device || { echo "device lost"; exit 1; }

timeout это GNU coreutils, в PowerShell та же логика делается через Start-Job и Wait-Job -Timeout, подробно разберем в главе 22.

Дальше по курсу: в главе 6 займемся навигацией по файловой системе Android, а паттерн ожидания загрузки из этой главы станет основой скриптов автоматизации в главах 22 и 24.

[debian99]

wait-for-bootloader формально есть в справке, но не дождется никогда

а как тогда в скрипте понять что девайс реально ушел в загрузчик после adb reboot bootloader? я сейчас делаю adb wait-for-disconnect и потом сразу зову fastboot, вроде работает, но не уверен что это правильный путь или костыль

[yura95]

подтверждаю про кабель на самсунгах, полчаса тупил с S21 пытаясь зайти в рекавери кнопками, думал уже что кнопка громкости сдохла. воткнул в комп и все сразу зашло. почему они так сделали кстати, есть какое то объяснение?

[aewald]

вопрос по sys.boot_completed. видел в чужих скриптах проверку dev.bootcomplete вместо него, это одно и то же или есть разница? и второй вопрос, на redmi note 13 adb reboot edl просто ребутает телефон, получается у меня все по уроку и EDL никак не получить без авторизации mi аккаунта?

[fortner]

маленькое дополнение из практики: на части прошивок adb reboot -p из под обычного шелла отрабатывает, а вот adb shell reboot -p может ругнуться на права, если adbd не перезапущен после включения отладки. лечится adb kill-server и передергиванием кабеля. ну и svc power shutdown тоже выключает, если кому надо именно из shell