txt
HOW TO INTERPRET THE OUTPUT FILE:
Q1: Batches
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.
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:
In which:
Q2: Alarms
In which:
To find out about this and the other output items after this I had to dig into the
AlarmManagerService.java source code.
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 simply means that at the time that dumpsys alarm was run, it was
not in the middle of sending any broadcasts.
Q4: Top Alarms
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.
Q5: Alarm Stats
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.
Q6: Alarm Stats Entries
com.example.someapp is the package name of the process that triggered the alarm
+1s857ms running is the total system time consumed by the processes
0 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:
Alternatively, if the alarm triggered a broadcast, the entry might look like:
with:
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.
Summary
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.