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. 代表：發送廣播的名稱