Should I use AlarmManager or Handler?

Question

I'm writing an app that constantly polls the device's sensors and every so often should write down some statistics to a file. This could be as fast as once a second or as slow once a minute. Should I use Handler's postDelayed()method or just schedule it with the AlarmManager?

msysmilu · Answer 1 · 2015-09-24T10:16:36.890

25

This should help you discriminate between Handler and AlarmManager. [source]

Though it is agreed these mostly work for API 23. It's a new release.

edited Sep 24 '15 at 10:16

answered Sep 24 '15 at 09:57

msysmilu

2,015
23
24

score 16 · Answer 2 · answered Nov 05 '12 at 09:35

16

If the app should work in standby then AlarmManager. If not then Handler.
AlarmManager will wake CPU therefore it will drain battery more, while Handler will not work on standby.

answered Nov 05 '12 at 09:35

pawelzieba

16,082
3
46
72

1

When does a phone go into sleep mode? I've been beta testing my app for a while now and the device going into standby has never been an issue. – Moises Jimenez Nov 05 '12 at 09:55
2

I've just found more detailed similar answer: http://stackoverflow.com/a/5120225/538169 – pawelzieba Nov 05 '12 at 10:16

cgr · Answer 3 · 2014-11-05T15:04:11.630

Decide your design based on the below key points:

AlarmManager: The advantage with the AlarmManager is that it works even if the device is in deep sleep mode (CPU is off). When the alarm fires, it hits the BroadcastReceiver and in onReceive, it acquires the wake lock (if you have used WAKEUP types of alarms like RTC_WAKEUP or ELAPSED_TIME_WAKEUP). After finishing the onReceive() it releases the wake lock.

But most of the times it DID NOT WORK for me. So I have acquired my own wake locks in onReceive() and released them at the end to make sure I really get CPU.

The reason why it DID NOT WORK is that when multiple applications simultaneously use a resource (such as wake locks that prevent the system from suspending), the framework spreads CPU consumption across those applications, although not necessarily equally. So, if it is critical, it is always better to acquire wake locks and do the stuff.

Timers and Handlers: Handler and Timers do not work in deep sleep mode meaning the task/runnable will not run as per the schedule when the device is asleep. They do not count the time in sleep which means that the delay given to execute task will be calculated only during active mode. So, actual delay will be delay-given + time-spent-in-deep-sleep.

Thanks. Would be nice to show an example of how you acquired your own wake locks. there are so many posts in stackoverflow on timer or doing things in an interval and I havent been able to do that consistently using AlarmManager, Handler, BackgroundServices or Sleeps :P The only thing I haven't tried is what is explained here https://stackoverflow.com/a/11177974 — San Jay, Mar 24 '18 at 21:33

score 2 · Accepted Answer · answered Nov 05 '12 at 09:10

I'd say that it depends on the polling interval. I guess it's quite low in your case (around a few secs), so you should go the Handler way, or by using the Timer class.

AlarmManger is a much higher level service and it involves a larger overhead to handle this use case. When an alarm triggers, you need to handle it with BroadcastReceivers. This means that every time you handle one of these alarm, you needs to register listeners for the sensors you're interested in, which is immensely inefficient imho.

I checked the Timer documentation, what does it mean for a Timer to be run as a daemon thread? Is it a service? — Moises Jimenez, Nov 05 '12 at 09:16

Should I use AlarmManager or Handler?

4 Answers4

Linked