如何阅读“adb shell dumpsys alarm"输出 [英] How to read "adb shell dumpsys alarm" output

查看:35
本文介绍了如何阅读“adb shell dumpsys alarm"输出的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在努力正确设置闹钟,并了解取消和重新安排闹钟的机制.

I'm struggling with setting an alarm properly, and understanding the mechanism of cancelling and rescheduling alarms.

我发现有一个 adb 命令来检索设备上安排的所有警报,但我没有找到解释输出格式的文档.

I have found, that there is an adb command to retrieve all alarms scheduled on device, but I haven't found a documentation, explaining the format of the output.

我明白,我在这里问了很多解释,所以如果有人提供关于adb shell dumpsys alarm"的详细解释的链接,我将非常感激.

I do understand, that I'm asking a lot of explanations here, so if anybody will throw a link with detailed explanation about "adb shell dumpsys alarm", I will really appreciate it.

那么,这里是问题:

待处理的报警批次:23

Pending alarm batches: 23

一个.'23' 是当前活动的、预定的警报数量吗?

a. Is '23' a number of currently active, scheduled alarms?

批次{4293d3a8 num=1 开始=1369361 结束=1407261}:
  RTC #0:警报{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}}

Batch{4293d3a8 num=1 start=1369361 end=1407261}:
  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}}

一个.什么是num=1"、start=1369361"和end=1407261"?
湾'RTC' 代表 RTC 警报,我想.
C.#0"代表什么?
d.'type=1' 是什么意思?
e.'when=+19s304ms' 是否意味着将在 19 秒内触发警报?
F.'window=-1' 是什么意思?
G.'repeatInterval=0' 是否意味着这是非重复警报?
H.'count=0' 是否意味着由于手机睡眠状态,此警报未推迟?
一世.'operation=PendingIntent{...}' 代表待处理的意图,我假设它将被警报触发.

a. What is 'num=1', 'start=1369361' and 'end=1407261'?
b. 'RTC' stands for RTC alarm, I assume.
c. What '#0' stand for?
d. What means 'type=1'?
e. Is 'when=+19s304ms' meaning that alarm will be triggered in 19 seconds?
f. What means 'window=-1'?
g. Is 'repeatInterval=0' meaning this is non-repeating alarm?
h. Is 'count=0' meaning this alarm wasn't postponed, due to phone sleep state?
i. 'operation=PendingIntent{...}' stands for the pending intent, that will be triggered by alarm, I assume.

广播引用计数:0

Broadcast ref count: 0

一个.这是什么?

热门警报:

一个.这是什么?

+47s271ms 运行,0 次唤醒,2 次警报:com.username.weatherinfo
  act=com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION
   cmp={com.username.weatherinfo/com.username.receivers.CyclicWeatherUpdater}

+47s271ms running, 0 wakeups, 2 alarms: com.username.weatherinfo
  act=com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION
    cmp={com.username.weatherinfo/com.username.receivers.CyclicWeatherUpdater}

一个.'+47s271ms' 是否意味着此警报将在 47 秒内触发?
湾什么是0 次唤醒" - 警报从未触发?
C.什么是2警报"?
d.'com.username.weatherinfo' 是否代表包的名称,在上下文字段中提供给待定的意图?
e.行为"是指为意图而发送的行为吗?
F.什么是'cmp'?我明白了,它是由包名和类名组成的——但它们是从哪里获取的?从意图构造函数?G.为什么部分警报只有行为"或只有cmp"?我假设,没有 'cmp' 字段的警报用于隐式广播意图.然而,为什么会有没有行为"字段的警报?

a. Is '+47s271ms' meaning this alarm will be triggered in 47 seconds?
b. What is '0 wakeups' - alarm was never triggered?
c. What is '2 alarms'?
d. Is 'com.username.weatherinfo' standing for name of package, that was given to pending intent in context field?
e. Is 'act' meaning the action, that was sent for intent?
f. What is 'cmp'? I see, that it is composed from package name and class name - but from where are they taken? From intent constructor? g. Why part of the alarms have only 'act' or only 'cmp'? I have assumed, that alarms without 'cmp' fields are for implicit broadcast intents. Yet, why there are alarms without 'act' field?

报警统计:

一个.这是什么?

推荐答案

我意识到这个帖子很旧,但答案并不容易找到,并且可能有用.我花了很多时间研究这些消息的含义.

