rtreffer / LocalGSMLocationProvider

Local opencellid based location provider backend for UnifiedNlp
Apache License 2.0
43 stars 10 forks source link

Location provider drains battery #8

Open mvglasow opened 10 years ago

mvglasow commented 10 years ago

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:

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 commented 10 years ago

PS: this issue might be related to #6

rtreffer commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

mvglasow commented 10 years ago

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

mvglasow commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

(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 commented 10 years ago

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: https://github.com/rtreffer/LocalGSMLocationProvider/issues/8#issuecomment-45100168

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

mvglasow commented 10 years ago

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):

rtreffer commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

rtreffer commented 10 years ago

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 commented 10 years ago

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?).

rtreffer commented 10 years ago

I'm still looking into this... I've added 2 small patches. I don't think they'll fix anything but they will help a bit...

I have opened a one-line pull request on UnifiedNLP because i've seen that a crash in this backend may result in an infinite unbound retry on UnifiedNLP (urghs).

I've also added a second service that can be used as a debug / introspection backend. I'll add some more functionality to debug issues.

Still on my TODO: make sure the service suspends itself if there is noone asking for a location (no update requests). I'll have to read more of UnifiedNLP before I can implement this, but it might solve the issues.

LuccoJ commented 10 years ago

Today I tried a few combination of location sources and saw what happened after some minutes. According to BetterBatteryStats, my i9300 could go into deep sleep when:

It does NOT go into deep sleep with the LocalGSMLocationProvider enabled in NLP Controller. So I suppose that points to the problem being specifically with this backend, or at least related to polling GSM/UMTS cells in some fashion.

I value being able to get network-based location offline, and I'm willing to conduct further tests as directed, but I don't know what to try next myself. I am able to use ADB, and I'm running the latest OmniROM nightly, with UnifiedNLP 1.0.1 and LocalGSMLocationProvider obtained from F-Droid.

aelmahmoudy commented 10 years ago

@rtreffer would you push those patches to github ?

haarp commented 9 years ago

Version 0.0.1.4: I'm also noticing moderate battery usage. After 2 days on battery, GSMLocationBackend has accumulated over 20 minutes of CPU time!

haarp commented 9 years ago

Seems to indeed be cell polling. In App ops, I can see that GSMLocationBackend has used "cell scan" around 7 and a half million (!) times. In the two months or so that I've been using it, that means it scans roughly every SECOND!

whitequark commented 9 years ago

@haarp That's literally what happens: https://github.com/rtreffer/LocalGSMLocationProvider/blob/master/src/org/gfd/gsmlocation/GSMService.java#L47-L48. I've tried to fix it in https://github.com/rtreffer/LocalGSMLocationProvider/pull/11#issuecomment-71332705.

h3r0n commented 9 years ago

On my device (Mi2S) I've tried this provider with several ROMs (CM11, PacMan 4.4, Mokee 4.4, CM12, AOSP 5.0, AOSP 5.1.1).

In all cases if I enable this provider, my smartphone never goes to "deep sleep" (Kernel Adiutor says that the "deep sleep" state is unusued) and is always "active".

If I disable it (leaving the other providers enabled, like the Apple one) "deep sleep" instantly works again and the battery lasts much more.

lambdaupb commented 9 years ago

I have the same Issue on CM12.1

It took a long time to find the culprit. Maybe it would be better to take it out of the F-Droid store since there does not seem to be an interest to maintain it (And alternatives are available).