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%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%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%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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
