Введение в Android Debug Bridge

[android_roman]

Если вы хоть раз ставили APK в обход маркета, вытаскивали лог падения приложения или сносили предустановленный мусор с нового телефона, то почти наверняка делали это через ADB. Android Debug Bridge выглядит как одна консольная утилита, но на самом деле это транспортный слой между компьютером и любым Android-устройством: телефоном, планшетом, эмулятором, приставкой на Android TV, часами на Wear OS. Этот курс про то, как выжать из него максимум. Первая глава закладывает фундамент: что это, из чего состоит и как устроено внутри.

Что такое ADB и зачем он нужен:

ADB (Android Debug Bridge) представляет собой клиент-серверную утилиту из комплекта Android SDK Platform Tools. Она дает с компьютера доступ к Unix-шеллу устройства и к набору сервисных команд поверх USB или TCP/IP. Через ADB можно ставить и удалять приложения (adb install, adb uninstall), копировать файлы в обе стороны (adb push, adb pull), читать системные логи (adb logcat), выполнять команды в шелле устройства (adb shell), снимать скриншоты и видео, эмулировать нажатия, пробрасывать порты, менять системные настройки. Каждой из этих тем посвящена отдельная глава, здесь только общая картина.

Маленький пример, чтобы пощупать. Если устройство уже подключено и отладка по USB включена (подробно настроим в главах 2 и 3), узнаем версию Android:

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

$ adb shell getprop ro.build.version.release
15

Команда getprop выполнилась не на вашем компьютере, а внутри телефона, и вернула вывод обратно в терминал. В этом весь смысл моста.

Кому это нужно. Разработчику ADB заменяет половину кнопок Android Studio и дает то, чего в студии нет. Тестировщику он открывает дорогу к автоматизации: логи, дампы, эмуляция ввода. Обычному владельцу телефона он позволяет, например, удалить неотключаемый блоатвар с какого-нибудь Redmi с маркетплейса, без root и без потери гарантии. Безопаснику он служит инструментом анализа приложений и их поведения.

Архитектура: клиент, сервер, демон:

В ADB три компонента, и понимание их ролей экономит часы при отладке проблем.

Клиент. Та самая команда adb, которую вы набираете в терминале. Каждый вызов adb devices или adb shell создает короткоживущий клиент, который передает запрос серверу и печатает результат.

Сервер (adb server). Фоновый процесс на вашем компьютере. Запускается автоматически при первом вызове любого клиента и слушает TCP-порт 5037 на 127.0.0.1. Сервер один на машину, он держит соединения со всеми устройствами и мультиплексирует запросы от всех клиентов: вашего терминала, Android Studio, scrcpy, Appium. Именно поэтому десяток инструментов может одновременно работать с одним телефоном и не мешать друг другу.

Демон adbd. Процесс на самом устройстве. Стартует, когда вы включаете отладку по USB в настройках разработчика, принимает команды от сервера и исполняет их. Работает от непривилегированного пользователя shell, поэтому далеко не все на устройстве ему доступно. На инженерных сборках userdebug и eng (и на рутованных прошивках) демон можно перезапустить с правами root командой adb root, на обычной заводской прошивке это не сработает, подробности в главе 15.

Цепочка целиком: клиент -> сервер (localhost:5037) -> транспорт (USB или сеть) -> adbd на устройстве.

Первый запуск выглядит так:

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

$ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
RF8M33QXXXX	device
emulator-5554	device

Две строки со звездочками говорят, что клиент не нашел сервер и поднял его сам. Дальше список устройств: физический Samsung по серийнику и эмулятор. Слово device в конце строки означает, что adbd ответил и устройство готово к работе. Другие состояния (unauthorized, offline, no permissions) разберем в главе 3.

С эмуляторами отдельная история. Сервер при старте сканирует нечетные порты с 5555 по 5585 на localhost. Каждый эмулятор занимает пару соседних портов: четный для консоли, нечетный для adbd. Имя emulator-5554 образовано от консольного порта, а сам adb общается с ним через порт 5555. Второй запущенный эмулятор получит имя emulator-5556, и так далее.

Сервером можно управлять руками:

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

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

Перезапуск сервера, первое средство при зависших или призрачных устройствах в списке. Обратите внимание: kill-server убивает процесс на компьютере, телефона он вообще не касается.

Если порт 5037 чем-то занят, сервер можно посадить на другой:

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

$ adb -P 5038 start-server
$ ANDROID_ADB_SERVER_PORT=5038 adb devices

Переменную окружения придется задавать для каждого клиента, иначе он пойдет на стандартный 5037.

Основные компоненты SDK Platform Tools:

ADB распространяется не сам по себе, а в составе пакета Platform Tools. Это отдельный архив, который Google обновляет независимо от остального SDK. Содержимое каталога на середину 2026 года (ветка 37.x):

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

$ ls ~/Library/Android/sdk/platform-tools
NOTICE.txt  etc1tool  hprof-conv  make_f2fs           mke2fs       source.properties
adb         fastboot  lib64       make_f2fs_casefold  mke2fs.conf  sqlite3

