Android uses a very proactive power management approach. Basically, the policy is to go to sleep if not told otherwise.
The way to signal to the system that it should stay awake are wakelocks. As soon as there's at least one app holding a wakelock, the system won't go to sleep and all the running processes can do their work (even those that are not holding a wakelock at that moment). Any application with the according permission can acquire a wakelock and thus prevent the system from sleeping. There are several "wakelock levels", you can read all the details here: http://code.google.com/android/reference/android/os/PowerManager.html In your case, as a background service, you probably want to hold a PARTIAL_WAKE_LOCK which will keep the CPU running as long as it's acquired. Please be very careful with using the wakelock, as this affects battery life a lot and it is hard for users to determine which application is causing the drainage and uninstall it. For every acquire(), make sure you have a matching release() call that is guaranteed to be executed* and only hold the lock for the minimal amount of time. Also ask yourself whether it's crucial that your service is preventing the system to go to sleep or whether it would be enough to do work only when the system is awake anyway (e.g. because the user is interacting with the phone). The AlarmManager can be used to get an intent delivered to you at a certain time, regardless of the sleep-state of the system. The AlarmManager will wake the system up if necessary and hold a wakelock until the intent has been delivered to you. As you should not do long-lasting work on the main thread of your service (which is receiving the intent), you should spawn a thread and manually acquire a wakelock. Sorry for the long post and I hope this information is helpful (and accurate :-)). Christoph * One has to pay special attention to the control flow in the case of exceptions. Make sure that a thrown exception won't prevent release() from being called: void doSomeWork() throws SomeException { ... } void barWrong() { try { wakelock.acquire(); doSomeWork(); wakelock.release(); // <- Won't be called on exception } catch (SomeException e) { Log.w(...); } } void barRight() { try { wakelock.acquire(); doSomeWork(); } catch (SomeException e) { Log.w(...); } finally { wakelock.release(); } } On Sat, Feb 7, 2009 at 11:19 PM, clarkbriancarl <clarkbrianc...@gmail.com> wrote: > > Thanks for the reply. I've been reading and tweaking for over a week > trying to figure this out. Thats a good idea to use the Alarm Manager. > I think I will give that a try. I would still like to hear from a more > experienced devloper or a google engineer if this is the way an > Android service is supposed to behave. > > On Feb 7, 3:29 pm, Greg White <debauchedsl...@gmail.com> wrote: >> On Sat, Feb 7, 2009 at 11:50 AM, Brian <clarkbrianc...@gmail.com> wrote: >> > While testing the service, I have come across something interesting. >> >> > My problem is that the service appears to sleep or pause for a few >> > hours, run a short time, and then sleep for a few more hours, then run >> > a short time, etc when the phone has become inactive. >> >> I'm interested to hear what others say. My experience mirrors yours. I >> believe the phone is going to sleep and freezing the service. >> >> What I did was to use the AlarmManager to wake the service to do its work. >> While it was working, I used a wake lock to keep the phone from sleeping. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
