Отладка самого ADB и устранение неполадок

[android_roman]

За 28 глав вы научились выжимать из adb всё, от logcat до скриптов автоматизации и работы с Wear OS. Финальная глава про то, что делать, когда ломается сам инструмент. Разберём трассировку, типовые ошибки подключения, чистую переустановку и конфликты с чужим софтом, который тянет USB-шину на себя.

Как устроена цепочка и где она рвётся:

Напомню схему из главы 4: клиент adb (то, что вы запускаете в терминале), сервер adb (демон на TCP-порту 5037 вашей машины) и adbd (демон на устройстве). Любая неполадка живёт в одном из трёх звеньев или на стыке. Первый диагностический шаг всегда один и тот же:

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

adb version
adb devices -l

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

Android Debug Bridge version 1.0.41
Version 36.0.0-13206524
Installed as /opt/platform-tools/adb

List of devices attached
RZ8T40KQXHE   device usb:1-2 product:o1sxxx model:SM_S921B device:o1s transport_id:3

Если в колонке состояния не device, а offline, unauthorized или no permissions, переходите к разбору ошибок ниже. Если устройства нет вообще, проблема уровнем ниже: кабель, драйвер, порт.

Подробное логирование: ADB_TRACE:

Переменная окружения ADB_TRACE включает трассировку. Поддерживаемые значения: all (или 1), adb, sockets, packets, rwx, usb, sync, sysdeps, transport, jdwp, services, auth, fdevent, shell. Перечислять можно через запятую.

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

# Linux/macOS: трассируем только USB и транспорт
ADB_TRACE=usb,transport adb devices

# Windows (cmd)
set ADB_TRACE=all
adb devices

# Windows (PowerShell)
$env:ADB_TRACE="all"
adb devices

Клиент пишет трассировку в stderr, строки выглядят так:

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

adb D 06-11 14:02:11 48211 48211 adb_client.cpp:160: _adb_connect: host:version
adb D 06-11 14:02:11 48211 48211 adb_io.cpp:107: writex: fd=3 len=18 ...
adb D 06-11 14:02:11 48211 48211 adb_client.cpp:392: adb_query: host:devices-l

Тонкость, на которой спотыкаются: переменная действует только на процесс, который её видит. Если сервер уже запущен без неё, трассировки сервера вы не получите. Вариант первый: перезапустить сервер с переменной, тогда его лог уйдёт в файл (Linux/macOS: adb.<uid>.log во временном каталоге, например /tmp/adb.1000.log; Windows: %TEMP%\adb.log, туда сервер пишет всегда):

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

adb kill-server
ADB_TRACE=all adb start-server
tail -f /tmp/adb.1000.log

Вариант второй, удобнее для живой отладки: запустить сервер в форграунде, лог польётся прямо в терминал:

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

adb kill-server
ADB_TRACE=all adb server nodaemon

Отдельно про USB-бэкенд. Свежие platform-tools умеют два бэкенда, встроенный и libusb, и дефолт зависит от ОС и версии. Узнать текущий и переключить:

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

adb host-features
shell_v2,cmd,stat_v2,ls_v2,apex,abb,abb_exec,sendrecv_v2,openscreen_mdns,push_sync,libusb

adb kill-server
ADB_LIBUSB=0 adb start-server

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

Разбор ошибки device unauthorized:

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

List of devices attached
RZ8T40KQXHE   unauthorized usb:1-2 transport_id:4

Авторизация в adb построена на RSA-ключах (глава 25). Пара клиента лежит в ~/.android/adbkey и adbkey.pub, доверенные публичные ключи на устройстве хранятся в /data/misc/adb/adb_keys (чтение только с root). unauthorized означает, что устройство ваш ключ не знает, а запрос вы не подтвердили. Порядок действий:

1. Разблокируйте экран. Диалог "Разрешить отладку по USB?" на залоченном устройстве не появляется.
2. Передёрните кабель, поставьте галочку "Всегда разрешать с этого компьютера".
3. Диалога нет совсем: на устройстве в разделе для разработчиков нажмите "Отозвать доступ для отладки по USB", выключите и включите отладку, переподключите кабель.
4. Не помогло, пересоздайте ключи на хосте:

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

