Blog Infos
The ADB command “dumpsys alarm” provides comprehensive data on the alarms scheduled on Android devices.
adb shell dumpsys alarm
Before diving into the blog, run the given command to see the output. It’ll help you grasp the content better.
command specifically gives the following information
- Settings: Includes the constraint information, minimum and maximum alarm intervals and quota limits
- Exempted Packages: Includes list containing White-Listed apps and apps having USE_EXACT_ALARM permission
- Pending Alarms: Includes all the alarms | batches that are pending
- Top Alarms: Includes top 10 apps having maximum alarm usage
- Alarm Stats: Includes Overview of Triggered Alarms
1. Settings
min_futurity=+5s0ms min_interval=+1m0s0ms max_interval=+365d0h0m0s0ms listener_timeout=+5s0ms allow_while_idle_short_time=+5s0ms allow_while_idle_long_time=+9m0s0ms allow_while_idle_whitelist_duration=+10s0ms max_alarms_per_uid=500 app_standby_window=+1h0m0s0ms standby_active_quota=720 standby_working_quota=10 standby_frequent_quota=2 standby_rare_quota=1 standby_never_quota=0 standby_restricted_quota=1 app_standby_restricted_window=+1d0h0m0s0ms
- min_futurity: the minimum time in the future for which the alarm can be scheduled
- min_interval: the shortest gap between two repeating alarms
- maximum_interval: the longest gap between two repeating alarms
- standby_active_quota, standby_working_quota, standby_frequent_quota, standby_rare_quota, standby_never_quota, and standby_restricted_quota indicate the number of alarms triggered per hour by the package with the given standby bucket
- The above quota limits can also be validated through Power Management Restrictions documentation
2. Exempted Packages
Exempted packages contain a list of all the White-Listed apps and apps having USE_EXACT_ALARM permission.
Exempted packages:
User 0
com.google.android.youtube
com.whatsapp
com.android.providers.calendar
com.nikhil.here.myalarammanager
...
- Exempted packages can ignore battery optimization and power management restrictions
- so the app standby quota is not applicable to exempted apps
3. Pending Alarms
Pending alarm batches: 42
Batch{58a4ec6 num=1 start=5061218010 end=5061218010 flgs=0x5}:
RTC_WAKEUP #0: Alarm{17b4f24 type 0 when 1690717200000 com.nikhil.here.myalarammanager}
tag=*walarm*:com.nikhil.here.myalarammanager/.domain.receivers.AlarmBroadcastReceiver
type=0 expectedWhenElapsed=+6m55s702ms expectedMaxWhenElapsed=+6m55s702ms whenElapsed=+6m55s702ms maxWhenElapsed=+6m55s702ms when=2023-07-30 17:10:00.000
window=0 repeatInterval=0 count=0 flags=0x5
operation=PendingIntent{3080e87: PendingIntentRecord{24581b4 com.nikhil.here.myalarammanager broadcastIntent}}
- Starting from API 19, all the inexact alarms are deferred, and the system attempts to batch multiple alarms together across the entire system. This reduces the number of times the device needs to “wake up,” minimizing overall battery drain.
Pending alarm batches : 42indicates that there are 42 pending batches, each batch has a unique identifier and the start-end timeRTC_WAKEUP #0 Alarm{17b4f24 type 0 when 1690717200000 com.nikhil.here.myalarmmanagergives the information on the type and execution time of the alarm- there are four different types of the alarm mentioned below
| Type | value | |------------------------- |------- | | RTC_WAKEUP | 0 | | RTC | 1 | | ELAPSED_REALTIME_WAKEUP | 2 | | ELAPSED_REALTIME | 3 |
- about execution time,
when 1690717200000for RTC and RTC_WAKEUP type alarms, the execution time is based on the device wall time i.e usingSystem.currentTimeinMillis()method, for ELAPSED type of alarms the execution time is given based on the device reboot time. expectedWhenElapsed | whenElapsedgives the expected remaining time for the alarm executionexpectedMaxWhenElapsed | maxWhenElapsedgives the expected remaining time plus the expected delay for the given alarm execution.- in our example
expectedWhenElapsedandexpectedMaxWhenElapsedboth are equal indicating that the given alarm is the Exact alarm, for which we don’t expect any delay in execution window = 0the value will be > 0 for alarms set usingsetWindowmethod indicating the window time.repeatInterval = 0the value will be > 1 for repeating alarms indicating repeating intervals. this repeating interval cannot be less than 1 as the minimum interval mentioned in the output of the setting is 1 minutemin_interval=+1m0s0mscount = 0indicates broadcast intent which is in the queue, whenever any alarm is triggered system basically adds the alarm broadcast intent to the queue and increments the counter value, and once the intent is delivered count value is again decremented, the system holds wake-lock while the count is greater than zerooperation=PendingINtent{3080e87:PendingIntentRecord{24581b4 com.nikhil.here.myalarmmanager.broadcastIntent}}gives the broadcast intent, flag information
4. Top Alarms
Top Alarms: +23m34s64ms running, 0 wakeups, 244 alarms: u0a216:com.google.android.calendar *alarm*:com.google.android.calendar.APPWIDGET_SCHEDULED_UPDATE +23m29s238ms running, 278 wakeups, 278 alarms: u0a103:com.android.providers.calendar *walarm*:com.android.providers.calendar.intent.CalendarProvider2 +21m23s110ms running, 222 wakeups, 222 alarms: u0a207:com.google.android.gms *walarm*:com.google.android.location.ALARM_WAKEUP_ACTIVITY_DETECTION +21m22s194ms running, 0 wakeups, 135 alarms: u0a227:com.google.android.apps.maps *alarm*:com.google.android.apps.gmm.plugins.serverrecovery.SCHEDULED_CHECK +20m48s456ms running, 0 wakeups, 2204 alarms: u0a207:com.google.android.gms *alarm*:com.google.android.gms.gcm.ACTION_CHECK_QUEUE +14m33s314ms running, 0 wakeups, 58 alarms: u0a216:com.google.android.calendar *alarm*:com.google.android.calendar.intent.action.MIDNIGHT +13m32s76ms running, 0 wakeups, 55 alarms: u0a216:com.google.android.calendar *alarm*:MonthViewWidgetProvider.MIDNIGHT +11m57s119ms running, 0 wakeups, 53 alarms: u0a154:com.facebook.appmanager *alarm*:check +9m54s957ms running, 4896 wakeups, 4896 alarms: u0a184:com.xiaomi.xmsf *walarm*:com.xiaomi.push.PING_TIMER +9m25s850ms running, 0 wakeups, 21051 alarms: 1000:android *alarm*:*job.delay*
- The top alarms section list ten packages, which have maximum running time, wake locks and number of alarms
+23m34s64ms running, 0 wakeups, 244 alarms: u0a216:com.google.android.calendar
*alarm*:com.google.android.calendar.APPWIDGET_SCHEDULED_UPDATE
Job Offers
OUR VIDEO RECOMMENDATION
ADB is an incredibly underutilized tool that can dramatically improve your Android development experience! Maybe you know some basic ADB commands, perhaps even a couple of nifty advanced ones or possibly, you don’t know what…
Watch Video
Jobs
23m34s64ms runningindicates the total amount of time for which the process was running while executing the given244 alarms with 0 wakelocks- Apps with longer running times and frequent wake-locks are major contributors to battery drain.
- In the above log you can see the Google Calendar app has executed multiple alarms, as I use google calendar heavily and also its whitelisted app which ignores all the battery optimizations
5. Alarm Stats
- Alarm stats gives the overview of all the alarms that are triggered recently,
Alarm Stats: u0a578:com.nikhil.here.myalarammanager +7s115ms running, 1 wakeups: +7s115ms 1 wakes 1 alarms, last -13m51s866ms: *walarm*:com.nikhil.here.myalarammanager/.domain.receivers.AlarmBroadcastReceiver
- The key point is the running time
+7s115ms running, which represents the execution time of our onReceive method that receives the alarm intent. To reduce battery drain we must try to keep this execution time as low as possible.
That’s it, i have covered most of the important details, if you feel anything is missing and requires further explanation, feel free to comment.
Thank You
This article was previously published on proandrdoiddev.com
