AlarmManager instead of Background Service? for repeated tasks

Question

Services can always be shut down by the OS. As such they seem less reliable to me than an AlarmManager. I have to do periodic updates every 1-2 seconds. Is it better to use background thread in a service or AlarmManager. Since there are ways to use AlarmManager without waking up the app. See http://vikinghammer.com/2012/04/22/android-use-alarmmanager-instead-of-a-service-with-a-timertask/

I wonder what advantage all the Timer, Thread, and Service code have? One thought I had against AlarmManager is that the task code must execute somewhere, so upon receiving it a BroadcastReceiver seems like wrong place to execute code. How about passing off to an IntentService? Is this higher overhead than all the thread management inside a running background service? Without AlarmManager how can we guarantee the background service really stays up and running?

Just to clarify, my app will run in background while other apps are allowed to be run by user. I will stop some of them, but let others run for long time. As such I don't think service checking every 2 seconds, guarantees it will be kept around while users are engaged with other apps. But if alarm manager, I can guarantee checks are always done right?

Answer 1

I am not sure but as per my knowledge I share my views. I always accept best answer if I am wrong .

Alarm Manager

The Alarm Manager holds a CPU wake lock as long as the alarm receiver's onReceive() method is executing. This guarantees that the phone will not sleep until you have finished handling the broadcast. Once onReceive() returns, the Alarm Manager releases this wake lock. This means that the phone will in some cases sleep as soon as your onReceive() method completes. If your alarm receiver called Context.startService(), it is possible that the phone will sleep before the requested service is launched. To prevent this, your BroadcastReceiver and Service will need to implement a separate wake lock policy to ensure that the phone continues running until the service becomes available.

Note: The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler.

Timer

timer = new Timer();

timer.scheduleAtFixedRate(new TimerTask() {

    synchronized public void run() {

        \\ here your todo;
        }

    }}, 60000, 60000);

Timer has some drawbacks that are solved by ScheduledThreadPoolExecutor. So it's not the best choice

ScheduledThreadPoolExecutor.

You can use java.util.Timer or ScheduledThreadPoolExecutor (preferred) to schedule an action to occur at regular intervals on a background thread.

Here is a sample using the latter:

ScheduledExecutorService scheduler =
    Executors.newSingleThreadScheduledExecutor();

scheduler.scheduleAtFixedRate
      (new Runnable() {
         public void run() {
            // call service
         }
      }, 0, 10, TimeUnit.MINUTES);

So I preferred ScheduledExecutorService

But Also think about that if the updates will occur while your application is running, you can use a Timer, as suggested in other answers, or the newer ScheduledThreadPoolExecutor. If your application will update even when it is not running, you should go with the AlarmManager.

The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. Take note that if you plan on updating when your application is turned off, once every ten minutes is quite frequent, and thus possibly a bit too power consuming.

Source : Scheduling recurring task in Android