[android-developers] Re: Disappearing Alarms
Was this ever resolved? I exactly the same problem with Droid-X users. I set an Alarm using RTC_WAKEUP and the first thing the Alarm Receiver does is log a message and then grab the WakeLock. The Alarm Broadcast does not go off and the LOG message is not shown. This seems to affect only a few users, but only if they are not connected to power. Truly frustrating for a developer to solve as it appears to be a hardware/device issue. -- 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
[android-developers] Re: Disappearing Alarms
> I exactly the same problem with Droid-X users. > > I set an Alarm using RTC_WAKEUP and the first thing the Alarm Receiver does > is log a message and then grab the WakeLock. > > The Alarm Broadcast does not go off and the LOG message is not shown. This > seems to affect only a few users, but only if they are not connected to > power. > > Truly frustrating for a developer to solve as it appears to be a > hardware/device issue. I don't know if the underlying problem received a fix, but I have not had users report it since I implemented refreshing of the alarm every 20 minutes. Bit silly though :-) Pent -- 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
[android-developers] Re: Disappearing Alarms
'Often'? But when, exactly? Is there some document somewhere that tells us when the system acquires and releases wake locks? Is there some way we can tell when other apps acquire and release them? This whole thread has been an excellent illustration of why this information is valuable for Android developers. On Aug 20, 1:19 pm, Dianne Hackborn wrote: > On Wed, Aug 18, 2010 at 12:23 AM, mot12 wrote: > > That would be the case if the alarm service broadcasts the intent and > > no wake lock is acquired. > > The platform does hold a wake lock while broadcasting an alarm, and always > has. > > > I was talking about a different situation in which the broadcast of > > the alarm intent doesn't happen at the designated time because the > > device is in some funky state. The broadcast happens later, when the > > user manually turns the display on. (After that, the receiving app > > should, of course, acquire a wake lock to process the alarm action but > > that is not a problem if properly coded). The problem is that the > > broadcast of the alarm intent does not happen at the time for which > > the alarm was set (otherwise I would see it in the logs, correct?). > > And that is a major problem for alarm clocks. > > This is exactly what you will see if someone is not holding a wake lock when > they should. The CPU goes to sleep, and won't run again until something > else wakes it up and holds a wake lock. Turning on the screen on does this. > > > All users have reported that the problem goes away if the phone > > remains plugged in. > > Often having a device plugged in will cause a wake lock to be held for the > duration. Definitely, having the screen on (such as when the clock is > displayed while in a desk dock) will keep a wake lock held. > > -- > 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
[android-developers] Re: Disappearing Alarms
Well, thanks for your help on this. I have been telling users to either - keep the phone plugged in - or use a night display mode of my alarm app that keeps the display alive over night (as long as they don't manually shut off the display, this also ensures the phone stays alive over night) Good to know that the suspect log entries don't come from the stock platform. I will keep asking users who report problems what platform they run and if I do have any indication that the stock platform is affected, I will post that here. -- 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
Re: [android-developers] Re: Disappearing Alarms
On Sat, Aug 21, 2010 at 12:48 AM, mot12 wrote: > - why does the log not show the alarm intent being FIRED? > The stock platform does not log anything when an alarm is broadcast. > - why does the stock alarm suffer from the same problem? > I know that early releases of Android had some problems with the alarm clock due to user space not doing the right things with wake locks... but this is not an issue I am aware of in the current platform, specifically on Droid. > Here's an example one of my users sent me: > The alarm is set for 08:45. > The user stopped using the device at 02:15. > There are some log entries until 02:54, then NOTHING until 11:46 when > the screen is turned on. > The log entry of the alarm intent being received happens at > 11:46:45.319. This is is the first line in my OnReceive. > What are these things in the log? 03-03 02:32:48.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:32:48.530 I/usbd( 1078): main(): call select(...) That is not something printed by the stock platform, certainly not on Droid running 2.2 (I just checked). If these people are using a Droid (I don't recall at this point who said their users were running what), then I would start to suspect that they have installed a custom build that is broken. If this is some other device that isn't running stock Android, they would perhaps be better off reporting the bug to the hardware manufacturer since it appears to be a bug in the device (and impacts features built in to the device). Also I don't know if this is your app, but somebody is using the old Service.setForeground() API that no longer does anything and they thus could get killed: 03-03 02:33:57.647 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService Anyway, at this point someone needs to show this problem happening on the stock platform. If it is not a bug in the stock platform, there is not much I can do to help. And honestly, if your users have a device where the alarm clock built into it doesn't work... and your alarm clock app doesn't work in the same way... how can they expect yours to work any better? It is an issue with their device. -- 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
[android-developers] Re: Disappearing Alarms
- why does the log not show the alarm intent being FIRED? - why does the stock alarm suffer from the same problem? Of course I hold my own wake lock as soon as I receive the alarm intent. But the intent never gets fired (on some devices, in some situations). Here's an example one of my users sent me: The alarm is set for 08:45. The user stopped using the device at 02:15. There are some log entries until 02:54, then NOTHING until 11:46 when the screen is turned on. The log entry of the alarm intent being received happens at 11:46:45.319. This is is the first line in my OnReceive. Several users have sent me something like this (I can provide a more complete log) and they all have the same last lines, i.e. wl127x- rfkill.0/rfkill bla bla which seems to come from a device driver. After that, the phone goes into "deep sleep" and no alarm intents are being sent. Martin 03-03 02:31:40.639 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:31:40.663 I/dalvikvm( 2937): Debugger thread not active, ignoring DDM send (t=0x41504e4d l=38) 03-03 02:31:40.678 I/dalvikvm( 2937): Debugger thread not active, ignoring DDM send (t=0x41504e4d l=58) 03-03 02:31:40.749 D/JuiceDefender.Db( 2937): Stats for last 48 hours: 147% 03-03 02:32:48.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:32:48.530 I/usbd( 1078): main(): call select(...) 03-03 02:33:57.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:33:57.530 I/usbd( 1078): main(): call select(...) 03-03 02:33:57.647 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:35:05.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:35:05.530 I/usbd( 1078): main(): call select(...) 03-03 02:36:14.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:36:14.530 I/usbd( 1078): main(): call select(...) 03-03 02:36:14.538 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:37:22.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:37:22.530 I/usbd( 1078): main(): call select(...) 03-03 02:38:31.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:38:31.530 I/usbd( 1078): main(): call select(...) 03-03 02:38:31.546 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:39:39.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:39:39.530 I/usbd( 1078): main(): call select(...) 03-03 02:40:47.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:40:47.530 I/usbd( 1078): main(): call select(...) 03-03 02:40:47.546 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:41:56.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:41:56.530 I/usbd( 1078): main(): call select(...) 03-03 02:41:56.624 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:43:04.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:43:04.530 I/usbd( 1078): main(): call select(...) 03-03 02:44:13.522 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:44:13.522 I/usbd( 1078): main(): call select(...) 03-03 02:44:13.546 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:45:21.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:45:21.530 I/usbd( 1078): main(): call select(...) 03-03 02:46:30.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:46:30.530 I/usbd( 1078): main(): call select(...) 03-03 02:46:30.538 W/Service ( 2404): setForeground: ignoring old API call on com.wsandroid.Core.BaseService 03-03 02:47:38.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:47:38.530 I/usbd( 1078): main(): call select(...) 03-03 02:48:47.530 I/usbd( 1078): process_usb_uevent_message(): buffer = change@/devices/platform/wl127x-rfkill.0/rfkill/rfkill0 03-03 02:48:47.530 I/usbd( 1078): main():
Re: [android-developers] Re: Disappearing Alarms
On Wed, Aug 18, 2010 at 12:23 AM, mot12 wrote: > That would be the case if the alarm service broadcasts the intent and > no wake lock is acquired. > The platform does hold a wake lock while broadcasting an alarm, and always has. > I was talking about a different situation in which the broadcast of > the alarm intent doesn't happen at the designated time because the > device is in some funky state. The broadcast happens later, when the > user manually turns the display on. (After that, the receiving app > should, of course, acquire a wake lock to process the alarm action but > that is not a problem if properly coded). The problem is that the > broadcast of the alarm intent does not happen at the time for which > the alarm was set (otherwise I would see it in the logs, correct?). > And that is a major problem for alarm clocks. > This is exactly what you will see if someone is not holding a wake lock when they should. The CPU goes to sleep, and won't run again until something else wakes it up and holds a wake lock. Turning on the screen on does this. > All users have reported that the problem goes away if the phone > remains plugged in. > Often having a device plugged in will cause a wake lock to be held for the duration. Definitely, having the screen on (such as when the clock is displayed while in a desk dock) will keep a wake lock held. -- 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
[android-developers] Re: Disappearing Alarms
That seems like a terrible solution though. I think we do have a real problem here as this has been confirmed by many users and you can also google the problem and you will see that the stock alarm is not reliable on some devices. As Diane hinted at, this is probably a firmware issue. It would be nice if we can get a developer with one of the affected devices to pull a little weight here by confirming this. For example, a Motorola Droid user. Set the stock alarm to ring in the morning, then turn off wireless over night (flightmode) and turn off the display. Don't use a charger or dock. On some days the alarm will fail, at least this is what my users report. If we can get someone to submit a log file, we would at least have a confirmed problem. But then what? Do we try to run after the hardware developers? Doesn't seem to be Google's issue. Or do we do workarounds like Pent suggests? I can already see the comments for you app though: "keeps firing up every 10 minutes draining battery, 1 star, learn how to program, uninstalled." And you will get this even if you do explain what and why you are doing it because many users won't pay attention to that. Martin -- 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
[android-developers] Re: Disappearing Alarms
Initial user reports indicate that setting a repeating 10 minute alarm in the background whose sole task is to 'refresh' the main alarm might be a viable workaround. i.e. repeating this line: alarmManager.set( AlarmManager.RTC_WAKEUP, alarmLastTime, alarmPendingIntent ); Now to see how far we can increase that 10 minutes without the problem coming up again. Pent -- 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
[android-developers] Re: Disappearing Alarms
That would be the case if the alarm service broadcasts the intent and no wake lock is acquired. I was talking about a different situation in which the broadcast of the alarm intent doesn't happen at the designated time because the device is in some funky state. The broadcast happens later, when the user manually turns the display on. (After that, the receiving app should, of course, acquire a wake lock to process the alarm action but that is not a problem if properly coded). The problem is that the broadcast of the alarm intent does not happen at the time for which the alarm was set (otherwise I would see it in the logs, correct?). And that is a major problem for alarm clocks. All users have reported that the problem goes away if the phone remains plugged in. -- 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
Re: [android-developers] Re: Disappearing Alarms
On Tue, Aug 17, 2010 at 10:12 AM, mot12 wrote: > Thanks for weighing in, Dianne. I misspoke: Actually the alarm > broadcast happens immediately after the display is turned on. But that > may be minutes or even hours after the time for which it was > scheduled. So that has nothing to do with the wake lock since that > would come into play only after the alarm broadcast was received. > That exactly has to do with a wake lock. If the alarm goes off, and no wake lock gets held, the CPU will not run. If nothing else happens to acquire the wake lock for those hours, no code will run. It is only until a wake lock is acquired (which happens when the screen is on) that the CPU can run. Then the question is what code is not holding a wake lock and allowing the CPU to stop running: the kernel driver, the platform's alarm manager impl, or the application code when it receives the broadcast and is doing its resulting work. -- 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
[android-developers] Re: Disappearing Alarms
> 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. Thanks for weighing in, Dianne. I misspoke: Actually the alarm broadcast happens immediately after the display is turned on. But that may be minutes or even hours after the time for which it was scheduled. So that has nothing to do with the wake lock since that would come into play only after the alarm broadcast was received. Martin mobitobi Gentle Alarm Sleep Now -- 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
Re: [android-developers] Re: Disappearing Alarms
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 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
[android-developers] Re: Disappearing Alarms
On Aug 17, 12:25 am, mot12 wrote: > The alarm service has many pitfalls but even if programmed correctly, > it doesn't work reliably on some devices. The standard alarm clock > doesn't run reliably on those same devices; that's a strong hint that > something is wrong. We've had similar discussions a while back here. At least how I understood it, the skinny was that services can become victim of Android's efforts to manage resources and that that's the way it's supposed to work. In that sense, things are perfectly fine. It's just that implementing alarms seems like a bad idea. I've since backed off from including features such as alarms (secondary to my apps) or dynamic app widgets (suffer similar fate), because they seem impossible to support, at least at this point. -- 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
[android-developers] Re: Disappearing Alarms
> - then suddenly there's NO activity in the logs for many hours (highly > unusual) > - the first activity reported after this silence is the display being > turned on manually I recognize that description but I'd put it down to just being in deep sleep during the night. Pent -- 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
[android-developers] Re: Disappearing Alarms
The alarm service has many pitfalls but even if programmed correctly, it doesn't work reliably on some devices. The standard alarm clock doesn't run reliably on those same devices; that's a strong hint that something is wrong. Here's what I observed in these devices after pulling the log: - the display is being turned off or goes off by itself and there is little activity for a while - then suddenly there's NO activity in the logs for many hours (highly unusual) - 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. -- 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
[android-developers] Re: Disappearing Alarms
You may also want to look into wake locks: http://developer.android.com/intl/de/reference/android/os/PowerManager.html to help avoid your service getting snoozed by the system. On Aug 15, 12:13 pm, Pent wrote: > Yeah I was thinking the thing was being killed at first, but I have > long-term logs going to SD > and I would've seen it happen. > > Pent > > On Aug 15, 5:36 pm, JP wrote: > > > Look for the following log entry: > > DEBUG/Activity(xx): Process (pid:xx) has died > > In my experience this happens quite a bit on smaller devices. > > > On Aug 15, 8:31 am, Pent wrote: > > > > Users are giving me logs showing alarm manager alarms just not going > > > off across many devices and OS versions. > > > > I log any calls to the alarm manager. They seem to just disappear into > > > a black hole sometimes. I usually have them chained. One goes off, I > > > do a check, then set another (usually a few hours). They're set by a > > > service. > > > > Intent ai = new Intent( this, ReceiverStaticInternal.class ); > > > ai.setAction( Keys.ActionCodes.ACTION_ALARM ); > > > > alarmPendingIntent = PendingIntent.getBroadcast( > > > this, > > > 0, > > > ai, > > > PendingIntent.FLAG_CANCEL_CURRENT > > > ); > > > alarmLastTime = some time in the future... > > > > alarmManager.set( AlarmManager.RTC_WAKEUP, alarmLastTime, > > > alarmPendingIntent ); > > > > I'm checking for alarmLastTime being in the past. > > > > Anyone else ? Any ideas ? > > > > Pent -- 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
Re: [android-developers] Re: Disappearing Alarms
sam wrote: >I've been having similar issue with my app, didn't think to query for >specific phones, thanks for the suggestions! Will report back with >more info... > >On Aug 17, 8:21 am, mot12 wrote: >> No, it happens even if the app is on the exclude list of these killer >> apps. That's the first thing I pointed out to users. But it happens >> only on some devices. > >-- >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 -- 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
[android-developers] Re: Disappearing Alarms
I've been having similar issue with my app, didn't think to query for specific phones, thanks for the suggestions! Will report back with more info... On Aug 17, 8:21 am, mot12 wrote: > No, it happens even if the app is on the exclude list of these killer > apps. That's the first thing I pointed out to users. But it happens > only on some devices. -- 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
[android-developers] Re: Disappearing Alarms
No, it happens even if the app is on the exclude list of these killer apps. That's the first thing I pointed out to users. But it happens only on some devices. -- 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
[android-developers] Re: Disappearing Alarms
> I have seen this on a number of devices if the phone is idle for a > long time or if the display gets shut off manually. My app has > ~100,000 users so I am quite sure I am not imagining it. My phones (N1 > and Galaxy) are not affected, but I get a lot of these reports from > Droid users. > > Here's a simple test I would recommend: > - tell your users to set the stock alarm. If you experience the same > situation that I talk about, you will find the stock alarm fails, too. > - tell your users to keep the phone plugged in. Your alarm will no > longer fail. > > If these tests show my experience is relevant to your problem, I have > a number of suggestions what else you can do. Thanks for the info, will make inquiries. Pent -- 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
[android-developers] Re: Disappearing Alarms
> You sure they're not killing your service with a task killer? I am seeing the service handling other incoming intents before and after the alarm time. If it was recreated that would be logged. Pent -- 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
[android-developers] Re: Disappearing Alarms
I have seen this on a number of devices if the phone is idle for a long time or if the display gets shut off manually. My app has ~100,000 users so I am quite sure I am not imagining it. My phones (N1 and Galaxy) are not affected, but I get a lot of these reports from Droid users. Here's a simple test I would recommend: - tell your users to set the stock alarm. If you experience the same situation that I talk about, you will find the stock alarm fails, too. - tell your users to keep the phone plugged in. Your alarm will no longer fail. If these tests show my experience is relevant to your problem, I have a number of suggestions what else you can do. -- 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
[android-developers] Re: Disappearing Alarms
Yeah I was thinking the thing was being killed at first, but I have long-term logs going to SD and I would've seen it happen. Pent On Aug 15, 5:36 pm, JP wrote: > Look for the following log entry: > DEBUG/Activity(xx): Process (pid:xx) has died > In my experience this happens quite a bit on smaller devices. > > On Aug 15, 8:31 am, Pent wrote: > > > Users are giving me logs showing alarm manager alarms just not going > > off across many devices and OS versions. > > > I log any calls to the alarm manager. They seem to just disappear into > > a black hole sometimes. I usually have them chained. One goes off, I > > do a check, then set another (usually a few hours). They're set by a > > service. > > > Intent ai = new Intent( this, ReceiverStaticInternal.class ); > > ai.setAction( Keys.ActionCodes.ACTION_ALARM ); > > > alarmPendingIntent = PendingIntent.getBroadcast( > > this, > > 0, > > ai, > > PendingIntent.FLAG_CANCEL_CURRENT > > ); > > alarmLastTime = some time in the future... > > > alarmManager.set( AlarmManager.RTC_WAKEUP, alarmLastTime, > > alarmPendingIntent ); > > > I'm checking for alarmLastTime being in the past. > > > Anyone else ? Any ideas ? > > > Pent > > -- 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
[android-developers] Re: Disappearing Alarms
Look for the following log entry: DEBUG/Activity(xx): Process (pid:xx) has died In my experience this happens quite a bit on smaller devices. On Aug 15, 8:31 am, Pent wrote: > Users are giving me logs showing alarm manager alarms just not going > off across many devices and OS versions. > > I log any calls to the alarm manager. They seem to just disappear into > a black hole sometimes. I usually have them chained. One goes off, I > do a check, then set another (usually a few hours). They're set by a > service. > > Intent ai = new Intent( this, ReceiverStaticInternal.class ); > ai.setAction( Keys.ActionCodes.ACTION_ALARM ); > > alarmPendingIntent = PendingIntent.getBroadcast( > this, > 0, > ai, > PendingIntent.FLAG_CANCEL_CURRENT > ); > alarmLastTime = some time in the future... > > alarmManager.set( AlarmManager.RTC_WAKEUP, alarmLastTime, > alarmPendingIntent ); > > I'm checking for alarmLastTime being in the past. > > Anyone else ? Any ideas ? > > Pent -- 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