adb kill-server
rm ~/.android/adbkey ~/.android/adbkey.pub
adb start-server
adb devices

Новая пара сгенерируется автоматически, устройство покажет свежий диалог. Если в конторе используются вендорские ключи, проверьте переменную ADB_VENDOR_KEYS, протухший путь в ней даёт вечный unauthorized.

Разбор ошибки offline:

Сервер видит транспорт, но рукопожатие с adbd не завершилось или связь протухла. Классика: старый adb на хосте против Android 14/15, зависший adbd, оборванное Wi-Fi-подключение из главы 20. Лечение по нарастающей:

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

adb reconnect            # передёрнуть соединение со стороны хоста
adb reconnect offline    # переподключить только offline-устройства
adb reconnect device     # сброс со стороны устройства
adb kill-server && adb devices

Дальше физика: другой кабель, другой порт, выключить и включить отладку на телефоне, в крайнем случае перезагрузить его. Для беспроводных подключений offline после смены сети нормален, просто выполните adb connect заново. И обновите platform-tools: комплекты старше пары лет с современными прошивками регулярно дают offline и кривую авторизацию.

Разбор ошибки no permissions:

Чисто линуксовая история, процессу adb не хватает прав на файл устройства в /dev/bus/usb:

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

List of devices attached
????????????   no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]

Решается правилом udev. Сначала узнайте VendorID:

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

lsusb
Bus 001 Device 014: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device

18d1 это Google, 04e8 Samsung, 2717 Xiaomi. Создайте правило и перечитайте конфигурацию:

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

sudo tee /etc/udev/rules.d/51-android.rules <<'EOF'
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0660", GROUP="plugdev", TAG+="uaccess"
EOF
sudo udevadm control --reload-rules
sudo udevadm trigger
sudo usermod -aG plugdev $USER

После usermod перелогиньтесь, затем adb kill-server и передёрните кабель. Запускать adb через sudo, как советуют на форумах, плохая идея: сервер от root создаст ключи в /root/.android и потом будет конфликтовать с вашим пользовательским сервером.

Разбор ошибки device not found (список пуст):

Устройство не доехало даже до сервера. Проверяйте снизу вверх. Кабель: зарядные шнуры без линий данных лидируют по потраченным часам, телефон заряжается, но в системе не появляется. Режим USB на телефоне: в шторке выберите "Передача файлов" вместо "Только зарядка". Отладка по USB вообще включена (глава 3). И сама шина:

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

# Linux: видит ли ядро устройство в момент подключения
dmesg -w
[ 8841.120334] usb 1-2: new high-speed USB device number 14 using xhci_hcd
[ 8841.270112] usb 1-2: Product: SM-S921B

# macOS
system_profiler SPUSBDataType

Ядро видит, а adb нет: это либо права (выше), либо выключенная отладка, либо бэкенд (поиграйте с ADB_LIBUSB).

Сброс и переустановка компонентов ADB:

Шаг 1, чистый перезапуск сервера:

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

adb kill-server
adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully

Шаг 2, найти зоопарк из нескольких adb. Это причина знаменитой ошибки про несовпадение версий, когда клиент и сервер из разных комплектов перезапускают друг друга по кругу:

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

adb server version (39) doesn't match this client (41); killing...

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

# Linux/macOS
which -a adb
/opt/platform-tools/adb
/home/user/Android/Sdk/platform-tools/adb

# Windows
where adb
C:\platform-tools\adb.exe
C:\Android\sdk\platform-tools\adb.exe

Оставьте один свежий комплект и почистите PATH. Сервер перед этим убейте, иначе старый бинарь продолжит висеть на 5037.

Шаг 3, выяснить, кто занял порт 5037:

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

# Linux/macOS
lsof -i :5037

# Windows
netstat -ano | findstr 5037
TCP    127.0.0.1:5037    0.0.0.0:0    LISTENING    9120
tasklist | findstr 9120

Чужой процесс прибейте. Если порт отдать нельзя, уведите свой сервер на другой, переменная действует и на клиент, и на сервер:

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

