As far as I know, alarms work correctly on current versions of the platform; in early versions I believe there were some issues with wake locks not being held as they should, allowing the device to fall back asleep while the alarm is being processed. Note that the app side implementation is tricky -- though the alarm manager takes care of holding a wake lock the time it is dispatching the alarm, this only works when delivering to a receiver, and the app then must be careful to acquire its own wake lock while in the onReceive() code and continue holding a wake lock for the entire time it is coming up, displaying its UI, starting its service, posting its notification, continues running, etc.
Definitely look at the current alarm clock code in the platform for an example, though each version tends to rely on newer APIs introduced in that version of the platform. If you are seeing a problem on one manufacturer's device but not on another manufacturer's but both are running the same version of the platform, this is probably a bug the manufacturer should be aware of. Re: On Tue, Aug 17, 2010 at 12:25 AM, mot12 <martin.hu...@gmail.com> wrote: > - then suddenly there's NO activity in the logs for many hours (highly > unusual) > That is very desired. If there is nothing that needs to be done, nobody is holding a wake lock, the application CPU stops running, and nothing happens. You want to be in this situation as much as possible for better battery life. Various things will wake up the CPU -- incoming network traffic, certain hardware buttons, scheduled alarms going off, etc -- at which point the kernel will internally hold a wake lock while it delivers that information to user space, and then user space must acquire its own wake lock to be able to continue running as it processes the event. > - the first activity reported after this silence is the display being > turned on manually > If the alarm was supposed to happen in this silence period, you will > find there's no Intent fired. The alarm service did no wake up the > device. > It's hard to say if the alarm did not wake up the device, or something in user space didn't keep it awake, because I don't think there is a log event for receiving an alarm and there definitely isn't one for sending a broadcast. However as of 2.1 "adb shell dumpsys activity broadcasts" will include the last N broadcasts that were sent... so you can plug in to your dev machine and collect that output and look for that broadcast and at the time stamp to determine when it was actually sent. On the other hand, if you are saying the alarm broadcast simply never happens, even once the device is turned on... that is a very different problem then any I am aware of. That is not a problem with the device sleeping at all, but simply some issue with the alarm getting lost. You can use "adb shell dumpsys alarm" to look at the currently registered alarms to see if your alarm is actually there. During development we have had bugs with alarms getting lost, but those are typically very obvious and get fixed before release. I am not aware of a final versions of the source having such a bug. Note that the "force stop" operation that task managers abuse also removes an application's alarms. -- Dianne Hackborn Android framework engineer hack...@android.com 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. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
