ADB命令与Dumpsys alarm查看应用程序唤醒命令
背景
在研究设备的低功耗突然唤醒时，看到了对应的唤醒源：
[ 75.813476] suspend ns: 75813465022x09suspend cycles: 1548322670
[ 75.813465] resume cycles: 2105086036
## 注意到这一行，唤醒源。
[ 75.813658] pm_system_irq_wakeup: 197 triggered pm8xxx_rtc_alarm
[ 75.814549] Enabling non-boot CPUs ...
[ 75.816121] Detected VIPT I-cache on CPU1
[ 75.816267] arch_timer: CPU1: Trapping CNTVCT access
[ 75.816333] CPU1: Booted secondary processor 0x0000000001 [0x51af8014]
[ 75.822557] CPU1 is up
[ 75.825359] Detected VIPT I-cache on CPU2
[ 75.825524] arch_timer: CPU2: Trapping CNTVCT access
[ 75.825598] CPU2: Booted secondary processor 0x0000000002 [0x51af8014]
[ 75.832122] CPU2 is up
[ 75.834884] Detected VIPT I-cache on CPU3
[ 75.835055] arch_timer: CPU3: Trapping CNTVCT access
[ 75.835129] CPU3: Booted secondary processor 0x0000000003 [0x51af8014]
[ 75.842262] CPU3 is up
[ 75.844905] Detected VIPT I-cache on CPU4
[ 75.845065] arch_timer: CPU4: Trapping CNTVCT access
[ 75.845142] CPU4: Booted secondary processor 0x0000000100 [0x51af8002]
[ 75.851134] CPU4 is up
[ 75.852917] Detected VIPT I-cache on CPU5
[ 75.853039] arch_timer: CPU5: Trapping CNTVCT access
[ 75.853095] CPU5: Booted secondary processor 0x0000000101 [0x51af8002]
[ 75.858917] CPU5 is up
[ 75.860717] Detected VIPT I-cache on CPU6
[ 75.860846] arch_timer: CPU6: Trapping CNTVCT access
[ 75.860903] CPU6: Booted secondary processor 0x0000000102 [0x51af8002]
[ 75.867485] CPU6 is up
[ 75.869900] Detected VIPT I-cache on CPU7
[ 75.870034] arch_timer: CPU7: Trapping CNTVCT access
[ 75.870094] CPU7: Booted secondary processor 0x0000000103 [0x51af8002]
[ 75.877657] CPU7 is up
[ 76.035199] enter resume
[ 76.035227] enter disable wake up
因此，需要排查alarm有关的问题。
dumpsys alarm
在安卓adb root进如命令行后（没有root或者root群组的权限执行不了该命令），执行方法：
adb shell "dumpsys alarm"adb dumpsys alarm
结果解析
Pending alarm batches
当应用设置ALARM的时候，系统不会将这些ALARM在设置的准确时间内触发，而将用一种批量触发（batches mode）的策略，这样可以最小化地使系统从休眠状态醒来，最低程度地减少电池的消耗，即将一批触发时间接近的闹钟，压缩到某一个时间段内一起触发，而不是一个个触发，这样系统会很难休眠。
Pending alarm batches: 16表示，有16个ALARM将被触发，dumpsys alarm 输出后，就是现实每一个闹钟的触发详情，如：
Pending alarm batches: 16
Batch{45002a6 num=2 start=1850496 end=2152767 flgs=0x8}:
ELAPSED #1: Alarm{9da07d9 type 3 when 1850496 android}
tag=*alarm*:com.android.server.action.NETWORK_STATS_POLL
type=3 expectedWhenElapsed=+9m18s608ms expectedMaxWhenElapsed=+31m48s608ms whenElapsed=+9m18s608ms maxWhenElapsed=+31m48s608ms when=+9m18s608ms
window=+22m30s0ms repeatInterval=1800000 count=0 flags=0x8
operation=PendingIntent{b0fa59e: PendingIntentRecord{53d87f android broadcastIntent}}
ELAPSED_WAKEUP #0: Alarm{e4104c type 2 when 1252767 android}
tag=*walarm*:WifiConnectivityManager Schedule Watchdog Timer
type=2 expectedWhenElapsed=-39s121ms expectedMaxWhenElapsed=+14m20s879ms whenElapsed=-39s121ms maxWhenElapsed=+14m20s879ms when=-39s121ms
window=+15m0s0ms repeatInterval=0 count=0 flags=0x8
operation=null
listener=android.app.AlarmManager$ListenerWrapper@4da4895
...
Batch
Batch{45002a6 num=2 start=1850496 end=2152767 flgs=0x8}:
45002a6：批处理模式下的内部ID号
num = 2：表示在该batch中，有2个闹钟
ELAPSED #1: Alarm{9da07d9 type 3 when 1850496 android}
...
ELAPSED_WAKEUP #0: Alarm{e4104c type 2 when 1252767 android}
...
start、end：表示自系统启动后，流逝的时间，该段时间粗略的表示，该闹钟会在start和end之间的时间触发
每一个alrm
对于每一个alrm，都是由这样子的块构成：
ELAPSED_WAKEUP #1: Alarm{61bf54d type 2 when 21600000 com.android.providers.calendar}
tag=*walarm*:com.android.providers.calendar.intent.CalendarProvider2
type=2 expectedWhenElapsed=+5h38m28s112ms expectedMaxWhenElapsed=+10h8m28s112ms whenElapsed=+5h38m28s112ms maxWhenElapsed=+10h8m28s112ms when=+5h38m28s112ms
window=+4h30m0s0ms repeatInterval=21600000 count=0 flags=0x0
operation=PendingIntent{5331802: PendingIntentRecord{b9e0513 com.android.providers.calendar broadcastIntent}}
ELAPSED #0: Alarm{7862350 type 3 when 14535465 android}
tag=*alarm*:LockSettingsPrimaryAuth.nonStrongBiometricIdleTimeoutForUser
type=3 expectedWhenElapsed=+3h40m43s577ms expectedMaxWhenElapsed=+6h40m43s576ms whenElapsed=+3h40m43s577ms maxWhenElapsed=+6h40m43s576ms when=+3h40m43s577ms
window=+2h59m59s999ms repeatInterval=0 count=0 flags=0x8
operation=null
listener=android.app.AlarmManager$ListenerWrapper@2bf9949
ELAPSED_WAKEUP：表示ALARM的类型type，一般有：RTC_WAKEUP、RTC、 ELAPSED_WAKEUP、ELAPSED。
详见：https://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP
#1：表示在该批量模式中，该ALARM的标号，取值0~n-1，n为该batch中alarm个数
61bf54d：闹钟的内部编号
type=1：闹钟的类型，即第一条中提到的几个闹钟类型，相当于type对应的整数值
com.android.providers.calendar：设置该闹钟的应用包名
whenElapsed=+5h38m28s112ms：该闹钟会在系统开机后，大概5小时后触发。
when = 21600000：该闹钟时间戳为21600000以后触发
window=：根据该alarm被调度的不同方法，设置不同的值：
- 如果该alarm是 setExact()或setAlarmClock()方法调用的，该值为 AlarmManager.WINDOW_EXACT（=0），
- 如果是 setInexactRepeating()，则赋值为AlarmManager.WINDOW_HEURISTIC（=- 1），
- 然而A PI的level不同该值也不同，API小于19（KITKAT）的是WINDOW_EXACT，大于19的是WINDOW_HEURISTIC
repeatInterval=21600000：闹钟的重复频率，900000ms后重复，0表示不重复
count=：表示该alarm因为某些原因而被忽略了的次数，0表示没有被忽略过
operation=PendingIntent{...}：与pendingIntent相关，该intent被实例化后，可以发送广播，启动服务，或者启动Activity， 说白了就是唤醒应用的操作。
Broadcast Ref Count
Broadcast Ref Count: 0
为了使得系统在醒来后，发送必要的广播帧，并且保证在所有的广播帧没有发送出去之前，系统不要进入睡眠状态，内部定义了一个变量：mBroadcastRefCount ，它的初始值是0，
并且当需要发送的广播在队列配对的时候，该变量的值就会递增，发送一个广播后则递减，当减到0的时候，就会释放它持有的wakelock，而让系统进入休眠状态。
所以，Broadcast Ref Count: 0 表示此时此刻，该时刻并没有广播要发送。
Top alarms
根据应用的唤醒系统的时间排行，取最长时间的前十名，然后按照降序列出，有助于找出第三方app因为编程不规范，而导致极度耗电
Top Alarms:
+10s913ms running, 1 wakeups, 1 alarms: u0a113:com.qti.ltebc
*walarm*:wake_up_from_boot
+10s156ms running, 1 wakeups, 1 alarms: u0a56:com.android.providers.calendar
*walarm*:com.android.providers.calendar.intent.CalendarProvider2
+1s333ms running, 0 wakeups, 1 alarms: 1000:android
*alarm*:com.android.server.action.NETWORK_STATS_POLL
+755ms running, 0 wakeups, 8 alarms: 1000:android
*alarm*:TIME_TICK
+220ms running, 1 wakeups, 1 alarms: 1000:android
*walarm*:EventConditionProvider.EVALUATE
+219ms running, 1 wakeups, 1 alarms: 1000:android
*walarm*:ScheduleConditionProvider.EVALUATE
+202ms running, 0 wakeups, 1 alarms: 1000:android
*alarm*:GraphicsStatsService
+56ms running, 3 wakeups, 3 alarms: 1000:android
*walarm*:WifiConnectivityManager Schedule Periodic Scan Timer
+45ms running, 1 wakeups, 1 alarms: 1000:android
*walarm*:*job.deadline*
+39ms running, 0 wakeups, 1 alarms: 1000:android
*alarm*:*CountQuotaTracker.cleanup*
Alarm Stats
列出所有系统中应用设置alarm的情况，可以排查设置的闹钟是否起作用了。
Alarm Stats:
1000:android +2s413ms running, 7 wakeups:
+1s333ms 0 wakes 1 alarms, last -20m41s388ms:
*alarm*:com.android.server.action.NETWORK_STATS_POLL
+755ms 0 wakes 8 alarms, last -3m8s638ms:
*alarm*:TIME_TICK
+220ms 1 wakes 1 alarms, last -20m25s368ms:
*walarm*:EventConditionProvider.EVALUATE
+219ms 1 wakes 1 alarms, last -20m25s368ms:
*walarm*:ScheduleConditionProvider.EVALUATE
+202ms 0 wakes 1 alarms, last -20m25s368ms:
*alarm*:GraphicsStatsService
+56ms 3 wakes 3 alarms, last -19m35s130ms:
*walarm*:WifiConnectivityManager Schedule Periodic Scan Timer
+45ms 1 wakes 1 alarms, last -19m35s130ms:
*walarm*:*job.deadline*
+39ms 0 wakes 1 alarms, last -9m32s957ms:
*alarm*:*CountQuotaTracker.cleanup*
+26ms 1 wakes 1 alarms, last -19m55s159ms:
*walarm*:WifiHealthMonitor Schedule Post-Boot Detection Timer
+23ms 0 wakes 1 alarms, last -19m35s130ms:
*alarm*:*job.delay*
1073:com.android.networkstack +8ms running, 2 wakeups:
+5ms 1 wakes 1 alarms, last -20m26s669ms:
*walarm*:DhcpClient.wlan0.TIMEOUT
+3ms 1 wakes 1 alarms, last -20m30s704ms:
*walarm*:DhcpClient.wlan0.KICK
u0a56:com.android.providers.calendar +10s156ms running, 1 wakeups:
+10s156ms 1 wakes 1 alarms, last -20m18s689ms:
*walarm*:com.android.providers.calendar.intent.CalendarProvider2
u0a113:com.qti.ltebc +10s913ms running, 1 wakeups:
+10s913ms 1 wakes 1 alarms, last -20m19s759ms:
*walarm*:wake_up_from_boot
格式如下
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}
例如：
1073:com.android.networkstack +8ms running, 2 wakeups:
+5ms 1 wakes 1 alarms, last -20m26s669ms:
*walarm*:DhcpClient.wlan0.TIMEOUT
+3ms 1 wakes 1 alarms, last -20m30s704ms:
*walarm*:DhcpClient.wlan0.KICK
com.android.networkstack：设置alarm的应用包名
+8ms running：系统总体被该应用所有的alarm消耗的时间
2 wakeups：设备被闹钟唤醒的次数，包含了每一次alarm的情况
每个alarm
1073:com.android.networkstack +8ms running, 2 wakeups:
+5ms 1 wakes 1 alarms, last -20m26s669ms:
*walarm*:DhcpClient.wlan0.TIMEOUT
+5ms：该alarm消耗的时间
1 wakes：设备被唤醒的次数
1 alarms：alarm被触发的次数，重复闹钟，该值大于1
如果触发的是广播，则格式如：
1000:android +2s413ms running, 7 wakeups:
+1s333ms 0 wakes 1 alarms, last -20m41s388ms:
*alarm*:com.android.server.action.NETWORK_STATS_POLL
+755ms 0 wakes 8 alarms, last -3m8s638ms:
*alarm*:TIME_TICK
+220ms 1 wakes 1 alarms, last -20m25s368ms:
*walarm*:EventConditionProvider.EVALUATE
+219ms 1 wakes 1 alarms, last -20m25s368ms:
*walarm*:ScheduleConditionProvider.EVALUATE
+202ms 0 wakes 1 alarms, last -20m25s368ms:
*alarm*:GraphicsStatsService
+56ms 3 wakes 3 alarms, last -19m35s130ms:
*walarm*:WifiConnectivityManager Schedule Periodic Scan Timer
+45ms 1 wakes 1 alarms, last -19m35s130ms:
*walarm*:*job.deadline*
+39ms 0 wakes 1 alarms, last -9m32s957ms:
*alarm*:*CountQuotaTracker.cleanup*
+26ms 1 wakes 1 alarms, last -19m55s159ms:
*walarm*:WifiHealthMonitor Schedule Post-Boot Detection Timer
+23ms 0 wakes 1 alarms, last -19m35s130ms:
*alarm*:*job.delay*
action. 代表：发送广播的名称