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，都是由这样子的块构成：

    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. 代表：发送广播的名称

posted @ 2021-08-04 11:48 schips 阅读(2291) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

黄树超

非典型嵌入式行业从业者；C/C++，Linux/Android

ADB命令与Dumpsys alarm查看应用程序唤醒命令

ADB命令与Dumpsys alarm查看应用程序唤醒命令

背景

dumpsys alarm

结果解析

Pending alarm batches

Batch

每一个alrm

Broadcast Ref Count

Top alarms

Alarm Stats

每个alarm