On Sun, May 13, 2012 at 8:05 PM, William Kelley <[email protected]>wrote:
> My question wasn't about battery life, but I'll address it anyway. Users > who install apps that use long running services are usually fully aware > that it will affect battery life. There is basically no relationship between "long running service" and battery life. It's all a matter of what your service does. > Certainly anyone who wants to record a GPS track for a few hours with very > fine resolution (points every 5 seconds say) knows it will kill the battery > quickly. But the point is they know this and want these apps regardless. > You may not personally have a use for such services, but others do. My > phone wouldn't be interesting, to me, if the only thing I focused on was > plugging the phone in no more than once a day. I have no problem recharging > several times a day (especially all the time I am driving) so that I can > use my phone as a sensor and logger and record interesting information. > This requires battery, but it is information I want. > I think you are taking this too personally. My comment was addressed at whatever other apps you say are on your phone that are holding wake locks and keeping the device from sleeping the entire time, with no indication you gave for them to do this. The fact of the matter is that for most people it is not typical for them to have apps on their phone that hold wake locks all the time consistently, because that would often mean they would never get through a day without charging their phone. Sure, you may do things on your device that do work for the user, that the user wants to have happening, and is clear to them that it is going to take power. Playing music, navigating, tracking your location with GPS, etc. There is no problem with that. The question I was trying to ask in this post was really more partly > practical and partly conceptual. Practically, are there any issues with > having multiple apps on your phone each implementing their own WakeLocks? Why would there be? I thought I answered your question -- you should hold a wake lock when you need to keep the CPU running, and you shouldn't worry about what other apps do nor rely on them to do this for you. > I currently have three and they don't seem to interfere with each other. I don't even know what it would mean for them to interfere. A wake lock tells the system to not let the CPU go to sleep. If three wake locks are being held, who cares if there are three things telling the system to not let the CPU go to sleep? It's still not going to sleep. > Which brings me to the question of whether I should implement a WakeLock > in my own GPS logger app despite the fact I know my phone will never sleep > the CPU? How in the world do you know that the phone will never sleep on whatever device you are running? Again, the same answer -- the correct thing to do is hold a wake lock when you are at a point where you can't let the CPU go to sleep. That is, when you have no other external signal like an alarm to wake it up in the future when you need to run again. Normally you will do this while you are actually using the CPU. If you are doing this to just wait for a certain amount of time until you run again, you should consider another mechanism like scheduling an alarm for when you want to wake up, because on many chipsets it takes a notable amount of battery to have a wake lock held with the CPU idle vs. not having a wake lock and letting the CPU go into full power collapse. Of course if you are doing very frequent wakeups like every 5 second it may be more overhead to schedule an alarm, but this is a difficult area because which way is better will probably vary across devices. At that point maybe it isn't worth worrying too much about, because either approach will be relatively power draining. > Now for any potential users of my apps (if I were to release it), I would > then tell them they had to get a WakeLock app (there is one on the market) > in order to keep the CPU awake so that my GPS logger will continue to > record points as long as they like. There are no wake lock apps, there is no reason to have such things, let's just stop talking about this. :) > That may be too much to require of a user and implementing my own WakeLock > is the easiest solution. But conceptually, it seems redundant that every > app that wishes to have a long running service would have to have its own > WakeLock, when only one is required. That's why, at least for me and users > like me, one WakeLock app to rule them all makes a lot of sense. > Why why why???? Just hold a wake lock when you need it!!! :) It's just a simple wake lock! It's not going to slap the user in the face every time you acquire it. :) > As for the user, I don't think it's "crazy" at all for them to want to > control how their phone works. Again, if the user wants the features of > long running services, why dissuade them? Letting the user choose to have > the CPU running at all times (partial wake lock) seems completely > reasonable. I don't think you understood my point. There is no reason for the user to decide every time when the CPU can run. This is what programs are good at, and should be able to do accurately and efficiently without bothering the user. Yes the user can certainly understand "I want to start tracking the GPS and recording my location until I say to stop." That is a fine thing to do. For the user this has nothing to do with wake locks, it is an actual feature they can understand that they can control. And for the implementation, there is no requirement that this be tied to holding a wake lock the entire time. Implementations of this that want to allow such tracking for long amounts of time could very well do this using the alarm manager to wake up regularly and hold a wake lock just while getting an updated location. -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
