I noticed the same thing. I looked at the AlarmManger code and it stores its data in in-memory arrays that are not persisted (nor publicly accessible) , even more the pending intents that the AlarmManager refers to are also lost when the device is restarted or the application is uninstalled. (This is actually what happens when you uninstall - it is the pending intent that gets lost not the AlarmManager registration). It appears that the only way to deal with pending alarms is to reschedule them.
What I did in my application is to register for 3 global events - in my case Intent.ACTION_TIME_CHANGED (which occurs when the phone time gets updated to some value manually or by syncing with the cell tower), Intent.ACTION_TIMEZONE_CHANGED, and Intent.ACTION_BOOT_COMPLETED. In response to any of the those events I remove all pending alarms and reschedule them again reading the schedules from my own storage. This takes care of the device reboots and when the time zone changes (for example the user takes a plane from one time zone to another). As it turns out if your device is set to auto sync its time from the cell tower (which is the default setting) the autosync occurs many times during the day (my guess is when switching from cell towers to another). Responses to the ACTION_TIME_CHANGED will restore the schedule. This is not an ideal solution but it is good enough for my case. (The AlarmClock application that comes with the Android Source uses a similar approach) Stefan On Feb 28, 10:58 am, Mariano Kamp <[email protected]> wrote: > Hi, > > as far as I see scheduled alarms are lost when upgrading an application. > As this seems to be an un-install and re-install I can understand what. > > What is the best way to cope with that? > > When an application is upgraded it doesn't need to be launched by the > user, so it is not the most sensible approach to use the "onCreate" method > of the launcher activity. Is there any other life-cycle event I can tap > into? > > If that is not the case, then I would think a not-too-bad-way of handling > this is to hook into the onCreate method on my launch activity, an create a > PendingIntent with the NO_CREATE [1] flag and schedule it again with the > AlarmManager. That shouldn't result in any change to the existing schedule, > if it exists, and should create the schedule when the application is > installed for the first time or after an upgrade. > > It's not elegant, as it expects the user to open the app after upgrading. > It's not a major PITA today as the current Market expects the user to > upgrade each app by hand and it is not unlikely that the user starts it, but > for the future I would expect that the Market makes automatic mass-upgrades > possible. > > Also it is not too nice to handle this logic in the UI. Furthermore it > doesn't seem elegant to bother the AlarmManager with a new PendingIntent > every time the app is launched. Is there anyway to query the AlarmManager > for scheduled events, like with dumpsys alarm on the command line? > > Better ideas? > > Cheers, > Mariano > > [1]http://developer.android.com/reference/android/app/PendingIntent.html... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