export ANDROID_ADB_SERVER_PORT=5038
adb start-server

Шаг 4, переустановка. Platform-tools не требует инсталлятора: adb kill-server, скачайте свежий zip со страницы platform-tools на developer.android.com, распакуйте поверх старого каталога, проверьте adb version. Либо через sdkmanager:

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

sdkmanager "platform-tools"

Ключи в ~/.android переустановка не трогает, удалять их нужно только при проблемах с авторизацией.

Драйверы, USB-порты и конкурирующие сервисы:

Windows, единственная платформа, где adb нужен драйвер. Здоровое устройство видно в диспетчере устройств как "Android Composite ADB Interface" (иногда с префиксом вендора). Жёлтый треугольник или "Неизвестное устройство" значит, что драйвера нет или встал не тот. Для Pixel и большинства китайских брендов подходит Google USB Driver, ставится через SDK Manager или вручную через "Обновить драйвер" с указанием папки usb_driver. Samsung требует свой драйвер, он приезжает вместе со Smart Switch.

Порты и кабели. Передние порты корпуса ПК, хабы в мониторах и дешёвые разветвители дают именно offline и обрывы посреди adb push больших файлов. Втыкайте в порт на материнской плате, со старыми устройствами иногда помогает уход с USB 3.x на USB 2.0.

Конкурирующие сервисы, классика жанра. HTC Sync Manager и Samsung Kies (сегодня его роль играет Smart Switch) держат собственный adb-сервер или монопольно захватывают USB-интерфейс телефона. Симптомы: их софт устройство видит, а adb devices пуст, либо ваш сервер регулярно умирает с version mismatch. Туда же эмуляторы и их обвязка: Nox возит nox_adb.exe, BlueStacks возит HD-Adb.exe, у Genymotion свой комплект. Лечение:

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

:: Windows: выгрузить всех претендентов и поднять свой сервер
taskkill /F /IM adb.exe
taskkill /F /IM nox_adb.exe
taskkill /F /IM HD-Adb.exe
adb start-server

В долгую: снесите синхронизаторы, которыми не пользуетесь, уберите их из автозагрузки, а в Genymotion в настройках укажите путь к своему системному SDK, чтобы все жили на одной версии adb. macOS и Linux от драйверов избавлены, но второй adb из Homebrew рядом с adb из Android Studio устраивает ровно тот же цирк, лечится через which -a.

Финальный чек-лист:

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

adb version                        # версия клиента и путь к бинарю
adb kill-server && adb devices     # чистый перезапуск сервера
adb devices -l                     # состояние: device/offline/unauthorized
which -a adb                       # нет ли второго adb в PATH
ADB_TRACE=all adb server nodaemon  # когда непонятно, читаем трассировку

Девять из десяти проблем закрывает связка: свежие platform-tools, единственный adb в PATH, нормальный кабель, порт на материнке. Десятую решает чтение трассировки, и теперь вы умеете её включать. На этом курс закончен. Инструмент разобран до винтика, осталось применять.

[herrman]

Новая пара сгенерируется автоматически, устройство покажет свежий диалог.

а если этим ключом авторизовано штук 15 девайсов на тестовом стенде, после rm adbkey все 15 заново руками подтверждать? или можно старый adbkey.pub через root докинуть обратно в /data/misc/adb/adb_keys и не мучиться?

[Bombers]

а на стороне телефона трассировку adbd как-то включить можно? ADB_TRACE же чисто про хост. интересно куда копать, когда по трейсу хоста все ок, а девайс сам рвет коннект каждые пару минут

[vapido]

подтверждаю про передние порты. два дня ловил offline на galaxy s23 при push файлов больше гига, грешил на кабель, оказался хаб в мониторе. и добавлю в список конкурентов vysor, он тоже возит свой adb и тихо садится на 5037, убрал из автозапуска и version mismatch пропал

[proxmox777]

про plugdev уточню. на свежих федорах и арчах этой группы из коробки вообще нет, и с GROUP="plugdev" правило молча не работает, пока группу не создашь руками. на системах с systemd достаточно TAG+="uaccess", права раздаются залогиненному юзеру автоматом, так что кусок с usermod там лишний