Системные дампы и диагностика (dumpsys)

[android_roman]

В главе 8 вы научились читать поток событий через logcat. Это история: что происходило. dumpsys отвечает на другой вопрос: что происходит прямо сейчас. Почти каждый системный сервис Android (на Android 14/15 их больше двух сотен) умеет по запросу выгружать своё внутреннее состояние, и dumpsys просто дергает этот механизм через Binder. На выходе текст, иногда мегабайты текста, но в нём есть ответы, которые из логов не вытащить: какая Activity сейчас на экране, кому отдан фокус ввода, сколько памяти съел процесс, почему не приходят пуши.

Обзор dumpsys и список сервисов:

Полный список того, что можно дампить, выдаёт флаг -l:

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

$ adb shell dumpsys -l
Currently running services:
  SurfaceFlinger
  accessibility
  activity
  alarm
  appops
  audio
  battery
  batterystats
  connectivity
  ...
  wifi
  window

Запуск dumpsys вообще без аргументов дампит ВСЕ сервисы подряд. Это минуты работы и десятки мегабайт, в консоли такое не читают, только в файл:

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

adb shell dumpsys > full_dump.txt
adb shell dumpsys --skip meminfo,cpuinfo > dump_lite.txt

У каждого сервиса свой таймаут на дамп, по умолчанию 10 секунд. Тяжёлые сервисы вроде wifi или batterystats на загруженном устройстве в него иногда не укладываются, тогда поможет -t:

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

adb shell dumpsys -t 30 wifi

Всё, что идёт после имени сервиса, передаётся самому сервису как аргументы. Поэтому у dumpsys activity и dumpsys package такие богатые подкоманды, это не флаги dumpsys, это API конкретного сервиса.

activity: стеки, задачи, текущий экран:

Сервис activity знает всё про Activity, задачи, процессы, сервисы и broadcast-очереди. Самый частый практический вопрос: что сейчас на экране. Ответ:

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

$ adb shell dumpsys activity activities | grep topResumedActivity
  topResumedActivity=ActivityRecord{e2a1b4d u0 com.android.settings/.Settings t127}

Здесь com.android.settings/.Settings это точное имя компонента, оно вам понадобится в главе 12 для am start. На старых устройствах (до Android 10) строка называлась mResumedActivity, поэтому в скриптах надёжнее grep -E "topResumedActivity|mResumedActivity".

Чуть выше в том же выводе видны задачи (tasks) и их стеки:

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

