Перейти на PRO

Что такое логи ADB и как с ними работать?

Тип вопроса: Мобильное тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Логи ADB — это системные журналы Android, доступные для просмотра и анализа через инструмент Android Debug Bridge (ADB). Они являются основным источником информации для отладки приложений и системы.

Основные буферы логов (log buffers):

  • main: Основной журнал, куда пишут большинство приложений (уровни V, D, I, W, E).
  • system: Сообщения от компонентов Android OS.
  • events: Системные события в специальном бинарном формате.
  • crash: Логи падений (крашей).
  • kernel: Логи ядра Linux (доступны через adb shell dmesg).

Базовые команды adb logcat:

# Вывести логи в реальном времени
adb logcat

# Вывести логи с метками времени и фильтром по тегу/уровню
adb logcat -v time *:I

# Сохранить логи в файл
adb logcat -v time > android_log.txt

# Очистить буфер логов
adb logcat -c

# Вывести логи только для определенного буфера (например, system)
adb logcat -b system

# Фильтрация по тегу (TAG) и уровню (например, только ошибки для тега "MyApp")
adb logcat MyApp:E *:S
# *:S ("silence") заглушает все остальные теги.

Практическое применение в тестировании:

  1. Отладка падений (Crashes): Поиск FATAL EXCEPTION и стека вызовов (stack trace).
  2. Анализ ANR (Application Not Responding): Поиск в логах ключевых строк ANR in.
  3. Мониторинг собственных сообщений: Добавление логов в код приложения (через Log.d(), Log.e()) и их фильтрация по уникальному тегу.
  4. Сбор логов для баг-репорта: Сохранение полного лога в момент воспроизведения дефекта.

Ответ 18+ 🔞

Слушай, ну вот сидишь ты, такой весь в себе, пишешь приложение, а оно, сука, не работает. Или виснет, или вылетает, или вообще молчит как партизан на допросе. И что делать? Глазами код сверлить? Так можно до пенсии досидеть, блядь.

А выход-то есть, и он называется ADB logcat. Это, грубо говоря, внутренний дневник твоего андроид-устройства или эмулятора, куда записывается вообще всё: от системных икоток до подробных отчётов твоего приложения о том, как оно сходило в туалет. Главный источник правды, когда всё пошло по пизде.

Где эта правда живёт? В буферах, блядь! У системы не одна папка, а целых несколько ящиков, куда она складывает разные типы записок:

  • main: Главный ящик. Сюда стекается почти вся хуйня от приложений — их дебаг-сообщения, инфо, предупреждения и крики «ЁБАНЫЙ В РОТ!» в виде ошибок (ERROR).
  • system: А это уже записки от самой системы Android. Тут свои внутренние разборки.
  • events: Специальный зашифрованный (бинарный) журнал системных событий. Для своих.
  • crash: Ну тут понятно — отчёты о том, кто, где и как накрылся медным тазом.
  • kernel: А это уже глубокие подвалы — логи ядра Линукса. Через adb shell dmesg смотреть.

Ну и как этим богатством пользоваться, спросишь ты? Да элементарно, Ватсон! Открываешь терминал и начинаешь колдовать.

# Просто смотреть, как льётся поток сознания устройства в реальном времени. Часто — сплошная белиберда.
adb logcat

# Включить метки времени и отфильтровать шум, оставив только уровень INFO и выше. Уже чуть читаемее.
adb logcat -v time *:I

# Сохранить весь этот поток сознания в файл, чтобы потом не спеша разобрать, кто виноват.
adb logcat -v time > android_log.txt

# Очистить буферы, чтобы начать с чистого листа. Как перед важным экспериментом.
adb logcat -c

# Смотреть не в общую помойку, а в конкретный ящик. Например, только системные сообщения.
adb logcat -b system

# А это, блядь, магия! Смотришь ТОЛЬКО сообщения с твоим тегом (TAG) и уровнем ERROR. Всё остальное заглушается (*:S).
adb logcat MyApp:E *:S

А где на практике применить-то, кроме как пялиться в консоль?

  1. Когда приложение БАХ и падает. Не надо гадать. Ищешь в логах FATAL EXCEPTION и читаешь следом stack trace — подробную историю о том, в каком именно методе всё пошло не так. Это как найти записку «виноват Петрович» на месте преступления.
  2. Когда приложение зависло и система пишет «Приложение не отвечает» (ANR). Быстро ищешь в логах ANR in — система обычно любезно оставляет в этом месте подробный отчёт, что делал главный поток, пока его ебали асинхронные задачи.
  3. Чтобы следить за своим приложением. Втыкаешь в код вызовы Log.d("MY_TAG", "Дошёл до сюда, значение = " + value). Потом в логах фильтруешь по MY_TAG и видишь, как твой код на самом деле выполняется. Проще пареной репы.
  4. Собрать доказательства для баг-репорта. Воспроизвёл баг — сразу же делаешь adb logcat -v time > bug_report.txt. Отдаёшь этот файл разработчику или самому себе, и все улики на месте. Никто не отвертится, епта.

Короче, logcat — это не просто команда, это твои глаза и уши внутри устройства. Без него ты как слепой котёнок в тёмной комнате, где все стены обмазаны хуём. Не будь слепым котёнком.

© ХакСобесов, 2026
support@hacksobesov.com