At least as far as the alarms set in the Alarm Clock app go, PendingIntents do in fact resurface after a reboot. At least as long as you make sure to have the device up and running in time for the alarm to go off. Those alarms and their on/off state are persisted through the database and re-registered with the AlarmManagerService when the Alarm Clock app comes up following a reboot.
The only gotcha I can think of is that you need to make sure to turn off the device in the same timezone as you want to wake up in. Otherwise the device will power up and sound the alarm that many hours early or late depending on how many timezones you've crossed and in which direction. Probably if daylight savings go into or out-of effect while the device is off you'd get a similar result. Setting the time automatically through NITZ, NTP, GPS or other mechanism will may also cause problems. Anyway, now that I know that Gogle never intended for Android to work this way I'll go ahead and make the changes which I assume will be submitted through the usual channels. Thanks, On 15 Sep, 02:10, Dianne Hackborn <[email protected]> wrote: > (Oh also such an alarm would have very different semantics than current ones > because all existing alarms do not persist across a boot, and then rely on > sending to a PendingIntent that can not surface across a reboot.) > > On Mon, Sep 14, 2009 at 5:09 PM, Dianne Hackborn <[email protected]>wrote: > > > > > It is there to bring the device out of deep sleep (that is when no wake > > locks are held), not to turn it on when it is off. > > > If you want to allow the device to turn on while off, a new kind of wakeup > > alarm will need to be defined. This is not currently feature that is > > supported by the platform. > > > On Mon, Sep 14, 2009 at 1:22 PM, /dev/null <[email protected]> wrote: > > >> I thought that the intention for the RTC_WAKEUP alarm was to wake up a > >> sleeping or powered off device. I was a bit surprised to find out that > >> it was not only the Alarm Clock application that registered RTC_WAKEUP > >> alarms, but also the Calendar does this to drive its synchronization. > >> I assume the GMail application uses the same technique. > > >> This means that I cannot use RTC_WAKEUP alarms on my hardware to > >> program an RTC to power on a device on an alarm. Because if I did it > >> would also power up the device when a synchronization activity is > >> scheduled, the device would stay powered up, the battery power would > >> eventually be exhausted, possibly long before the alarm set in the > >> Alarm Clock app is reached. > > >> Is this the intended behaviour, or am I assuming to much that the > >> intention for Android was to support alarms to power up a device and > >> sound an alarm as many classic feature phones have supported almost > >> since time immemorial? If this wasn't intended then there needs to be > >> a new RTC category of alarms that does power up the device, and only > >> alarms set in the Alarm Clock or a Calendar event with a reminder can > >> trigger it. > > >> TIA > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
