8

I am making an app that needs to execute a function each hour even the app is closed.

First of all, I thought to create a service, but during my tests, I realise that android sometimes kills my service. So I was looking for another solution and I found AlarmManager. I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)

Another question, it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread?

Ahmad
  • 69,608
  • 17
  • 111
  • 137
Jorge181
  • 297
  • 2
  • 4
  • 10

2 Answers2

6

I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)

It will run until:

  • the device is rebooted, as you noted, or
  • the user uninstalls your app, or
  • you cancel the events yourself, or
  • the user goes into Settings, finds your app in the list of installed apps, taps on that entry, and clicks the Force Stop button

It's possible that alarms will need to be scheduled again after your app is upgraded (I forget...).

it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread??

Unless the work you are going to do will take only a couple of milliseconds, you will want a background thread for it. That leads to two possible patterns:

  1. If you are not using a _WAKEUP-style alarm, use a getService() PendingIntent to send control to an IntentService every hour

  2. If you are using a _WAKEUP-style alarm, you will need to use a getBroadcast() PendingIntent, and have it either invoke your subclass of my WakefulIntentService, or you will need to manage a WakeLock yourself to keep the device awake while you do your bit of work

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 2
    Also, if you want it to not stop when the device has been rebooted, you can register it in the `manifest` with an `intent-filter` of `BOOT_COMPLETED` so it will start again once the device is rebooted – codeMagic Apr 22 '13 at 23:03
  • @CommonsWare In case of an upgrade, won't an alarm-clock app be useless since it can't be re-enabled automatically ? I mean , you wrote that after an upgrade, the alarmManager cancels everything related to the app, right? about the running-in-background solutions, do you have any sample codes for each of them? – android developer Apr 22 '13 at 23:09
  • @androiddeveloper: "In case of an upgrade, won't an alarm-clock app be useless since it can't be re-enabled automatically ? " -- listen for `ACTION_PACKAGE_CHANGED`, if that proves to be necessary. "you wrote that after an upgrade, the alarmManager cancels everything related to the app, right?" -- no, that is not what I wrote. I wrote "*It's possible* that alarms will need to be scheduled again after your app is upgraded (*I forget*...)." (emphasis added) "about the running-in-background solutions, do you have any sample codes for each of them?" -- I have no idea what you are talking about. – CommonsWare Apr 22 '13 at 23:19
  • @CommonsWare ACTION_PACKAGE_CHANGED is for disabled<=> enabled, no ? I think you mean ACTION_PACKAGE_REPLACED . Question is, if the current app will be notified when it occurs, just after the upgrade. In any case, sorry for misunderstanding you about this. About the other thing, I meant about the last part of your answer. You have 2 bullets each is about a different solution. I asked if you know of samples for each of them. – android developer Apr 23 '13 at 05:55
  • @androiddeveloper: Actually, I think the right one is `ACTION_MY_PACKAGE_REPLACED`, which is new to API Level 12, further suggesting that apps' alarms are left alone on an upgrade. "I asked if you know of samples for each of them" -- https://github.com/commonsguy/cw-omnibus/tree/master/AlarmManager/Scheduled and https://github.com/commonsguy/cw-omnibus/tree/master/AlarmManager/Wakeful – CommonsWare Apr 23 '13 at 11:11
  • @CommonsWare You mean that you think that prior to API 12, alarms weren't automatically removed after an upgrade? Would using ACTION_PACKAGE_CHANGED help you in any way for overcoming this and see if something needs to be updated (for example the timing of the alarm) ? About the samples, thanks. Might be handy some day. – android developer Apr 23 '13 at 11:50
  • @androiddeveloper: "You mean that you think that prior to API 12, alarms weren't automatically removed after an upgrade?" -- that is my guess. – CommonsWare Apr 23 '13 at 11:51
  • @CommonsWare Is there maybe an alternative to using the alarmManager? One that will be able to handle such special cases? Using a service might not be a good thing as it can randomly close itself (unless it's a foreground service yet it would be a bit annoying for the user) . – android developer Apr 23 '13 at 12:10
3

No, Android won't kill scheduled alarms and they got executed as planned unless app is replaced or device is rebooted. Use broadcast receivers for these events to reschedule Alarms. There's no way to prevent Force Stop as it kills all of your app components and threads totally.

That depends on what Alarm Manager do. If it sends a broadcast, the receiver limit is 10 second.

If it starts an Activity, Service or Intent Service, there is no limit. For Activity and Services you must finish or stop it and for Intent Services until the process is finished. Be aware that you can't have another thread inside Intent Service and you'r limited to code inside the OnHandleIntent.

Also you must consider device state. If it's sleep and you are using Wake Up flag receivers won't need a wake lock, but others do. It won't take long for device to go back to sleep.

Don't waste system resources with a service because Alarm Manager do what you want.

Ali
  • 21,572
  • 15
  • 83
  • 95