Location provider drains battery

[mvglasow]

It appears that, once accessed, the location provider remains active in the background and drains the battery. I noticed the following:

I opened SatStat on my way to work (the satstat-location branch, which accesses the network location provider) and looked my position on the map for some time. Then I returned to the home screen and switched the screen off.

I briefly used my phone at work on a few occasions – no calls, just briefly checked my email once or twice – and noticed that the back of the phone felt warm to the touch, and the battery was draining quickly. When I went home, it was around 20%. Battery usage statistics showed Phone as the biggest consumer (72%), the second one being SatStat (11%).

I have checked the code of SatStat to rule out any errors there. SatStat registers with location providers in two places:

• GpsEventReceiver registers with the passive location provider – this should not put any strain on resources as long as no other location provider is in use
• MainActivity registers with the location providers selected by the user (in that case, I had selected GPS and network) in onResume() and releases them in onPause(). Since there is no way to selectively release a single location provider, all providers are released simultaneously.

As I returned from SatStat to the home screen, I noticed that the location notfication icon went away, indicating SatStat had released the GPS (and thus also the other location providers held by the MainActivity’s context).

This leads me to the suspicion that the location provider stays active even after it is released by all apps, when it should really cease all activity until it is needed again.

[mvglasow]

PS: this issue might be related to #6

[rtreffer]

Hmm, I highly doubt that the location provider would account for a battery use on "Phone".

It is running as it's own process and should thus be accounted as it's own process. Anyway, I've just installed the branch, ran the map (which triggered the lp) and will give it a try.

[rtreffer]

I can confirm via logcat that the lnlp is active, but I don't see a high drain... I'll keep an eye on it for the next 2-3 days.

[rtreffer]

Could you provide some more information? I'd specifically interested in

• Device
• OS version (ROM + Version)

[mvglasow]

Device is a Nexus S, OS is Cyanogenmod 10.2.1-crespo (Android 4.3.1), baseband I9023XXKI1

[mvglasow]

I re-ran the same test on my way to work today. However, before I did, I removed the lp from UniversalNLP and rebooted the device. Right now I’ve been on battery for almost 8 hours, and it is at 84%, with the biggest consumers being screen (33%), SatStat (20%) and Wi-Fi (17%). Phone does not even show up in the list.

[rtreffer]

Could you do another test with the LNLP? It must be some interaction on the system... I'm getting 24+h on battery on my old Galaxy Nexus... There is no way the provider could cause this alone

[rtreffer]

(I'm carrying that phone around to test my own free software only rom... I'll try outdoor usage at home with SatStat and switching then, it might make a difference.... This sounds like a really nasty bug)

[mvglasow]

I reenabled the lp and fired up SatStat again, then returned to home screen. Three hours later, Phone was the top power consumer again, so it appears to be related to the lp being enabled. Though it might also be a bug in OpenNLP rather than the lp.

On June 4, 2014 4:50:11 PM CEST, Rene Treffer notifications@github.com wrote:

(I'm carrying that phone around to test my own free software only
rom... I'll try outdoor usage at home with SatStat and switching then,
it might make a difference.... This sounds like a really nasty bug)

---

Reply to this email directly or view it on GitHub:
#8 (comment)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[mvglasow]

I ran another test with AppleNlpBackend instead of LocalGSMLocationProvider. (Added one, removed the other from UniversalNlp provider list). This time battery usage was moderate, which points to the lp rather than UniversalNlp.

As for how battery usage by the lp would be shown: if the lp makes some calls which get processed by the RIL, they would probably count towards Phone's battery usage.

Some pointers (if you haven't come up with them yourself anyway):

• Does the lp have any way of knowing if there are still any apps listening to it?
• Does it get notified when the last app unregisters?
• Do you disable any polling/processing when no more apps are listening?

[rtreffer]

I do not start sticky and I do listen to the UnifiedNLP close method. I'll have to add some sort of ref counting to stop the listeners, but that shouldn't be too hard...

[LuccoJ]

I get high wakelock count from RILJ in particular (which falls under the "Phone" umbrella), but I haven't tested whether this happens with UnifiedNLP in general, or just with this backend.
The battery impact, however, is definitely very noticeable (from 6 days standby to a bit more than 1, last time I checked, on a Galaxy S3 i9300 running OmniROM).

[rtreffer]

@LuccoJ thanks, that makes sense (rild dependance would explain why results vary largely). What tool did you use to debug that?

[rtreffer]

I'm also checking if I can assume that I've got no bound services or if I have to check the update call frequency....

[LuccoJ]

I checked with Wakelock Detector (and BetterBatteryStats, but couldn't make much sense of the latter).
However, now I upgraded to Android 4.4.3 (still OmniROM), and apparently the names of things like RILJ have changed, and while the phone still stays awake all the time, I'm a bit confused as to which service is causing the wakelocks now (ConnectionManager maybe?).