ADB命令与Dumpsys alarm查看应用程序唤醒命令
背景
在研究设备的低功耗突然唤醒时,看到了对应的唤醒源:
[ 75.813476] suspend ns: 75813465022\x09suspend 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,都会有这三行解说:
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}}
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. 代表:发送广播的名称