android - 如何读取 "adb shell dumpsys alarm"输出

Question

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

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

我明白，我在这里问了很多解释，所以如果有人会抛出一个关于“adb shell dumpsys alarm”的详细解释的链接，我会非常感激。

所以，这里是问题:

Pending alarm batches: 23

a. '23' 是当前 Activity 的、预定的警报数量吗？

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}}

a.什么是“num=1”、“start=1369361”和“end=1407261”？
湾'RTC' 代表 RTC 警报，我想。
C. “#0”代表什么？
d. 'type=1' 是什么意思？
e. 'when=+19s304ms' 是否意味着将在 19 秒内触发警报？
f. 'window=-1' 是什么意思？
克。 'repeatInterval=0' 是否意味着这是非重复警报？
小时。 'count=0' 是否意味着由于手机 sleep 状态，这个闹钟没有被推迟？
一. 'operation=PendingIntent{...}' 代表待处理的 Intent ，我假设它将被警报触发。

Broadcast ref count: 0

a.这是什么？

Top Alarms:

a.这是什么？

+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}

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

Alarm Stats:

a.这是什么？

Answer 1

我意识到这个线程很旧，但答案并不容易找到，并且可能有用。我花了很多时间来研究这些消息的含义。
Q1:批次

Pending alarm batches: 23

警报按批次组织。 As described in the documentation :

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输出，描述每个批次的行如下所示:

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

其中:

4293d3a8是与批次关联的内部 ID。

num=1是该批次中的警报数。在这种情况下，批次中只有一个警报。

start和 end数字表示自系统上次重新启动以来经过的毫秒数 described in this post ，也粗略地表示应该触发批处理中的警报的时间窗口。

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是批次中的警报数。如果您的警报与其他人一起批处理，那么 future 最远的“when=”定义了触发批次中所有警报的时间。

4293d358是与警报相关的内部 ID 号

com.android.chrome是设置警报的类的包名

type=1 ，警报类型，请参见上面的第一项

whenElapsed=1369361指自系统启动后触发此警报的毫秒数(大约)

when=+19s304ms表示警报将在 19 秒后触发，从 dumpsys alarm 开始的时间为 304 毫秒。被称为。同样，像 +2d13h29m03s882ms 这样的值指相对时间 2 天 13 小时 29 分钟... future

window=指与报警批处理方法有关的两个内部常量之一。 AlarmManager.WINDOW_EXACT=0并且在使用 setExact() 安排警报时设置或 setAlarmClock() . AlarmManager.WINDOW_HEURISTIC=-1并且在使用 setInexactRepeating() 安排警报时设置.否则，该值由 API 版本决定。对于 API < 19 (KitKat)，WINDOW_EXACT用于 API >= 19, WINDOW_HEURISTIC使用。 (我必须 dig into the AlarmManager.java source code 才能弄清楚。)

repeatInterval=900000是闹钟重复的频率，例如每 900000 毫秒或 15 分钟。值为 0 表示警报不会重复。

count=指报警次数应该已被触发，但 不是 出于某种原因。 0 在这里是一个很好的数字。 >0 表示由于某种原因跳过了警报。

operation=PendingIntent{...}是对 PendingIntent 的引用由警报触发。取决于是否PendingIntent使用 getService 实例化, getBroadcast , getActivity , 或 getActivities ，闹钟将启动一项服务、发送广播或启动一项或多项 Activity 。

Q3:广播引用计数
要了解此内容以及此后的其他输出项目，我必须dig into the AlarmManagerService.java source code .
为了使某些警报起作用，必须唤醒设备，并且在发送完所有必要的广播之前不应返回 sleep 状态。内部变量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=...被广播的 Intent 的名称

警报可能同时具有 cmp={...}和一个 act=...条目，意味着警报既广播 Intent 又启动服务。
总结
使用 adb shell dumpsys alarm 的输出调试 android 警报可能很棘手，而且没有中心位置 dumpsys消息得到充分解释。警报如何批量处理并不总是很明显，有时很难在需要时准确触发服务或 Activity 。希望这对于尝试调试警报的人来说是有用的引用。