We have such a program that supports GPS logging every second. We use a foreground service (and a notification icon) and the service very rarely gets killed (and most of the time it gets restarted quickly by the OS) . Our users are fully aware of and fully ok with the battery impact. Most of them use the app in the car with the device in a powered cradle. You wouldn't believe how many requests we get for subsecond GPS logging. Thankfully the consumer GPS devices don't go that low. We actually see the opposite problem. When the user exits the application this sends the stop signal to the service. However, the service then sometimes restarts on its own. We had to add logic to the service to check if the app is still there or if the service is orphaned (in which case we stop it from the inside). Hmm, maybe that's the idea. Not bother stopping the service from the app, let the service stop itself?
On Thursday, May 10, 2012 6:17:30 AM UTC-4, William Kelley wrote: > > > On Wednesday, May 9, 2012 9:40:20 PM UTC-7, Kristopher Micinski wrote: >> >> >> What you're doing isn't draining the battery only because of the >> service, but also because of the location updates you'll be getting.. >> > > GPS fixing is definitely the main battery killer here, but there are smart > ways to handle it. > > >> 30-40 seconds, do you really need that kind of accuracy? I would say >> that I'd only want something like 5 minutes, which an AlarmManger >> certainly could do (I believe, at least..) >> > > Actually, I like to get accuracy of about 5-10 seconds when driving, less > when walking. But 5 minutes would be basically useless. At 70 miles an > hour, that's 6 miles between points. Even when hiking, I can make quite a > few switchbacks and directional changes in 5 minutes. It all really depends > on what you want out of a GPS tracker. I want a detailed log with great > accuracy. I know battery life suffers, but when you're in a car, you can be > plugged in, so that helps. And even when hiking, 10 seconds between fixes > allows my phone to go for 8 hour hikes, so it's completely reasonable. > > I changed my app to run as a foreground service and so far that has made > all the difference. It hasn't once been restarted in 3 hours. For some > reason, I thought a background process would be less likely to be killed, > but now I see that services that let the user know exactly what is going on > by being in the foreground and being required to show a notification icon > are more transparent and thereby more "trusted" by the OS. The one thing > that I don't understand is WakeLock. I am running my service without a > wakelock, the phone has been off for a few hours, and it is still logging > GPS points. Should I assume that some other app (I am running Tasker and > some other automation apps as well as CatLog) are keeping the CPU awake? > > Thanks for everyone's help. Little by little, I am getting a better grasp > of what I am doing. > -- 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
