5

My app uses an alarm timer to check for updates on a server every 2 minutes or so. I create a recurring timer using this:

    alarmIntent = new Intent(context, OnWakeUpReceiver.class);
    PendingIntent pIntent = PendingIntent.getBroadcast(context, 0, alarmIntent, 0);

    mAlarmManager.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), 120000, pIntent);

For the vast majority of people, this works just fine. But a small number of people report that the app suddenly stops updating itself. I put in a simple check that sees if the timer exists:

    PendingIntent pIntent = PendingIntent.getBroadcast(context, 0, alarmIntent, PendingIntent.FLAG_NO_CREATE);   

and sure enough, when the app is no longer updating, this return null, indicating no timer still exists.

My app had been controlling the alarm timer (turning it off when there was no network connection, then turning it back on when there was, and other scenarios). I thought perhaps I was somehow turning it off and not turning it back on. So I created a version where I removed every call to cancel the alarm timer. So my app no longer has any means to cancel that timer. But after just a few days time, once again the alarm timer is no longer present, and the app is not updating.

I haven't been able to get this to happen on my own systems, or have someone find a foolproof way to repeat it on theirs. I wondered if maybe the Android system was cancelling it (though that would stop my app from ever working again), but on one of the more problem systems, he said he hardly has anything running on the phone.

I didn't know if task killers might kill alarm timers as well, but I understood that after I think SDK 8, task killers couldn't do that anymore anyway, and I've been having problems with post version 8. And also on systems that do not run task killers, and have not been rooted.

I even created a "watchdog" alarm timer that ran a receiver just to check and see if the main app timer had stopped updating. What I found is that THAT timer was being cancelled as well (it gave no further "last ran" updates, and never noticed the main app had stopped).

This problem is an app killer for me. Can anyone suggest any way even to try and debug when and what is happening? Is there any log entry made ever by the system when a timer gets cancelled, whether by the system or something else? I hate that it just evaporates away without a trace.

Rob
  • 801
  • 2
  • 9
  • 16
  • does the alarm still exist when the device is power cycled? – Matt K Mar 21 '12 at 16:58
  • I never checked, but I assumed I had to create the alarm timer again each time the phone was booted. I have an OnBoot receiver that does that. – Rob Mar 21 '12 at 17:38
  • if someone goes off data plan and wireless would the app crash if it cannot make a connection to the server, or does it fail gracefully and create another alarm? – Matt K Mar 21 '12 at 20:25
  • Indeed, alarms are cleared when power is cycled. http://stackoverflow.com/questions/5616769/alarm-is-not-working-in-android-when-the-device-is-off-and-on-again – Rob Mar 21 '12 at 20:43
  • No, it is resistant to lack of data connections. I've tested that pretty thoroughly. But even it if wasn't, it's a recurring alarm timer, so it should be happening ever 2 minutes, even if the broadcast receiver that received it crashes, correct? I don't reset the timer each time (mainly because I was concerned about that very scenario, where a crash or some other problem would prevent me from resetting the alarm, and thus the app would never wake up again). – Rob Mar 21 '12 at 20:46
  • I'm not sure... seems like a good question that needs an answer to- if an app that creates a recurring alarm crashes does the recurring alarm fail as well? – Matt K Mar 22 '12 at 13:27
  • Are the alarm events considered complete when they broadcast the intent, or do they wait for that intent to be complete? I don't think there's crashing going on, because one of the persons who sees this problem the most often has never said that it is also crashing/FCing. In general, the app is pretty stable, and I tried to try/catch all most likely areas where crashes would upset the completion of its server data check. At this point all I can think to do is add *another* alarm timer as a 1 minute heartbeat check, and see if I can tell if they all die at the same time. FWIW... – Rob Mar 26 '12 at 14:07
  • Ok, I've double checked that when I set the alarm timer, it's to a valid time and interval, and it is. And I've double checked that when "it" happens, both my normal timer and my backup (watchdog) timer are cancelled, and they are. But I still have no unknown crashes, and no other indication anything is wrong except the timers just suddenly stop. Is there NO way in android to find out what/why your timers were cancelled?? – Rob Apr 01 '12 at 17:12
  • I'm close to wits end here. Does anyone know of an open source example that uses recurring timers to accomplish some task? I can then at least compare how I do things with how it does things. I'm willing to offer money to whoever can help me find what is causing this... – Rob Apr 04 '12 at 16:06

1 Answers1

1

I can't say this is the complete answer, but these 2 changes together seem to have stopped MUCH of the cancelled alarms:

1) I was taking the pending intent and cancelling that, as opposed to calling cancel() on the alarm manager when I had to cancel the alarm for whatever reason. Over time, I don't know if that managed to confuse the alarm manager or something, but it probably wasn't good. Now I cancel the alarm manager as well as the pending intent.

2) One of my users mentioned how when they hit Clear RAM, it disables my service. Apparently some phones come with a task manager that gives them a nice shiny button that lets them clear out memory/RAM. The button even says clearly that pressing it will cause some apps to stop working...and still the users mash it. I don't know how exactly, but this appears to kill my alarms MOST of the time. So I put out a big notice for people to stop doing that, and since then things have really quieted down. The sucky side is that I won't ever really know the next time I get a disabled alarm if the user hit the magic button of death, or if something really went wrong.

But either way, things are better now.

Rob
  • 801
  • 2
  • 9
  • 16