Today, while doing research to answer some bug mail, I learned that all versions of Android since 4.0 (Ice Cream Sandwich) have used gpsd to read the take from the onboard GPS. Sadly, gpsd is getting blamed in some quarters for excessive battery drain. But it’s not gpsd’s fault! Here is what’s actually going on.
Activating the onboard GPS in your phone eats power. Normally, Android economizes by computing a rough location from signal-tower strengths, information it gathers anyway in normal operation. To get a more precise fix, an app (such as Google Maps) can request “Detailed Location”. This is what is happening when the GPS icon appears on your status bar.
Requesting “Detailed Location” wakes up gpsd, causing it to power up the on-board GPS and begin interpreting the NMEA data stream it ships. Somewhere in Android’s Java code (I don’t know the details), the reports from gpsd are captured and made available to the Java API that apps can see. Normally this mode is a little expensive, mainly because of the power cost of running the GPS hardware; this is why Android doesn’t keep the GPS powered up all the time. Normally the gpsd demon itself is very economical; we’ve measured its processor utilization on low-power ARM chips and it’s below the noise floor of the process monitor. As it should be; the data rate from a GPS isn’t very high, there’s simply no reason for gpsd to spend a lot of cycles.
Nevertheless, instances of excessive battery drain have been reported with the system monitor fingering gpsd as the culprit, especially on the Samsung Galaxy SIII. In some cases this happens when the onboard GPS is powered off. In every case I’ve found through Googling for “Android gpsd”, the actual bad guy is an app that is both requesting Detailed Location and running in background; if you deinstall the app, the battery drain goes away. (On the Galaxy SIII, the ‘app’ may actually be the “Remote Location Service” in the vendor firmware; you can’t remove it, but you can disable it through Settings.)
I suspect that there’s something else going on here. The fact that gpsd is reported to be processor-hogging when the GPS is powered off suggests that it’s spinning on its main select(2) call. We’ve occasionally seen behavior like this before, and it has always been down to some bug or misconfiguration in the Linux kernel’s serial I/O layer (gpsd exercises that layer in some unusual ways). This is consistent with the relative rareness of the bug; likely it’s only happening on a couple of specific phone models. If every background app using the GPS caused this problem, I’d have had a mob of pitchfork-wielding peasants at my castle door long since…
TL;DR: It’s not gpsd’s fault – find the buggy app and remove it.
All this having been said, why, yes I do think it’s seriously cool that gpsd is running in all newer Android phones. My code is ubiquitous and inescapable, bwahahahaha! But you knew that already.
Isn’t this what the PulseAudio guys said about Wine and vice versa?
Not that you are necessarily wrong, just this has the potential to turn into a long-running political issue without user-satisfactory resolution.
>Not that you are necessarily wrong, just this has the potential to turn into a long-running political issue without user-satisfactory resolution.
I’m not hugely worried about that. It’s a rare bug, and the word that it has to be solved by finding the misbehaving app already seems to have gone out on various Android-related blogs and web forums. I posted about it mainly to air my suspicion that there almost has to be a kernel-level serial I/O problem in the mix.
I solved the problem , yes it is not gpsd , it is the find my mobile->romote controls service is turned on . It is used by samsung account to trace and find your mobile if lost. I couldn’t turn it off , but when I removed samsung account it is turned off , and everything thing is fine now . I hope this would help .
Perhaps, but if gpsd isn’t doing anything it can avoid, how can it fix the problem?
>Perhaps, but if gpsd isn’t doing anything it can avoid, how can it fix the problem?
I don’t actually have any belief that gpsd can fix this problem. When select(2) isn’t working properly, for whatever reason, gpsd is pretty comprehensively screwed.
We used to see problems like this under early versions of Mac OS X that had a buggy driver for the PL2303 chip used in a lot of USB GPSes. Wasn’t much we could do about that, either.
It’s quite interesting that your code is in use by Android (and I know your GIF related code has been used everywhere as well). Question 1 then is, have you seen any money (whether via paid consultancy work, or one-off donations, or similar) for GPSD from Google or any of the handset manufacturers? Question 2, have you got any paid work or donations from other people or organisations, because of your work on GPSD?
I ask because I know GPSD (and GIFLIB) is BSD, and I recall another hacker (I think it was Mark Pilgram, sadly missed) who was quite annoyed that lots of people used his work, they all loved it, but that they never gave anything back. And because it was BSD, he couldn’t even see the changes they’d made. He accepted that, because he had, after all, said, BSD. but then, he changed to GPL for a new project. And then all the same people came and said, “hey, that looks great, it’s a pity we can’t use it because it isn’t BSD”. He said, but you can you use it. And then I think he offered an expensive license if they wanted a non-GPL version. And, I think that was that.
Thanks.
>Question 1 then is, have you seen any money (whether via paid consultancy work, or one-off donations, or similar) for GPSD from Google or any of the handset manufacturers?
No.
>Question 2, have you got any paid work or donations from other people or organisations, because of your work on GPSD?
I’ve received hardware donations,
You say “And, I think that was that.”
Did he make any money?
This is part of why Apple and Microsoft have opted for curated platforms on mobile: battery life is crucial to mobile, and they don’t want the complaints, support calls, and reputational tarnishment that will come when a rogue app eats up their customers’ batteries.
I’ve seen what may be this bug on Android 2.2, so if gpsd didn’t go in until ICS, then it may not be anywhere near the scene of the crime.
The symptoms I see are the system process spinning using all CPU; only a reboot resets things. The problem can start minutes, hours, or days after boot, but seems to be related to GPS failing to get a lock – opening an app which wants fine location, and then minimising or closing it before the GPS icon stops flashing is much more likely to trigger. Leaving GPS configured off eliminates the problem entirely.
> When select(2) isn’t working properly, for whatever reason, gpsd is pretty comprehensively screwed.
Any chance that it could detect the issue and A) produce debugging output that might get the attention of the people building the handsets and B) throttle back to waiting (manually via sleep) some time between calls?
These aren’t _good_ solutions, but if it can be detected in a way that avoids false positives, it might be better than nothing.
>Any chance that it could detect the issue
I’ve been thinking about this and have a sketch of an approach in my head. There are two problems:
(1) Testing the detector would be tricky, since I don’t have a way to reproduce the bug.
(2) Supposing I could do that, I can’t think of any way to regression-test the bug in my normal environment.
What about mocking select?
I guess I should have asked (I assumed you did, from what you said before) if you know what specific misbehavior you believe is occurring in select.
>What about mocking select?
Yeah, it would have to be done that way.
>I guess I should have asked (I assumed you did, from what you said before) if you know what specific misbehavior you believe is occurring in select.
The reported symptoms would be explained if select is sometimes reporting data ready, without an error indication, when the device is actually closed. gpsd’s main loop would buzz furiously getting zero-length reads from the device and eating many orders of magnitude more processor cycles than it does in normal operation.
Is there a normal case where gpsd would get a zero-length read, or some moderate number of them in a row? If not, perhaps sleeping for some short period after getting a 0-length read, then checking to see fi the file was actually open, would armor you against this.
I don’t know that it is related but the latest rev of ASUS Transformer code (JB 4.2.1) has been failing to correctly disable the wifi while sleeping and hence battery life in standby has gone down significantly. It may also be enabling GPS too (not sure). Either way the workaround seems to be to remember to put the thing in airplane mode before sleeping (see this thread – http://www.transformerforums.com/forum/transformer-pad-300-help/35011-poor-battery-life-after-4-2-1-update-2.html ).
I’d be curious if the same thing works for the GPSD related problems (and yes I understand that if it’s a *phone* then airplane mode kind of defeats the point of having a phone, this would just be for debugging purposes).
Could that main loop decrement a counter before it loops, and if that counter hits zero, give up trying, at least for a few minutes?
>Could that main loop decrement a counter before it loops, and if that counter hits zero, give up trying, at least for a few minutes?
How would you know when to reset the counter?
Remember that in normal operation you never want to sleep for longer than 0.5 sec. That’s because 1sec is the typical GPS reporting interval.
Select is broken? http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html
>Select is broken? http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html
Thing is, I’ve actually seen select(2) be broken in a relevant way – I even know roughly why and when it happens. The PL2303 driver for Mac OS X used to be buggy in a way that produced incorrect select(2) behavior if one of the file descriptors in the select set happened to belong to it. GPSD had to advertise Mac non-support for this exact reason until it got fixed.
@ESR “Did he make any money?”
I don’t know. I just found the piece (Zed Shaw, not Mark Pilgrim) Why I (A/L)GPL. So, you can see for yourself.
It’s quite interesting isn’t it. That you can give away software that is used by millions of people around the world, and all you get is recognition and hardware (but presumably to make sure it works with the software). That’s partly why Zed Shaw went GPL if I understand his rant correctly.
Still, there is no obligation for anyone to give back, and they are in it for the money.
>It’s quite interesting isn’t it. That you can give away software that is used by millions of people
>around the world, and all you get is recognition and hardware (but presumably to make sure it
>works with the software). That’s partly why Zed Shaw went GPL if I understand his rant correctly.
Well, we have quite a nice experiment here, since dnsmasq is, like gpsd, in Android but it’s GPL rather than BSD. I can report that I’m in pretty much the same position is Eric: I’ve never made any money either as a consequence of the inclusion of dnsmasq in Android.
@Michael
“It’s quite interesting isn’t it. That you can give away software that is used by millions of people around the world, and all you get is recognition and hardware (but presumably to make sure it works with the software).”
What is more interesting is that many (young) people want money just for the recognition. Being famous and admired can be a stronger reward than being rich and powerful. Even the extremely rich tend to succumb to the desire for recognition and admiration and give away much of their hard earned money.
Any time you read valid data, or wake up from the sleep imposed by the counter hitting zero, you’d reset the counter. The idea is that if you make
xconsecutive zero-length reads, something is wrong, and you just give up trying for a couple of minutes to give it a chance to get non-wrong.>Any time you read valid data, or wake up from the sleep imposed by the counter hitting zero, you’d reset the counter. The idea is that if you make x consecutive zero-length reads, something is wrong, and you just give up trying for a couple of minutes to give it a chance to get non-wrong.
Stalling for 0.5 sec ought to be sufficient to prevent serious buzzing.
My hesitation at this point stems from the fact that I’m reluctant to add complexity at a critical part of the code unless I know I’m addressing the actual bug. But I’ll look at it to see how simple I can make such a guard.
@Intertube, I thought that was amusing too given the specific example, but ESR is a much better programmer than the typical person who complains of such things – which also enables him to make sweeping pronouncements like suspect your compiler’s optimizer because his “optimizer bugs” are much less likely to be the kind of think-i-know-how-it-should-work Undefined Behavior that such things often are than most people’s.
@Simon Kelley, but presumably you can take the changes made and fold them back into your distribution if they aren’t submitted by the people making said changes. In Zed Shaw’s case, as I understand it, there was not even code contribution being made (whether indirect, as in the code is public and he can put it back into his version of the program, or direct, where the people directly give the changes).
@Winter I can’t understand that really. What’s the point of being famous for being famous? If you want to be known, you can do an honest days work, and blow up parliament.
—
I should just note, I’m not passing judgement here. Or at least, that is not my intention. I’m rather just observing. I’d be thrilled to have code of mine used widely. One, it would be a validation of my abilities. Two, I could point to that code, and have a greater possibility that the person I’m talking to has used it (which leads to greater job options etc.).
Moreover gpsd is tested heavily, both static (including lint annotations) and dynamic (testsuite!).
>Moreover gpsd is tested heavily, both static (including lint annotations) and dynamic (testsuite!).
Also, its successful deployments are, at this point, well into the hundreds of millions in a variety of embedded environments that could make you dizzy to think about. Smartphones, high-precision agriculture, armored fighting vehicles, marine navigation systems, and every kind of flying and swimming unmanned vehicle there is…if GPSD’s error rate weren’t comparable to that of space-shuttle firmware our bugtracker would collapse under a flood of bitching. As it is we routinely have multiple months go by between single bug reports.
Just out of curiosity, Eric: why did you stop blogging about smartphones?
>Just out of curiosity, Eric: why did you stop blogging about smartphones?
Because I no longer believe I have a reliable source for market-share numbers. Used to be I had one source that I thought was steady and good and a lot of other spotty ones that were telling the same story (up to statistical noise levels). Then my steady source went nuts relative to several second-best ones, and I could no longer believe that it gave me good visibility into what was actually happening.
To put it more succinctly, Eric’s source of data failed to support Eric’s hypothesis. (Namely, that Android was winning, and that a super majority had occurred when ComScore showed Android at 50% US market share.)
As for gpsd: sometimes you get what you pay for.
Really? If that’s the best you can do, you need to spend more time in the troll-dojo.
I would have said that the Comscore numbers were incredibly steady, if very smooth curves indicate steadiness. Who knows if they’re reliable though, certainly not me.
Sorry for taking this off topic, I was just curious.
I find this interesting because I ended up fixing a bug in the memory allocator at work which only occurred when the system was really out of memory *and* you attempted certain-sized allocations.
That was fun …
If you see repeated zero-byte reads over the course of a whole second plus a bit, then sleep for 30 seconds (just a plain sleep — not a select with a 30 second timeout).
Very off topic, but might be interesting (via G+): http://www.nationalreview.com/articles/344763/turning-gun-owners-felons-dave-kopel
@Random832 @Intertube
esr said:
Indeed. GPSD is quite heavily used in the aeospace industry, especially in the military and space sectors where Linux currently rules in embedded navigation systems. If there were lots of bugs, these guys would find them. The fact that the Linux kernel and GPSD are so heavily used in these systems says volumes about the quality of the proprietary embedded software they replaced (QNX and VxWorks, mostly).
Hmmm.
> GPSD ignoring settings in .gpsdrc
> GPSD still ignoring settings in .gpsdrc
> GPSD apparently not even reading .gpsdrc
> GPSD ignoring settings in /etc/gpsd.conf
> GPSD still ignoring settings in /etc/gpsd.conf
> GPSD apparently not even reading /etc/gpsd.conf
> GPSD does not document where its config lives
> GPSD also does not document its config format
> GPSD is not user-configurable! But this is Unix, dammit!
>GPSD ignoring settings in .gpsdrc
gpsd doesn’t have a configuration file because it is designed correctly – that is, it autoconfigures so it doesn’t need one. Unix practice is, in this respect, often lazy and sloppy.
(There is one minor exception for broken devices that go catatatonic when you try to change the reporting speed on their ports. There’s a command-line switch to prevent this.)
Yes. Was joking about the kind of “bug” reports GPSD would get flooded with.
Will be sure to include smilies next time.
Eric: why did you stop blogging about smartphones?
I found the answer very interesting. Eric, I’d assumed given the multiple losses Apple is taking in its “nuclear” war against Samsung, plus the delicacy of some of the court cases involved, plus the international character of the fight, that you’d decided silence on this subject was the best pro-Android policy.
I’ve actually seen select(2) be broken in a relevant way – I even know roughly why and when it happens.
Is it just select that’s broken in this particular way, or is poll broken as well? Just wondering if switching to poll might be an option.
> Is it just select that’s broken in this particular way, or is poll broken as well?
All these interfaces (select/poll/epoll/kqueue etc.) are implemented with the same mechanism in the driver.
(And it’s only the driver itself that decides when its file is considered “ready” for I/O.)
Here’s the actual implementation of select and poll, in case anyone’s interested: http://lxr.linux.no/linux/fs/select.c
At the core, both call the file_operations->poll method on the file, which is the driver’s responsibility.
@ESR
Did you get a chance to look at the feasibility of implementing a counter on zero-length reads that would force GPSD to give up trying for a decent interval before the next attempt?
>Did you get a chance to look at the feasibility of implementing a counter on zero-length reads that would force GPSD to give up trying for a decent interval before the next attempt?
It’s on my list, but I’ve spent most of the last two days trying to recover from problems with a graphics card upgrade.
I’ve found some information about possible reason that battery is highly used by gpsd. This problem probably concerns Samsung devices with enabled remote control option. So below is information how to save your battery consumption.
Tap Settings
Scroll down, tap Security
Scroll down, tap Remote controls
Enter the password for your Samsung account, tap OK in top right
Slide the switch in the top right corner towards the left, where it should change to grey
I had the same problem when the GPS was “off”. If the GPS is “on” the battery act normally.
Ok so how do I disable Remote Location Service on my GS3 as you’ve suggested and what effect will this have on my phone?
I’ve just stumbled on this post as I look for an explanation for gpsd being reported as draining 50% of my battery. It’s draining just about as it is charging off a USB port. Mad.
My phone is a Galaxy S3, and I’ve just recently updated about 10 apps. I can probably remember about 5 of them….
Thanks to the author for writing gpsd & for putting up this post that puts me in the right direction to troubleshoot. I suspect some samsung bloatware (the remote control feature mentioned above has always been off)…. it may take a while to find it and I won’t be able to uninstall it.
It’s mind blowing to consider your code being used on hundreds of millions of devices…. well done sir.
thanks so much this post. I nearly flipped with finding the root cause of this problem . Now my battery works fine again (after disabling the remote location service on my S3 – 4.1.2)
On Samsung Galaxy Note 1 rooted 4.3.1 cyanogen mod
I confirm that when GPSD process is active (I cannot prevent it to be active and I cannot cancel it), the battery is going down drastically quick ; in addition, the device is heating a lot (just below the camera at the back). I have not “Remote location service” accessible via the Security settings.
I would like to know how to kill GPSD (I could not see the difference when active and not active, except on battery consumption) and how to identify the application using GPSD.
The title of this blog “No, GPSD is not the battery-killer on your Android!” is by itself very questionable. Would we question is GPSD able to cook pancake?
For me it was the bloody samsung navigtion software – Navagon : Navigation
I did what was suggested on another side, the little “GPS” icon in top left was constantly on.
So I just kept killing apps until is disappeared.
It may have been while i was inside since there is no gps signal and it kept searching constantly giving me a phone life of about 3-4hrs hours.
I disabled the app – hopefully that was my answer.
Cheers – Mark
GPS chips from 2011’s Sirfstar IV onwards draw so little power (max 30mA whilst doing acquisition, 8mA normally and less than 0.1mA in warm standby) that they’d have a hard time running the battery down – and it’s important that they NOT be fully shut down, if you care about fast lockons. (Broadcom’s GPS chipsets are comparable to CSR’s in power consumption)
The biggest offender these days is the screen, closely followed by whatever app(s) causes the CPU to run at full speed.
Compare that with the old days of the original sirf, which could run my Motorola A1000 flat in less than 45 minutes.
>GPS chips from 2011’s Sirfstar IV onwards draw so little power (max 30mA whilst doing acquisition, 8mA normally and less than 0.1mA in warm standby) that they’d have a hard time running the battery down
Alas, they suck badly in other ways. Their performance is generally poor, and execrable in weak-signal conditions. And whatever portion of their firmware interprets control commands is seriously flaky.
> Alas, they suck badly in other ways
Yes, and the documentation restrictions of certain portions of their binary protocol doesn’t help.
Not that it’s stopped a lot of copies of the documentation getting out. (It turns out that there _is_ a way to knock them out of their proprietary binary mode into 1 or 10Hz NMEA operation.)
Afterthought:
I have discovered that Samsung’s sirfgps driver contains a number of CarrierIQ hooks and possibly sections of CIQ code. This is one of the “other perils” of closed source software.
At what point does one start deciding that public interest overrides a company’s secrecy?
The steps in the article below has stopped my Galaxy S4 gpsd battery drain
http://thedroidguy.com/2014/10/samsung-galaxy-s4-problems-errors-questions-solutions-part-43-98682#Problem1
I have had this problem already three times. Once ~1 year ago, second about 4 months ago. In both cases I searched, searched, and deeply searched inside the phone. No solution ever worked. The only solution was to reinstall the OS. A different OS each time. I did try each and all solutions, indeed. The third time was 2 days ago. This time, again: nothing worked. Not having the interest to fully reset my phone (it takes a long time to get all back as desired) I searched for some other solution.
I decided to rename the gpsd executable in /system/bin to gpsd.trash, as suggested here: http://forum.xda-developers.com/general/help/gpsd-keeping-phone-awake-time-t2846721 PROBLEM STOPPED, IMMEDIATELY.
Of course, that solution demands having the phone rooted, the use of terminal app, and some Linux commands (ls, cd, mv), but it worked for me in 10 minutes. The problem went away.
Sure, I will need to make the gps available sometimes, but that is not a serious problem, once the problem can be controlled.
So, Sorry, you are wrong, that’s fact. The gps daemon is involved in quickly draining the battery.
>The gps daemon is involved in quickly draining the battery.
By coincidence, I actually found what is likely the root cause of the problem earlier today, working with a guy who had tripped over it on a Raspberry Pi. The bug is in select(2), but we’ve added an adaptive delay that slows down the select loop when it’s buzzing. The workaround will be released in the upcoming 3.12 version of GPSD.
Hi ESR,
Any idea of when this will happen? How will we be able to upgrade gpsd?
Regards
>Any idea of when this will happen? How will we be able to upgrade gpsd?
Probably this Sunday. I’m about to ship 3.12.
Hi ESR,
I am no developer or have any such knowledge on phones or so. How can we get hold of the new gpsd and how do we update the existing one?
>I am no developer or have any such knowledge on phones or so. How can we get hold of the new gpsd and how do we update the existing one?
http://catb.org/gpsd/
http://forum.xda-developers.com/showthread.php?t=2623112
Just a quick update, I managed to solve this problem by setting Network mode to WCDMA only.
After reading all over the net about GPSD battery drain, I concluded that my problem could be either caused by :
a. Misbehaving app (not my case) or
b. Radio interface problems (my case)
As it turns out, my local signal situation (Ecuador) is so “jumpy” that setting Network mode to Auto Connect, cause continuous GPSD wakelocks which didnt let my device go into deep sleep.
i found a solution to the cursed gpsd hell. . tried everything. . master resets. . rebooting dozens of times. . disabled everthing on my galaxy s4. . rooted and custom roms. . nothing worked. . gpsd refused to stop. . i sat down with a hammer in my hand ready to smash the phone when it hit me. . its not the phone its was the sim card. . yes the sim. . turns out that my galaxy s4 is a gt-19500 model. . its not a LTE/4G phone. . the sim card is a mtn network sim with LTE activated. . what i done is . . went to settings. . connections. . more networks. . mobile networks . .network mode and set it to GSM only. . bloody hell . . it worked. . installed my stock 4.2.2 firmware again. . left nothing disabled or uninstalled for testing. . the phone runs like new. . only downfall is that its running on a slower edge network. . my wife is using the s4 . .she mostly use it for whattsapp and dont do downloads and stuff. . I’m still convinced that its a network problem because the phone was fine for more than a year and a half with the same sim card thats LTE activated. . will see what happens after a week or so to see if the phone will run on HSDPA network without triggering the bloody gpsd. . i think MTN must have made changes to the network that affected thousands of phones. .
I solved the problem , yes it is not gpsd , it is the find my mobile->romote controls service is turned on . It is used by samsung account to trace and find your mobile if lost. I couldn’t turn it off , but when I removed samsung account it is turned off , and everything thing is fine now . I hope this would help .