Acquiring PARTIAL_WAKELOCK every 10 seconds

Question

Is there any problem with an application which acquires a partial wake lock at 10 second intervals. My use-case for this is being able to continually monitor the user's movement via the device accelerometer. Basically, I have a Service which is invoked by an alarm every 10 seconds.

This Service acquires a wake lock, gets some readings from the accelerometer to determine current movement status, and then releases the wake lock. The total lifetime of the service is around 4 seconds.

My understanding is that this leads to the device being kept awake for approx 24 seconds in each minute. While not ideal, I would hope that this is still better practice than holding a constant wake lock for the entire lifetime of my application.

On the other hand, is it possible that the act of acquiring and releasing the wake lock in such a short space of time is just as bad for battery life?

Any input is appreciated.

Walsh

Why do you need to wake the screen to access the accelerometer? – Tentacle

I'm not waking the screen, just the CPU. I'm using a PARTIAL_WAKELOCK. I wake the device every 10 seconds to check for movement, take action if necessary, and then put it back to sleep – Walsh

I just don't think you need a wake lock for your situation. If your Service is invoked when the Alarm goes off, the cpu is processing it. You don't have to tell the system that your application wants to use the cpu... – Tentacle

Yes, the AlarmManager will wake the device up. That said, I doubt the CPU will get much sleep at this interval. – Aport

This is going to have a large negative impact on your users' battery life. The extent of this may vary drastically from device to device. Holding a wake lock for 4 seconds every 10 seconds means you are explicitly keeping the device awake 40% of the time, all the time. – Laughton

@adamp: Even more than 40%. I don't believe the CPU will go back to sleep immediately after the service is done doing its thing, although I don't want to state that as a fact. – Aport

@Laughton Your assertion that the device will be awake 40% of the time makes sense to me and this is close to the actual wake time of the device after some testing. While this is not ideal, surely it is better that the device is awake 40% of the time than 100% of the lifetime of my application? – Walsh

Yes, but the closer that gets to 0%, the happier your users will be. Is what your app does with that battery power more important than your users having enough charge left to make a phone call at the end of a day? :) – Laughton

@Laughton solid advice, thanks again – Walsh

Answer 1

As the comments have indicated, this is really not a good idea. As in "one-star ratings on the Market" type of a not-good idea.

The accelerometer is designed to be used by a running activity (e.g., a game), and that's about it. It is absolutely not designed to be used in the mode in which you are trying.

You are also assuming that the device will fall back asleep immediately upon your release of the WakeLock. That may or may not be true. I would suspect that you will find that you are causing the CPU to be powered on for significantly more than 40% of the available time, even if you are only mandating it to be on for 40%.

I strongly encourage you to view Jeff Sharkey's presentation on power usage in Android from the 2009 Google I|O conference.

Crock

Thanks for this confirmation. I had a fair idea that this would be the case. I've seen that presentation before in one of your earlier answers but thanks anyway for the link, it's good advice! The only reason I am attempting to achieve this is to implement a GPS tracking application that stops invoking the gps while the user is not moving (in an attempt to save battery, no less). Alas, it seems obvious that this approach will most likely use as much battery as it is trying to save, which is a shame. Thanks again, anyway – Walsh

@declantraynor: Bear in mind that acceleration != movement. Somebody can be moving and not accelerating (e.g., in a car on cruise control). – Crock

yeah that's something I've been considering while working on this app. Nothing's ever simple! :P I'm convinced now that using the accelerometer in this way is just the wrong approach anyway. Ah well... back to the drawing board! – Walsh

Answer 2

Have you ever used the app MyTracks? http://code.google.com/p/mytracks/

Last I checked, they use a wake lock when the user has an active path.

I have the same issue as you - and while I'd prefer not using a wake lock, my app is ruined if the OS kills the app along the way. Right now we're doing so, at the expense of about 10% battery life per hour - which isn't all that bad. It's certainly not great, but our average path is only about 20 minutes. And it works.

Using the Alarm Manager does seem like a better route. Any good examples of how to use it for this sort of situation?

Antilogarithm