I realize this thread is old, but the answers are not easy to find, and could be of use. I've spent a good bit of time working out what these messages mean.

Pending alarm batches: 23

警报按批次组织.如文档:

从 API 19 开始,传递给此方法的触发时间被视为不准确:警报不会在此时间之前传递,但可能会延迟并在一段时间后传递.操作系统将使用此策略在整个系统中批量"警报,最大限度地减少设备需要唤醒"的次数.并尽量减少电池使用.一般来说,安排在近期的闹钟不会推迟,只要安排在很远的将来的闹钟.

Beginning in API 19, the trigger time passed to this method is treated as inexact: the alarm will not be delivered before this time, but may be deferred and delivered some time later. The OS will use this policy in order to "batch" alarms together across the entire system, minimizing the number of times the device needs to "wake up" and minimizing battery use. In general, alarms scheduled in the near future will not be deferred as long as alarms scheduled far in the future.

每批可能有多个警报.在这种情况下,有 23 个批次的警报,这意味着计划的警报可能多于 23 个.在 dumpsys alarm 输出中,描述每个批次的行如下所示:

There may be more than one alarm per batch. In this case there are 23 batches of alarms, which means there are probably many more than 23 alarms scheduled. In the dumpsys alarm output, the line describing each batch looks like:

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

其中:

  • 4293d3a8 是与批次关联的内部 ID.
  • num=1 是该批次的报警数量.在这种情况下,批次中只有一个警报.
  • startend 数字表示自系统上次重新启动以来经过的毫秒数 在这篇博文中描述,也粗略地表示了应该触发批次中的警报的时间窗口.
  • 4293d3a8 is an internal id associated with the batch.
  • num=1 is the number of alarms in this batch. In this case there's only one alarm in the batch.
  • the start and end numbers represent the number of milliseconds that have elapsed since the system was last rebooted as described in this post, and also roughly represent the window of time in which the alarms in the batch should be triggered.

每个警报由三行描述,如下所示:

Each alarm is described by three lines that look like:

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_WAKEUPRTCELAPSED_WAKEUPELAPSED 之一,表示type 报警,分别对应0-3的整数值
  • #0 是批次内的报警编号,编号从 0 到 n-1 其中 n 是编号批次中的警报数.如果您的闹钟与其他人一起分批,那么将来最远的when="定义触发批次中所有警报的时间.
  • 4293d358 是与警报关联的内部 ID 号
  • com.android.chrome 是设置闹钟的类的包名
  • type=1,报警类型,见上面的第一项
  • whenElapsed=1369361 是指自系统启动后触发此警报的毫秒数(大约)
  • when=+19s304ms 表示将在 19 秒内触发警报,即从调用 dumpsys alarm 开始的 304 毫秒.同样,像 +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 是否使用 getServicegetBroadcastgetActivitygetActivities 实例化>,闹钟将启动一项服务、发送广播或启动一项或多项活动.
  • The first part, which is one of RTC_WAKEUP, RTC, ELAPSED_WAKEUP, or ELAPSED, represents the type of alarm and corresponds to an integer value 0-3, respectively
  • #0 is the number of the alarm within the batch, where numbers go from 0 to n-1 where n is the number of alarms in the batch. If your alarm gets batched with others, the furthest in future "when=" defines the time all alarms in the batch will be triggered.
  • 4293d358 is an internal id number associated with the alarm
  • com.android.chrome is the package name of the class that set the alarm
  • type=1, the type of alarm, see first bullet above
  • whenElapsed=1369361 refers to the number of milliseconds since the system started at which this alarm will be triggered (approximately)
  • when=+19s304ms means the alarm will be triggered in 19 seconds, 304 milliseconds from the time when dumpsys alarm was called. Likewise, a value like +2d13h29m03s882ms refers to a relative time 2 days, 13 hours, 29 minutes... in the future
  • window= refers to one of two internal constants having to do with the method in which the alarm is batched. AlarmManager.WINDOW_EXACT=0 and is set when the alarm is scheduled with setExact() or setAlarmClock(). AlarmManager.WINDOW_HEURISTIC=-1 and is set when the alarm is scheduled with setInexactRepeating(). Otherwise, the value is determined by the API version. For API < 19 (KitKat), WINDOW_EXACT is used and for API >= 19, WINDOW_HEURISTIC is used. (I had to dig into the AlarmManager.java source code to figure this out.)
  • repeatInterval=900000 is how often the alarm repeats, e.g. every 900000ms or 15 minutes. A value of 0 means the alarm does not repeat.
  • count= refers to the number of times that an alarm should have been triggered, but wasn't for some reason. 0 is a good number here. >0 means the alarm was skipped for some reason.
  • operation=PendingIntent{...} is a reference to the PendingIntent that gets triggered by the alarm. Depending on whether the PendingIntent was instantiated using getService, getBroadcast, getActivity, or getActivities, the alarm will start a service, send a broadcast, or start one or more activities.