По пунктам. adb, герой нашего курса. fastboot, общение с загрузчиком: прошивка разделов, разблокировка bootloader, восстановление окирпиченных устройств; работает, когда Android еще не загружен и adbd недоступен, вернемся к нему в главе 27. sqlite3, консольный клиент SQLite, полезен, чтобы покопаться в базах данных приложений, вытащенных через adb pull. mke2fs и make_f2fs (плюс вариант с casefold), утилиты форматирования ext4 и F2FS, их дергает fastboot при очистке userdata, руками они нужны редко. etc1tool и hprof-conv, наследие прошлых лет: кодирование текстур ETC1 и конвертация дампов памяти для старых анализаторов. Утилиты systrace в пакете больше нет, ее убрали еще в версии 33.0.1, профилирование переехало в Perfetto и профайлер Android Studio.

Проверить свою версию:

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

$ adb version
Android Debug Bridge version 1.0.41
Version 37.0.0-14910828
Installed as /opt/homebrew/bin/adb
Running on Darwin 25.5.0 (arm64)

Здесь два разных номера. 1.0.41, версия протокола, она не меняется годами. 37.0.0, версия самого пакета Platform Tools, вот за ней и нужно следить. Старый adb может некорректно работать с устройствами на Android 15 и 16, поэтому пакет обновляют отдельно и часто.

Связь с Android Studio и экосистемой разработки:

Android Studio не содержит никакой собственной магии для общения с устройством. Кнопка Run, вкладка Logcat, Device Explorer, зеркалирование экрана в Running Devices, все это обертки над тем же самым adb сервером. Студия ставит Platform Tools через свой SDK Manager в стандартный путь:

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

Windows:  %LOCALAPPDATA%\Android\Sdk\platform-tools
macOS:    ~/Library/Android/sdk/platform-tools
Linux:    ~/Android/Sdk/platform-tools

Отсюда типичная грабля: на машине живут два разных adb, например один из Homebrew, второй из студии, а то и совсем древний из комплекта эмулятора Nox или BlueStacks. Клиент и сервер разных версий при встрече убивают друг друга:

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

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

Само по себе это не фатально, но когда два инструмента по кругу перезапускают сервер каждый своей версией, устройства будут вечно отваливаться. Лечение одно: оставить единственный актуальный adb и убедиться, что и PATH, и Android Studio смотрят на него. Как это сделать аккуратно, покажу в главе 2.

Вокруг ADB построена целая экосистема. scrcpy зеркалит экран телефона через adb. Flutter и React Native деплоят приложения через adb. Appium, UiAutomator2 и Maestro гоняют автотесты через adb. Облачные фермы устройств вроде Firebase Test Lab внутри тоже разговаривают по протоколу adb. Освоив его напрямую, вы понимаете, что происходит под капотом у всех этих инструментов, и можете чинить их, когда они ломаются.

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

adb: command not found или 'adb' is not recognized. Утилита не прописана в PATH. Решение в главе 2, временно можно запускать по полному пути к platform-tools.

device unauthorized в выводе adb devices. На телефоне не принят RSA-отпечаток компьютера. Разблокируйте экран и нажмите Разрешить в появившемся диалоге. Если диалог не показался, в настройках разработчика выберите пункт отзыва доступа для USB-отладки и переподключите кабель.

error: could not install *smartsocket* listener: Address already in use. Порт 5037 занят чужим процессом, чаще всего это adb из эмуляторов Nox, LDPlayer, BlueStacks или фирменный софт производителя вроде HiSuite. Найти виновника:

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

# macOS и Linux
$ lsof -nP -iTCP:5037 -sTCP:LISTEN
# Windows
> netstat -ano | findstr 5037

Дальше либо завершить чужой процесс, либо увести свой сервер на другой порт через ANDROID_ADB_SERVER_PORT.

Пустой список в adb devices при подключенном телефоне. Обычно не включена отладка по USB либо попался кабель только для зарядки, без линий данных. Полный чеклист подключения будет в главе 3.

adbd cannot run as root in production builds. Вы выполнили adb root на обычной заводской прошивке. Это нормальное поведение, а не поломка, root-доступ обсудим в главе 15.

В следующей главе поставим Platform Tools на Windows, macOS и Linux, пропишем PATH, разберемся с драйверами и правилами udev, чтобы все дальнейшие примеры курса запускались без бубна.

[VimDev]

Сервер один на машину, он держит соединения со всеми устройствами и мультиплексирует запросы от всех клиентов

а если сервер слушает только 127.0.0.1, есть легальный способ дергать его с другой машины? у меня телефон воткнут в домашний сервак, хочу с ноута команды слать. ssh-туннель на 5037 прокатит или там еще какая-то привязка?

[vault_andy]

подтверждаю историю про Address already in use. поставил LDPlayer и началось: студия теряет телефон каждые пару минут. оказалось эмулятор тащит свой adb.exe версии 1.0.39 и они с системным по очереди друг друга прибивают, ровно как в уроке. вылечил заменой adb.exe в папке LDPlayer на свежий из platform-tools, с тех пор живут мирно

[fedya42]

не понял момент с портами эмуляторов. если сервер сканирует только 5555-5585, выходит больше 16 эмуляторов одновременно не увидеть? или для остальных надо руками adb connect на нужный порт делать?

[rickjan]

etc1tool и hprof-conv, наследие прошлых лет

забавно что их до сих пор не выпилили. systrace убрали, dmtracedump когда-то тоже лежал в platform-tools и его убрали, а эти двое живут. кто-нибудь вообще открывал hprof-conv после того как Studio научилась сама читать дампы?