ACQUIRE_CAUSES_WAKEUP not working on some devices

Put your problem here if it does not fit any of the other categories.

ACQUIRE_CAUSES_WAKEUP not working on some devices

Postby splunchy » Wed Oct 27, 2010 10:49 am

I wrote an application that makes use of alarm events scheduled in the AlarmManager.

The AlarmManager event triggers a BroadcastReceiver. In its onReceive() method, I implemented a PowerManager.WakeLock in order to activate the screen and to keep the CPU running.

Code: Select all
      WakeLock wl = pm.newWakeLock(
            PowerManager.FULL_WAKE_LOCK |
            PowerManager.ACQUIRE_CAUSES_WAKEUP |
            PowerManager.ON_AFTER_RELEASE,
            "MyLock");
                wl.acquire(10000);
      WakeLock wl_cpu = pm.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "MyCpuLock");
                wl_cpu.acquire(10000);


So these WakeLocks are automatically released after 10 seconds. That is also the maximum time a Receiver is allowed to take for the onReceive() method.
During these 10s, the BroadcastReceiver starts a Service that handles (amongst other things) a MediaPlayer object in order to private an alarm sound. This Service itself holds a WakeLock (same WakeLocks as the Receiver above), but acquired them without time limit.

So, my problem.... It works on all virtual machines. And it works well on my HTC Desire. But there seem to be some devices that fail to wake up. As far as I know, it mostly appeared on Samsung Galaxy S phones with Android-2.1-update1.
Is that a known bug so far? Any ideas? I found nothing on the web treating this problem...

Thank you!
Fabian
splunchy
Freshman
Freshman
 
Posts: 4
Joined: Wed Oct 27, 2010 10:19 am

Top

Re: ACQUIRE_CAUSES_WAKEUP not working on some devices

Postby splunchy » Mon Nov 08, 2010 2:43 pm

So in the mean time, I found the cause. But it's not related to the WakeLock but to the AlarmManager. It seems it does not work very reliable in the RTC_WAKEUP mode on some devices.

HERE IS WHAT I FOUND OUT: http://www.netzpurist.de/2010/11/samsung-i9000-galaxy-s-%E2%80%93-critical-firmware-bug-regarding-time-events/

In the past, many Samsung i9000 Galaxy S users reported a critical bug. Sometimes, the alarm just does not go off until they activate the display. This missbehaviour appears on every i9000 phone with Android 2.1 and is caused by a critical firmware bug, as I figured out.

AlarmDroid makes (like many other applications where events are triggered time-based) use of Android’s AlarmManager. This built-in class is used to trigger certain events at certain times. In this way, it is possible to wake up the device at a given time to perform some actions. It’s implemented this way in order to prevent battery consumption. E.g. AlarmDroid also schedules its alarm events using this mechanism. So there is NO battery consumption until the alarm goes off. And the same while AlarmDroid remains in snooze mode. And the most important aspect: It is intended to work even while the device is sleeping.

So as some users reported, the AlarmManager does not work as well as it should on their devices. This bug was already known in the past on the Motorola Milestone, they fixed it later on within a firmware upgrade.

A brief experiment
In the last days, an AlarmDroid user (Thank you, Davyd!) was so kind to participate in a little experiment. I prepared a small service-based application that schedules a repeating alarm to the AlarmManager, one event per minute. Every time the event receiver is called, it saves the current time (in milliseconds) to a log file, in order to compare preset time with the real time, which is expected to be delayed in some cases. For comparison, I ran the same test on my HTC Desire.

The results
I measured the time on which the alarm went off and the corresponding preset time, and plotted both against each other. If all alarms were fired up at the right time, it should look highly linear. The first figure shows the results of the HTC Desire. Since I never noticed the mentioned bug on my phone, I expect a linear graph. And indeed, it looks like it should. Every alarm went of at the correct time. The maximum delay was about 614ms, the mean delay about 207ms.
Image

On the contrary, the results of the i9000 Galaxy S deviate considerably from this test:

Image
Here, 33 of 480 events (6.9%) failed! The plot above shows a typical sample. Event 1 and 2 are delayed 3 minutes in each case. Event 3 has a delay of 2 minutes, event 4 of 1 minute and event 5 finally woke up the CPU correctly. So event 1, 2, 3 and 4 failed to wake up the CPU.

Now, the very odd thing is that event 2, 3, 4 and 5 were received at the same time, like expected, but event 1 was already received at the time on which actually event 4 should be received. This makes no sense at all and needs to adjust our speculation. Possibly, the CPU went on, but did not last until the event’s receive method was completed, although I used a «PARTIAL_WAKE_LOCK» to keep the CPU running.

A workaround
So in the end, we need a workaround in order to treat this problem. Because the CPU woke up on the 4th try at the latest, I changed my test application in the following way. I added a second alarm event receiver that holds an own partial wake lock. Before the actual alarm event should be go off, the second receiver is triggered 10 times, e.g. 10s before, 9s before, n seconds, …. and 1s before. Every receiver holds a wakelock for a duration of n+1 seconds. So most likely, the CPU will already be awake for a few seconds when the final alarm is fired.
Image

This works pretty well. I repeated the experiment last night with the modification described above, and here are the results:

* Fails: 0 / 375 (0%)
* Maximum delay: 194ms
* Mean delay: 22ms

So with this workaround, it works very accurate and reliable!
splunchy
Freshman
Freshman
 
Posts: 4
Joined: Wed Oct 27, 2010 10:19 am

Re: ACQUIRE_CAUSES_WAKEUP not working on some devices

Postby splunchy » Sun Nov 14, 2010 11:00 am

... and there are still more devices with similar AlarmManager "bugs":

http://www.netzpurist.de/2010/11/samsung-gt-i5500-with-android-2-1-update1-alarmmanager-not-suitable/

Never buy a Samsung smartphone... :|
splunchy
Freshman
Freshman
 
Posts: 4
Joined: Wed Oct 27, 2010 10:19 am

Top

Return to Other Coding-Problems

Who is online

Users browsing this forum: Google [Bot] and 10 guests