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
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
- 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
On Sat, Aug 21, 2010 at 12:48 AM, mot12 martin.hu...@gmail.com 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
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
'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
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
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
On Wed, Aug 18, 2010 at 12:23 AM, mot12 martin.hu...@gmail.com 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
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 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
- 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
On Aug 17, 12:25 am, mot12 martin.hu...@gmail.com 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
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
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
On Tue, Aug 17, 2010 at 10:12 AM, mot12 martin.hu...@gmail.com 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
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
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
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
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
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 martin.hu...@gmail.com wrote:
No, it happens even if the app is on the exclude list of these killer
apps. That's the
sam sam.henw...@gmail.com 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 martin.hu...@gmail.com wrote:
No, it happens even if the app is on the exclude list
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 tas...@dinglisch.net wrote:
Yeah I was thinking the thing was being killed at first, but I
Look for the following log entry:
DEBUG/Activity(xx): Process yourappservice (pid:xx) has died
In my experience this happens quite a bit on smaller devices.
On Aug 15, 8:31 am, Pent tas...@dinglisch.net wrote:
Users are giving me logs showing alarm manager alarms just not going
off across
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 joachim.pfeif...@gmail.com wrote:
Look for the following log entry:
DEBUG/Activity(xx): Process yourappservice (pid:xx) has died
In my
25 matches
Mail list logo