为了了解这个和其他输出项目,我不得不深入AlarmManagerService.java 源代码.

To find out about this and the other output items after this I had to dig into the AlarmManagerService.java source code.

为了使某些警报起作用,必须唤醒设备,并且在发送完所有必要的广播之前不应返回睡眠状态.内部变量 mBroadcastRefCount 初始化为 0,并随着要发送的广播排队而递增.每次发送广播时,它都会递减,当它回到 0 时,wakeLock 被释放,设备可以重新进入睡眠状态.

In order for some alarms to work the device has to be woken up, and should not go back to sleep until all necessary broadcasts have been sent. The internal variable mBroadcastRefCount is initialized at 0 and is incremented as broadcasts to be sent are queued up. As each broadcast is sent it is decremented and when it gets back to 0, the wakeLock is released and it is okay for the device to go back to sleep.

Broadcast Ref Count: 0 只是意味着在运行 dumpsys alarm 时,它没有在发送任何广播.

Broadcast Ref Count: 0 simply means that at the time that dumpsys alarm was run, it was not in the middle of sending any broadcasts.

这是按警报代码运行的总聚合时间降序排列的前十个警报.这可用于查找消耗最多系统资源的警报,例如找出可能会耗尽电池寿命的进程.

This is the top ten alarms ranked in descending order by total aggregate time that the alarm code has run. This can be used to find alarms that are consuming the greatest amount of system resources, e.g. to find processes that may be at fault for draining battery life.

此部分显示自系统上次重新启动以来运行的所有警报的统计信息.您可以在此处查看您过去设置的闹钟是否已触发,是否唤醒了手机等.这些条目的格式将在接下来介绍.

This section shows stats for all of the alarms that have run since the system was last restarted. This is where you can look to see if the alarms you set in the past have been triggered, if they woke the phone up, etc. The format of these entries is covered next.

警报统计条目如下所示:

Alarm stats entries look like:

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 次唤醒 是设备被这些警报之一唤醒的次数
  • com.example.someapp is the package name of the process that triggered the alarm
  • +1s857ms running is the total system time consumed by the processes
  • 0 wakeups is the number of times the device was woken by one of these alarms

然后每一行都指的是设置的警报之一,带有:

and then each line after that refers to one of the alarms that was set, with:

  • +1s817ms 是系统消耗的总时间
  • 0 wakes 是设备必须被唤醒的次数
  • 83 alarms 是警报被触发的次数;对于重复警报,这只会 >1
  • cmp={...} 触发警报时启动的服务
  • +1s817ms is total system time consumed
  • 0 wakes is the number of times the device had to be woken up
  • 83 alarms is the number of times the alarm has been triggered; this will only be >1 for repeating alarms
  • cmp={...} the service that was started when the alarm was triggered

或者,如果警报触发了广播,则条目可能如下所示:

Alternatively, if the alarm triggered a broadcast, the entry might look like:

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=... 是广播意图的名称
  • act=... being the name of the intention that was broadcast

警报可以同时具有 cmp={...}act=... 条目,这意味着警报都广播一个意图并启动了一项服务.

It is possible for an alarm to have both a cmp={...} and a act=... entry, meaning the alarm both broadcast an intent and started a service.

使用adb shell dumpsys alarm 的输出调试android 警报可能很棘手,而且没有中央位置可以完整解释dumpsys 消息.警报如何批量处理并不总是很明显,有时很难在需要时准确触发服务或活动.希望这对尝试调试警报的人有用.

Debugging android alarms using the output of adb shell dumpsys alarm can be tricky, and there is no central location where the dumpsys messages are fully explained. It is not always apparent how alarms get batched together, and sometimes it's difficult to get a service or activity to be triggered exactly when desired. Hopefully this will be useful reference for people trying to debug their alarms.

这篇关于如何阅读“adb shell dumpsys alarm"输出的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