Как читать вывод "dbsys shell adb shell"

Я борюсь с правильной настройкой тревоги и пониманием механизма отмены и перенастройки аварийных сигналов.

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

Я понимаю, что я задаю много объяснений здесь, поэтому, если кто-нибудь бросит ссылку с подробным объяснением "adb shell dumpsys alarm", я буду очень благодарен.

Итак, вот вопросы:

  • Ожидающие пакеты аварий: 23

    а. Является ли "23" числом активных, запланированных аварийных сигналов в настоящее время?

  • Пакет {4293d3a8 num = 1 start = 1369361 end = 1407261}:
      RTС# 0: Тревога {4293d358 тип 1 com.android.chrome}
      type = 1 whenElapsed = 1369361, когда = + 19s304ms window = -1 repeatInterval = 0 count = 0
      операция = PendingIntent {429e4500: PendingIntentRecord {429dbbc8 com.android.chrome broadcastIntent}}

    а. Что такое 'num = 1', 'start = 1369361' и 'end = 1407261'?
    б. Я полагаю, что "RTC" означает сигнализацию RTC.
    с. Что означает "# 0"?
    д. Что означает "тип = 1"?
    е. Is 'when = + 19s304ms' означает, что будильник будет срабатывать через 19 секунд?
    е. Что означает "окно = -1"?
    г. Is 'repeatInterval = 0' означает, что это не повторяющийся сигнал тревоги?
    час Is 'count = 0' означает, что этот сигнал не был отложен из-за состояния ожидания телефона?
    я. 'operation = PendingIntent {...}' означает ожидающее намерение, которое будет вызвано сигналом тревоги, я полагаю.

  • Счетчик трансляции: 0

    а. Что это?

  • Верхние аварийные сигналы:

    а. Что это?

  • + 47s271ms работает, 0 пробуждений, 2 аварийных сигнала: com.username.weatherinfo
      акт = com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION
        CMP = {com.username.weatherinfo/com.username.receivers.CyclicWeatherUpdater}

    а. Is '+ 47s271ms' означает, что этот сигнал будет срабатывать через 47 секунд?
    б. Что такое "0 пробуждений" - тревога никогда не срабатывала?
    с. Что такое "2 сигнала тревоги"?
    д. Является ли имя com.username.weatherinfo для имени пакета, которое было присвоено ожидающему намерению в поле контекста?
    е. "Действует" означает действие, которое было отправлено для намерения?
    е. Что такое "cmp" ? Я вижу, что он состоит из имени пакета и имени класса, но откуда они взяты? От конструктора намерений? г. Почему часть сигналов тревоги только "действует" или только "cmp" ? Я предположил, что тревоги без полей "cmp" предназначены для неявных трансляций. Тем не менее, почему есть тревоги без поля "act"?

  • Статистика предупреждений:

    а. Что это?

Ответы

Ответ 1

Я понимаю, что эта ветка устарела, но ответы нелегко найти и могут быть полезны. Я потратил много времени на то, что означают эти сообщения.

Q1: партии

Pending alarm batches: 23

Тревоги организованы в партии. Как описано в документации:

Начиная с API 19, время запуска, переданное этому методу, рассматривается как неточное: сигнал тревоги не доставляется до этого времени, но может быть отложен и доставлен через некоторое время. ОС будет использовать эту политику для "пакетных" аварийных сигналов вместе во всей системе, минимизируя количество раз, когда устройство должно "просыпаться" и минимизировать использование батареи. В общем случае аварийные сигналы, запланированные в ближайшем будущем, не будут отложены до тех пор, пока тревога запланирована далеко в будущем.

В партии может быть более одного сигнала тревоги. В этом случае имеется 23 пакета сигналов тревоги, что означает, что, вероятно, запланировано гораздо больше 23 аварийных сигналов. На выходе dumpsys alarm строка, описывающая каждую партию, выглядит следующим образом:

Batch{4293d3a8 num=1 start=1369361 end=1407261}:

В котором:

  • 4293d3a8 - внутренний идентификатор, связанный с пакетом.
  • num=1 - количество тревог в этой партии. В этом случае в пакете есть только один сигнал.
  • числа start и end представляют собой количество миллисекунд, прошедших с момента последней перезагрузки системы как описанных в этом сообщении, а также примерно окно времени, в которое должны запускаться аварийные сигналы в партии.

Q2: Аварийные сигналы

Каждый сигнал тревоги описывается тремя строками, которые выглядят следующим образом:

RTC #0: Alarm{4293d358 type 1 com.android.chrome} 
    type=1 whenElapsed=1369361 when=+19s304ms window=-1 repeatInterval=0 count=0
    operation=PendingIntent{429e4500: PendingIntentRecord{429dbbc8 com.android.chrome broadcastIntent}}

