Question

I’m creating a Service that will be set up to start using the AlarmManager (using ELAPSED_REALTIME_WAKEUP). I do all my processing inside the onStartCommand method mainly because:

1. It doesn’t take long (read small file from disk, maybe push notifications via NotificationManager)
2. I can easily set it to start in a separate process if I need to.

Under these circumstances, do I still need to obtain a WakeLock?

From what I know, you have to obtain a WakeLock only if you create separate threads (because the OS will see the main thread as idle and go to sleep). Is that true or do I still risk being interrupted by the OS… dozing off?

Answer 1

Beware — currently you should not have wakeup alarms delivered directly to a service. Delivery to a service is different from delivery to a receiver; the alarm manager can not know when the service is done executing, so it can’t make sure it holds a wake lock for you even up to the call to your onStartCommand().

Thus, do to this, you’ll need to have a receiver that the alarm is sent to, in that receiver acquire a wake lock, and then call startService() to have the service execute and ensure you don’t release the wake lock until the service is done. Yes sorry this sucks. 🙁 I think Mark or someone may have helper code for this.

One way you can simplify this is if you only care about what happens when the service is already running. Context.peekService() can be used within onReceiveIntent() to get the currently running service, and you can call it right there in the receiver to have the critical code execute while you are holding the wake lock. Further if you are using the common case of these running in the same process, you can use the same tricks shown in the Service doc to directly call on to it without having to write an aidl file.