如何阅读“adb shell dumpsys alarm"输出 [英] How to read "adb shell dumpsys alarm" output
问题描述
我正在努力正确设置闹钟,并了解取消和重新安排闹钟的机制.
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
是该批次的报警数量.在这种情况下,批次中只有一个警报.start
和end
数字表示自系统上次重新启动以来经过的毫秒数 在这篇博文中描述,也粗略地表示了应该触发批次中的警报的时间窗口.
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
andend
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_WAKEUP
、RTC
、ELAPSED_WAKEUP
或ELAPSED
之一,表示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
是否使用getService
、getBroadcast
、getActivity
或getActivities
实例化>,闹钟将启动一项服务、发送广播或启动一项或多项活动.
- The first part, which is one of
RTC_WAKEUP
,RTC
,ELAPSED_WAKEUP
, orELAPSED
, represents thetype
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 ton-1
wheren
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 alarmcom.android.chrome
is the package name of the class that set the alarmtype=1
, the type of alarm, see first bullet abovewhenElapsed=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 whendumpsys alarm
was called. Likewise, a value like+2d13h29m03s882ms
refers to a relative time 2 days, 13 hours, 29 minutes... in the futurewindow=
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 withsetExact()
orsetAlarmClock()
.AlarmManager.WINDOW_HEURISTIC=-1
and is set when the alarm is scheduled withsetInexactRepeating()
. 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 theAlarmManager.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 thePendingIntent
that gets triggered by the alarm. Depending on whether thePendingIntent
was instantiated usinggetService
,getBroadcast
,getActivity
, orgetActivities
, 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 processes0 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
是警报被触发的次数;对于重复警报,这只会 >1cmp={...}
触发警报时启动的服务
+1s817ms
is total system time consumed0 wakes
is the number of times the device had to be woken up83 alarms
is the number of times the alarm has been triggered; this will only be >1 for repeating alarmscmp={...}
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屋!