11

The alarms set by my app using AlarmManager are cleared if

  1. The user force closes my app in the settings.
  2. Some task killer app auto-killed my app process.
  3. Android itself killed my app, because of the need of memory for front apps.

Please tell me how do I detect it? rather how to set my alarms so that all these cases dont affect my alarms.

John Nash
  • 315
  • 2
  • 6

1 Answers1

31

The user force closes my app in the settings.

Yes, this clears alarms.

Some task killer app auto-killed my app process.

This does not clear alarms on any recent version of Android.

Android itself killed my app, because of the need of memory for front apps.

This does not clear alarms.

Please tell me how do I detect it?

Maintain a record of when your alarm last occurred (e.g., in SharedPreferences). When your code runs (e.g., LAUNCHER activity is started), check the last-alarm time. If it was a long time ago, you know that your alarms were cleared, and so you need to reschedule them.

rather how to set my alarms so that all these cases dont affect my alarms.

This is not possible. There are few cases where the alarms actually are cleared (reboots and Force Stop), and there is nothing you can do to prevent your alarms from being cleared in those cases.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thank you commonsware, for the complete and elaborative answer! – John Nash Dec 31 '12 at 08:20
  • What if the user clears the app's data? Won't we loose track of the record? – Krishnaraj Oct 19 '15 at 18:35
  • @Krishnaraj: Yes. Hope that your user does not do that. – CommonsWare Oct 19 '15 at 18:42
  • @CommonsWare is the alarm also removed when the user clears data? – Krishnaraj Oct 19 '15 at 18:48
  • @Krishnaraj: I do not know, sorry. – CommonsWare Oct 19 '15 at 18:49
  • Ok, just tested on Android 4.1 and it does look like the alarms are also removed if the user clears data. – Krishnaraj Oct 19 '15 at 18:52
  • @CommonsWare Alarms set by my app using AlarmManager are cancelled when user clear my App from recent app list. Is normal behaviour? If it is normal behaviour then how System Alarm App working correctly? Please help. Thanks. – bCliks Apr 08 '16 at 10:16
  • 3
    @bCliks: "Is normal behaviour?" -- no. That is the behavior normally associated with "Force Stop" in Settings. Occasionally, a device manufacturer does something like you describe. When I get the opportunity, I yell at them. "If it is normal behaviour then how System Alarm App working correctly?" -- the device manufacturer can do whatever the device manufacturer wants, as it is their device. – CommonsWare Apr 08 '16 at 11:21
  • @CommonsWare Oh. Thanks for clarifying that. – bCliks Apr 08 '16 at 12:09
  • @MuhammadBabar: I forget, sorry! – CommonsWare Nov 14 '16 at 11:24
  • @CommonsWare no worries. Thanks – Muhammad Babar Nov 14 '16 at 12:44
  • Do you know if an app crashing has the same effect as a force stop? As in, if my app crashes, and isn't restarted, will it still receive an alarm I set before the crash? – TheWanderer Sep 23 '19 at 19:18
  • 2
    @TheWanderer: AFAIK, crashes will not affect alarms. You can confirm this by checking `adb shell dumpsys alarm` before and after a crash (such as a manually-generated `NullPointerException` for experimentation purposes) to confirm the alarm status. – CommonsWare Sep 23 '19 at 23:05
  • @CommonsWare Is there any way to set the alarms again in case of force stop from android setting screen? I tried to catch the UncaughtExceptionHandler in my activity but I am not getting this exception when I am doing force stop. – Sandeep Agrawal Jan 03 '20 at 10:19
  • @SandeepAgrawal: There is no exception. Your process is terminated. All you can do is keep track of what alarms you need in a file, database, `SharedPreferences`, etc., and restore them when if and your app runs again, if you determine that those alarms are not working as they should. In general, in modern Android, trying to do scheduled background work like this is something that I recommend that developers avoid where possible. – CommonsWare Jan 03 '20 at 11:55