* Task{f3c9e21 #127 type=standard A=10123:com.android.settings U=0 visible=true mode=fullscreen}
    * Hist #1: ActivityRecord{e2a1b4d u0 com.android.settings/.Settings t127}
    * Hist #0: ActivityRecord{91c44a0 u0 com.android.settings/.SubSettings t127}

Hist это back stack задачи: нажатие "назад" снимет верхнюю запись. Полезные подкоманды: dumpsys activity top (полное состояние верхней Activity вплоть до иерархии View), dumpsys activity recents (недавние задачи), dumpsys activity broadcasts (очереди рассылок), dumpsys activity processes (LRU-список процессов и их oom_adj).

window: фокус, размеры, политика:

WindowManager отвечает за окна, и его дамп решает классическую задачу автотестера: кто держит фокус ввода. Это не всегда та же сущность, что верхняя Activity (диалог, IME, системный оверлей):

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

$ adb shell dumpsys window windows | grep -E "mCurrentFocus|mFocusedApp"
  mCurrentFocus=Window{a4f2c1e u0 com.android.settings/com.android.settings.Settings}
  mFocusedApp=ActivityRecord{e2a1b4d u0 com.android.settings/.Settings t127}

Если mCurrentFocus=null, а тапы через input (глава 11) уходят в пустоту, причина обычно тут: экран погашен или идёт анимация перехода. Размеры и плотность дисплея:

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

$ adb shell dumpsys window displays | grep -E "init|cur"
    init=1080x2400 420dpi cur=1080x2400 app=1080x2236 rng=1080x1020-2400x2340

init это родное разрешение, cur текущее (могло быть изменено), app то, что доступно приложениям за вычетом системных панелей. Для изменения этих значений есть команда wm, ей посвящена глава 13. Раздел dumpsys window policy показывает состояние keyguard, ориентацию и политику поворота, пригодится, когда тест падает из-за внезапно заблокированного экрана.

package: версии и разрешения:

PackageManager хранит досье на каждый установленный пакет. Версия приложения без выкачивания APK:

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

$ adb shell dumpsys package org.telegram.messenger | grep -E "versionName|versionCode"
    versionCode=42150 minSdk=21 targetSdk=34
    versionName=11.9.0

В полном дампе по пакету смотрите: userId (понадобится ниже для netstats), firstInstallTime и lastUpdateTime, codePath, а главное, два блока разрешений. install permissions выданы при установке, runtime permissions запрашиваются в рантайме, и у каждого видно состояние:

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

    runtime permissions:
      android.permission.POST_NOTIFICATIONS: granted=true
      android.permission.CAMERA: granted=false
      android.permission.RECORD_AUDIO: granted=true

Это быстрейший способ проверить, что pm grant из главы 7 реально сработал. Без аргументов dumpsys package выгружает данные обо всех пакетах сразу плюс таблицы разрешений, это сотни тысяч строк, всегда уточняйте пакет.

battery: заряд и health:

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

$ adb shell dumpsys battery
Current Battery Service state:
  AC powered: false
  USB powered: true
  Wireless powered: false
  Max charging current: 1500000
  Charge counter: 3187000
  status: 2
  health: 2
  level: 87
  scale: 100
  voltage: 4312
  temperature: 304
  technology: Li-ion

Расшифровка неочевидных полей: status 2 значит "заряжается" (1 unknown, 3 разряжается, 4 не заряжается, 5 заряжен), health 2 значит "good" (3 перегрев, 4 убитая, 7 переохлаждение). voltage в милливольтах, temperature в десятых долях градуса, то есть 304 это 30.4 C. Max charging current в микроамперах.

Сервис умеет подменять состояние, root не нужен. Так тестируют поведение приложения при низком заряде:

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

adb shell dumpsys battery unplug
adb shell dumpsys battery set level 5
adb shell dumpsys battery set status 3

unplug обязателен первым шагом, иначе реальный кабель будет перетирать ваши значения. Физически зарядка при этом продолжается, врёт только Battery Service. Закончили, верните всё как было:

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

adb shell dumpsys battery reset

Забытый reset это классика: телефон до перезагрузки показывает 5% и панические уведомления.

cpuinfo, meminfo, procstats:

Три сервиса дают три взгляда на ресурсы. cpuinfo это срез нагрузки за последние десятки секунд:

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

$ adb shell dumpsys cpuinfo
Load: 7.12 / 6.98 / 6.51
CPU usage from 31992ms to 7081ms ago (2026-06-12 14:02:11 to 2026-06-12 14:02:36):
  42% 1213/system_server: 28% user + 13% kernel / faults: 1422 minor 4 major
  18% 2841/com.android.systemui: 14% user + 4.1% kernel
  9.6% 14233/org.telegram.messenger: 7.2% user + 2.4% kernel

meminfo с именем пакета показывает память конкретного процесса:

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

$ adb shell dumpsys meminfo org.telegram.messenger
** MEMINFO in pid 14233 [org.telegram.messenger] **
                   Pss  Private  Private  SwapPss      Rss
                 Total    Dirty    Clean    Dirty    Total
                ------   ------   ------   ------   ------
  Native Heap    98342    98256        0     1240   101332
  Dalvik Heap    12404    12320        0      180    18230
...
       TOTAL    287654   231120    18234     4820   412110

 App Summary
   Java Heap:        24620
   Native Heap:      98342
   Graphics:         71240

Главная метрика TOTAL PSS: доля памяти процесса с честным учётом разделяемых страниц. Рост Native Heap между двумя замерами при одинаковом сценарии это типичный признак утечки в нативном коде или в графике. meminfo без аргументов даёт сводку по всем процессам плюс Free RAM и Lost RAM по устройству.

procstats добавляет измерение времени: сколько процент времени процесс жил в памяти и сколько занимал:

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

$ adb shell dumpsys procstats --hours 3
  * com.android.systemui / u0a142 / v34:
           TOTAL: 100% (182MB-195MB-204MB/148MB-160MB-167MB over 12)
      Persistent: 100% (...)

Формат: процент времени в памяти, затем min-avg-max PSS/USS по выборкам. Приложение, которое висит в TOTAL 100% без видимых причин, кандидат на разбор в главе 10, где мы займёмся производительностью всерьёз.

Сеть: netstats, connectivity, wifi:

netstats считает трафик по UID. Сначала узнаём UID пакета, потом ищем его в статистике:

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

$ adb shell dumpsys package org.telegram.messenger | grep userId
    userId=10234
$ adb shell dumpsys netstats | grep -A 3 "uid=10234"
  ident=[{type=WIFI, metered=false}] uid=10234 set=DEFAULT tag=0x0
    st=1749700800 rb=18734231 rp=15234 tb=2345112 tp=8123

rb/tb это принятые и отправленные байты, rp/tp пакеты, st метка времени бакета. connectivity отвечает на вопрос "есть ли вообще сеть и валидна ли она":

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

$ adb shell dumpsys connectivity | grep -m 5 -E "Active default network|Capabilities"
Active default network: 102
  Capabilities: NET_CAPABILITY_NOT_METERED&NET_CAPABILITY_INTERNET&NET_CAPABILITY_VALIDATED ...

Если NET_CAPABILITY_VALIDATED в списке нет, Android считает сеть без выхода в интернет (не прошла проверка captive portal), и приложения ведут себя как в офлайне, хотя Wi-Fi подключён. Частая ситуация в гостиницах и на вокзальных сетях. Детали радиочасти даёт сервис wifi:

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

$ adb shell dumpsys wifi | grep "mWifiInfo"
mWifiInfo SSID: "Rostelecom_2845", BSSID: a4:2b:8c:11:7e:90, MAC: 02:00:00:00:00:00, IP: /192.168.0.103, Supplicant state: COMPLETED, Wi-Fi standard: 5, RSSI: -54, Link speed: 433Mbps, Frequency: 5180MHz

RSSI -54 это отличный сигнал, хуже -75 уже проблемы. MAC вида 02:00:00:00:00:00 не ошибка, а заглушка анонимизации в дампе.

notification:

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

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

$ adb shell dumpsys notification | grep -A 2 "org.telegram.messenger"
  NotificationChannel{mId='messages', mName=Messages, mImportance=4, ...}
  NotificationChannel{mId='silent', mName=Silent, mImportance=0, ...}

mImportance=0 значит канал заблокирован пользователем, 4 это high с heads-up. Содержимое уведомлений в обычном дампе вырезано из соображений приватности, флаг --noredact его раскрывает:

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

$ adb shell dumpsys notification --noredact | grep -A 12 "pkg=org.telegram.messenger"
  NotificationRecord(0x8f12aa3: pkg=org.telegram.messenger user=UserHandle{0} id=12)
      channel id=messages
      extras={
        android.title=String (Дима)
        android.text=String (го завтра созвон в 11)
      }

Этим активно пользуются в автотестах: пришёл ли пуш с нужным текстом, проверяется одним grep без UI Automator.

adb bugreport: полный отчёт:

Когда непонятно, куда смотреть, снимают всё сразу. bugreport это архив с дампами всех сервисов, полным logcat, dmesg, ANR-трейсами и статистикой батареи:

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

$ adb bugreport bugreport-pixel8-2026-06-12.zip
/data/user_de/0/com.android.shell/files/bugreports/bugreport-...zip: 1 file pulled
Bug report copied to bugreport-pixel8-2026-06-12.zip

Команда выполняется на хосте, не в shell, и занимает от двух до пяти минут, архив выходит на 30-100 МБ. Внутри главный файл bugreport-*.txt (это, по сути, dumpsys всех сервисов, сшитый в один документ), каталог FS со срезами файловой системы и anr/ с трейсами зависаний. На Android 6 и старше adb bugreport выводил плоский текст в stdout, на всём современном (Android 7+) по умолчанию zip. Прогресс генерации можно наблюдать и изнутри устройства:

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

adb shell bugreportz -p

Именно bugreport скармливают Battery Historian для анализа расхода батареи, и именно его просят приложить инженеры Google и вендоров в баг-трекерах. Не выкладывайте его публично не глядя: внутри серийники, SSID, тексты уведомлений и список всего установленного.

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

Первая по популярности, потерянный shell:

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

$ adb dumpsys battery
adb: unknown command dumpsys

dumpsys это команда внутри устройства, правильно adb shell dumpsys. Вторая, опечатка или отсутствующий на устройстве сервис:

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

$ adb shell dumpsys batery
Can't find service: batery

Сверяйтесь с dumpsys -l, набор сервисов отличается между версиями Android и вендорами. Третья, meminfo по незапущенному приложению:

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

$ adb shell dumpsys meminfo com.example.app
No process found for: com.example.app

Это не "приложение не установлено", это "процесс сейчас не жив". Запустите его или проверьте установку через pm list packages. Четвёртая, Windows: в cmd и PowerShell нет grep, используйте findstr (adb shell dumpsys battery | findstr level) или ставьте Git Bash, потому что контекстных флагов -A и -B у findstr нет. Пятая, обрезанный дамп с пометкой Timeout в выводе, лечится adb shell dumpsys -t 30 имя_сервиса. И шестая, уже упомянутая: после игр с dumpsys battery set всегда делайте reset, иначе устройство останется жить в выдуманном вами мире до перезагрузки.

В следующей главе мы возьмём cpuinfo, meminfo и их друзей в работу: будем мерить производительность в динамике, а не по разовым срезам.

[hommel]

unplug обязателен первым шагом, иначе реальный кабель будет перетирать ваши значения

то есть я правильно понял, что физически телефон продолжает заряжаться, просто система думает что кабель выдернут? а то сделал unplug, уровень все равно потихоньку растет, уже думал что-то сломал. и да, подтверждаю про забытый reset, полдня ходил с "5%" и не мог понять почему телефон не помер до сих пор

[elixir_pro]

а если procstats нужен за сутки, --hours 24 сработает? или там история только часа на 3-4 хранится в памяти? хочу отловить приложение, которое ночью держит процесс и жрет батарею

[wbarrich]

по поводу findstr на винде. он реально убогий, -A и -B нет, регулярки кривые. поставил git bash и просто гоняю adb оттуда, все примеры из урока работают один в один. еще вариант wsl, но для adb придется пробрасывать usb или коннектиться по tcp на adb сервер винды

[regexenjoyer]

маленькое дополнение про эмулятор: там dumpsys battery по умолчанию всегда показывает AC powered: true и level 100, это нормально, железной батареи же нет. set level и unplug работают так же как на живом устройстве, так что low battery сценарии на эмуляторе гонять можно