Open mvglasow opened 10 years ago
PS: this issue might be related to #6
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.
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.
Could you provide some more information? I'd specifically interested in
Device is a Nexus S, OS is Cyanogenmod 10.2.1-crespo (Android 4.3.1), baseband I9023XXKI1
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.
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
(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)
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.
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):
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...
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).
@LuccoJ thanks, that makes sense (rild dependance would explain why results vary largely). What tool did you use to debug that?
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....
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?).
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.
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.
@rtreffer would you push those patches to github ?
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!
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!
@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.
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.
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).
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 useMainActivity
registers with the location providers selected by the user (in that case, I had selected GPS and network) inonResume()
and releases them inonPause()
. 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.