Just do not sit there holding a partial wake lock forever. If this actually didn't matter, why would we have these at all? Why would we just instead skipping the whole sleeping the CPU thing? It sure would have made our life a lot easier.
The problem with a partial wake lock is that on many (but not all) devices, it does not *directly* consume power, but it allows a lot of things to *indirectly* consume it by allowing them to run when they normally wouldn't. Thus how much you reduce battery life is going to depend greatly on the other apps running on the phone. Even for a stock build of the platform, though, I can guarantee you will be noticeable impacting battery life. It seems like every release we go through we have some situation come up where wake locks are being held too much in some case, causing our battery life to go down. Also it makes no sense to measure the impact of holding a partial wake lock while doing anything with the screen on, since while the screen on the CPU is not allowed to go to deep sleep so a partial wake lock wouldn't do anything. Another complication with them is that, because they don't directly consume power, the battery use UI won't accurately reflect what you are doing. That is, if you are holding a wake lock, and that is allowing another app to run a lot, then none of the increased battery drain will be accounted against you in the UI, it will be all against the other app. Worse, the more likely case is that by doing this you allow 5 or 10 or more other processes to run for a little bit each, which together result in significant battery drain, but not coming from a particular source. So as a user you will just have an experience where your battery life is poor, but won't see anyone in the UI as a real culprit. That said, the reporting of this has been greatly improved in 2.3. Now while you are holding a partial wake lock (while the screen is off), you will get 50% of the blame for all CPU during that time. This makes it very likely that your app will show up on the CPU usage list. I think you can assume that as 2.3 gets on more devices, you will get increasingly complaints from users as they start seeing your app to blame, instead of just having a nebulous experience of their battery life being poorer than it seems it should be with no clear cause. Also there are devices where the simple act of holding a partial wake lock *does* consume power, because the hardware can't put the CPU into power collapse while doing so. The Nexus S (and other Galaxy S class devices) is an example of this. On these devices, you will definitely have an impact on battery life, even if there is nothing else that is allowed to use the CPU. And also in 2.3 this will be better reflected in the battery usage UI. As far as a service being killed -- unless you use startForeground(), you should count on your service being killed and restarted somewhat regularly. I believe, in the current implementation, after it has been started for 30 minutes it is dropped out of the service OOM adjustment, and put into the regular background LRU list. At that point it will just get killed whenever it gets to the end of the list -- best case for a device that can keep the maximum of 15 background processes running, after the user (or broadcasts or other activity) has made 15 other app processes active for any amount of time. On devices with little memory, you will be killed almost immediately at that point. We didn't start killing processes for excessive wake lock use until 2.3. At this point it is only done to background processes. I don't recall if a service that has been running a long time is considered a background process for that accounting. It probably should be (though it will soon after be restarted). We allow a service otherwise to keep holding a wake lock, since also as of 2.3 these things will show up in the battery use for the user so they will know how to blame. That all said, if you aren't currently causing the GPS to run yourself, waking up every 15 seconds to acquire a GPS lock would have significantly more battery use because GPS is fairly power hungry. Well and fundamentally waking up every 15 seconds is not solving any problem here, it is doing the same problem while following the letter of the guidelines. Finally, if you are just passively listening for location updates that come from other apps requesting location information, do you really need to hold a wake lock? If a location update is happening, someone else must be holding a wake lock during that time in order for it to happen. On Tue, Jan 25, 2011 at 6:33 AM, mikeee <mike.engelh...@gmail.com> wrote: > Thanks for all the comments. A few more from me. > > Diane, just to clarify I am using a *partial* wake lock as I mentioned > in my original post and this is what Mark was implying was evil. I > understand that it uses more batteries then not having acquiring the > lock but it seems that if you have a requirement in an application > where you need to receive a GPS update as the user moves around with > relatively fine granularity of say 100 meters, that using a partial > wake lock is a perfectly valid use case - in fact I think it's a > better use of the API to let the screen and other parts of the phone > turn off yet the CPU and GPS remain on rather then forcing the > activity to be in the foreground and keep the screen on. The screen is > one the largest user of battery power. > > Also my app has been on the Market for several months and hasn't had a > single comment or email sent to us about the battery life being an > issue. Granted we've only sold 500 or so but I would expect since > it's not a free app that people would complain. For example I can > easily run the app for 24 hours with a PARTIAL_WAKE_LOCK acquired > without using up all the batteries on my Motorola Droid and also while > surfing the web, checking email, making phone calls. I would argue > that if you're running applications, surfing the web and using email > on your phone frequently that 24 hours is about right for the amount > of time you get out of a charge. I know many Droid owners that say > they have to charge their phone every day (and these are people that > aren't using my app - just general phone, text messaging, email, > surfing web activities). Same is true of iphone users. > > Also, Mark you said that the OS is probably terminating the service > because it has acquired an everlasting wake lock. Why would their be > a published API call that is specifically designed to keep the phone > running and then behind the scenes have OS level logic that sniffs > around for services that are accessing the public API and then killing > them off. I can't think of a single scenario where that makes any > sense. I'd be perfectly fine if the documentation said "don't use > this ever" or "don't ever use this in a service" but I haven't ever > seen such a document other then random comments from people who > purport to have built a better mousetrap but it never captures the use > cases of specific app requirements. > > Just to clarify - my app isn't polling anything, it's waiting to be > sent events from the LocationManager which pushes location changed > events if you are an observer so although the CPU is left running my > application isn't really doing anything except responding to events > that the OS pushes out. > > I'm not sure what switching to a timer approach that has to wake up > every 15 seconds or less and then wait to acquire a GPS lock (which > itself can take 15 seconds if you have to do it from scratch each time > the phone wakes up), update the database in my app and then let the > default sleep timeout come and go. I don't think the phone would ever > sleep in that scenario if your phone sleep time was 15 seconds for > example. I agree if I only needed to wake the phone up every 5 > minutes to do a task then an Alarm based system would make sense. > > > On Jan 25, 4:04 am, Dianne Hackborn <hack...@android.com> wrote: > > It probably uses FLAG_KEEP_SCREEN_ON for its window to keep the screen on > > while in its UI, and also holds a partial wake lock to keep the device > > running while you are not in its UI. > > > > On Tue, Jan 25, 2011 at 12:38 AM, Mark Murphy <mmur...@commonsware.com > >wrote: > > > > > > > > > > > > > Moreover, I doubt Google Navigation uses an explicit WakeLock, > > > preferring instead to use activity-based means of keeping the screen > > > on. > > > > > On Tue, Jan 25, 2011 at 6:30 AM, Dianne Hackborn <hack...@android.com> > > > wrote: > > > > Navigation uses Service.startForeground() to say that the user is > > > currently > > > > aware of it so it can't be considered expendable. > > > > > > On Mon, Jan 24, 2011 at 5:33 PM, mikeee <mike.engelh...@gmail.com> > > > wrote: > > > > > >> So you're saying Google Navigation *doesn't* use a wakelock and > > > >> continually receive gps updates or that it's somehow an evil > > > >> application because it uses the battery quickly? > > > > > >> On Jan 24, 5:24 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > >> > On Fri, Jan 21, 2011 at 8:11 AM, mikeee <mike.engelh...@gmail.com > > > > > >> > wrote: > > > >> > > I've got an app that starts a service in order to receive > location > > > >> > > updates from the LocationManager. The use case is the service > > > needs > > > >> > > to be running all the time and as such it acquires a > > > >> > > PowerManager.PARTIAL_WAKE_LOCK in the onCreate() of the Service. > > > > > >> > This sounds evil from the standpoint of battery life, if nothing > else. > > > > > >> > > But it seems from testing on several different phones and user > > > >> > > feedback that the Service is still being put to sleep as the > > > location > > > >> > > notifications will stop if the application isn't in the > foreground. > > > > > >> > Android does not put applications to sleep. In your case, Android > is > > > >> > probably terminating your service for being everlasting and using > a > > > >> > perpetual WakeLock. > > > > > >> > > This effectively renders the app ineffective for the task at > hand. > > > >> > > I've read posts about using an Alarm to simulate a pseudo cron > job > > > but > > > >> > > I don't really need to be woken up in order to do a task, the > app > > > >> > > needs to run code based on the location manager calling > > > >> > > onLocationChanged the service that the users position has > changed. > > > > > >> > You can experiment with my LocationPoller, which is designed for > your > > > >> > scenario: > > > > > >> >https://github.com/commonsguy/cwac-locpoll > > > > > >> > > yet the fact that it > > > >> > > effectively stops running in some cases is causing problems for > the > > > >> > > users. > > > > > >> > That is because you cannot write everlasting services. Please use > > > >> > AlarmManager and something (LocationPoller or your own design) to > > > >> > write so you do not have a service and WakeLock in memory all of > the > > > >> > time. > > > > > >> > -- > > > >> > Mark Murphy (a Commons > > > >> > Guy)http://commonsware.com| > > > > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > > >> > Android Training in London: > > >http://bit.ly/smand1andhttp://bit.ly/smand2 > > > > > >> -- > > > >> 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<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > > >> For more options, visit this group at > > > >>http://groups.google.com/group/android-developers?hl=en > > > > > > -- > > > > Dianne Hackborn > > > > Android framework engineer > > > > hack...@android.com > > > > > > Note: please don't send private questions to me, as I don't have time > to > > > > provide private support, and so won't reply to such e-mails. All > such > > > > questions should be posted on public forums, where I and others can > see > > > and > > > > answer them. > > > > > > -- > > > > 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<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > > > For more options, visit this group at > > > >http://groups.google.com/group/android-developers?hl=en > > > > > -- > > > Mark Murphy (a Commons Guy) > > >http://commonsware.com|http://github.com/commonsguy > > >http://commonsware.com/blog|http://twitter.com/commonsguy > > > > > Android Training in London:http://bit.ly/smand1andhttp://bit.ly/smand2 > > > > > -- > > > 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<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