В котором:

  • Первая часть, которая является одной из RTC_WAKEUP, RTC, ELAPSED_WAKEUP или ELAPSED, представляет type тревоги и соответствует целочисленному значению 0-3, соответственно
  • #0 - номер тревоги в пакете, где числа идут от 0 до n-1, где n - количество аварийных сигналов в партии. Если ваша тревога попадает вместе с другими, самая дальнейшая в будущем "когда =" определяет время, в течение которого будут запускаться все тревоги в партии.
  • 4293d358 - внутренний номер идентификатора, связанный с сигналом тревоги
  • com.android.chrome - это имя пакета класса, в котором установлен аварийный сигнал
  • type=1, тип тревоги, см. первую марку выше
  • whenElapsed=1369361 относится к числу миллисекунд с момента запуска системы (примерно)
  • when=+19s304ms означает, что будильник будет срабатывать через 19 секунд, 304 миллисекунды с момента вызова dumpsys alarm. Аналогично, значение, подобное +2d13h29m03s882ms, относится к относительному времени 2 дня, 13 часов, 29 минут... в будущем
  • window= относится к одной из двух внутренних констант, связанных с методом, в котором помечен сигнал тревоги. AlarmManager.WINDOW_EXACT=0 и устанавливается, когда будильник запланирован с помощью setExact() или setAlarmClock(). AlarmManager.WINDOW_HEURISTIC=-1 и устанавливается, когда будильник запланирован на setInexactRepeating(). В противном случае значение определяется версией API. Для API < 19 (KitKat), WINDOW_EXACT и для API >= 19 используется WINDOW_HEURISTIC. (Я должен был найти исходный код AlarmManager.java, чтобы понять это.)
  • repeatInterval=900000 заключается в том, как часто повторяется сигнал тревоги, например. каждые 900000мс или 15 минут. Значение 0 означает, что будильник не повторяется.
  • count= относится к числу раз, когда срабатывал сигнал , но по какой-либо причине не был. 0 - хорошее число здесь. > 0 означает, что по какой-то причине сигнал пропущен.
  • operation=PendingIntent{...} - это ссылка на PendingIntent, которая срабатывает по сигналу тревоги. В зависимости от того, был ли экземпляр PendingIntent создан с использованием getService, getBroadcast, getActivity или getActivities, будильник запустит службу, отправит трансляцию или начнет одно или несколько действий.

Q3: количество трансляций Ref

Чтобы узнать об этом и других выходных элементах после этого, я должен был найти исходный код AlarmManagerService.java.

Для того, чтобы некоторые сигналы тревоги работали, устройство должно быть разбужено и не должно возвращаться спать, пока не будут отправлены все необходимые передачи. Внутренняя переменная mBroadcastRefCount инициализируется в 0 и увеличивается при передаче в очереди. По мере того, как посылается каждая передача, она уменьшается и когда она возвращается к 0, выдается wakeLock, и устройство нормально возвращается в режим сна.

Broadcast Ref Count: 0 просто означает, что во время выполнения dumpsys alarm он не был посреди отправки каких-либо передач.

Q4: Верхние аварийные сигналы

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

Q5: Статистика аварийных сигналов

В этом разделе приведены данные о всех тревогах, которые были запущены с момента последнего перезапуска системы. Здесь вы можете посмотреть, были ли активированы сигналы тревоги, установленные вами в прошлом, если они разбудили телефон и т.д. Формат этих записей будет рассмотрен далее.

Q6: Записи статистики аварийных сигналов

Записи в статистике тревог выглядят следующим образом:

com.example.someapp +1s857ms running, 0 wakeups:
    +1s817ms 0 wakes 83 alarms: cmp={com.example.someapp/com.example.someapp.someservice}
    +40ms 0 wakes 1 alarms: cmp={com.example.someapp/com.example.someapp.someotherservice}

где в первой строке:

  • com.example.someapp - это имя пакета процесса, вызвавшего аварийный сигнал
  • +1s857ms running - общее системное время, затрачиваемое процессами
  • 0 wakeups - количество раз, когда устройство было разбужено одним из этих аварийных сигналов

а затем каждая строка после этого относится к одному из установленных аварийных сигналов:

  • +1s817ms - общее системное время
  • 0 wakes - это количество раз, когда устройство нужно было разбудить.
  • 83 alarms - это количество срабатываний будильника; это будет только > 1 для повторения сигналов тревоги
  • cmp={...} служба, которая была запущена при срабатывании тревоги

В качестве альтернативы, если тревога вызвала широковещательную передачу, запись может выглядеть так:

android +4m51s566ms running, 281 wakeups:
    +2m46s583ms 0 wakes 1224 alarms: act=android.intent.action.TIME_TICK
    +1m25s624ms 89 wakes 89 alarms: act=android.content.syncmanager.SYNC_ALARM
    +52s898ms 0 wakes 41 alarms: act=com.android.server.action.NETWORK_STATS_POLL
    ...

с:

  • act=... - название намерения, которое было передано

Сигнал тревоги может иметь как запись cmp={...}, так и act=..., что означает, что сигнал тревоги передавал намерение и запускал службу.

Резюме

Отладка андроид-сигналов с использованием вывода adb shell dumpsys alarm может быть сложной, и нет центрального местоположения, где сообщения dumpsys полностью объясняются. Не всегда очевидно, как сбрасываются сигналы тревоги, и иногда бывает трудно получить услугу или активность, которые будут срабатывать именно по желанию. Надеюсь, это будет полезной ссылкой для людей, пытающихся отладить свои тревоги.

Ответ 2

Как кто-то, кто также боролся с сигналами тревоги, вот два совета:

Отладка вывода оболочки:

  • видя отрицательные или огромные времена (например, -2hr57m20s311ms, 14d5hr23m07s500ms), было связано с тем, что я смутил тип часов (например, RTC с ELAPSED). Это ясно в документации "RTC_WAKEUP: Alarm time in System.currentTimeMillis()" https://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP

  • отмена аварийных сигналов в режиме реального времени (после их создания). Используйте отмену, которая, если вы запланировали ожидающее намерение, нуждается в обоих: alarmManager.cancel(pendingIntent) и pendingIntent.cancel()

Ответ 3

Несмотря на то, что морфологический ответ - это все, что вам нужно знать, я создал проект с открытым исходным кодом для графического интерфейса, чтобы визуализировать ту же информацию. Я думаю, что это может быть полезно для других, поскольку это было для меня в первую очередь.

https://github.com/Dottorhouse/DumpsysAlarm