Power consumption is up on Nexus 5

[crankycoder]

User bug reported: "The last 2 or 3 updates seem to have regressed motion detection on my nexus 5. Even overnight where the phone is completely motionless, seems to continually scan and not pause causing significant battery usage."

[sshvetsov]

I've got Nex5, so I can try verifying this. Any suggestions on the test procedure?

[crankycoder]

I think you just leave the phone idle overnight while you sleep. If significant power drain happens, then we have a bug.

[sshvetsov]

Did one test last night. So far doesn't seem out of the ordinary, just 1% consumption by MozStumbler when stationary over period of 7 hours, compared to 7% over period of 2 hours while moving. Will do another test tonight.

Test 1: Phone laying on the desk over night: Trip to work:

[sshvetsov]

Second test produed similar results. Here are the screen shots from my tests:

Test 2: Phone laying on the desk over night: Trip to work:

[dhawkshaw]

Hi, I'm the original user reporting this issue.

I can confirm that settings for power saving were originally set to 'Significant Motion'. Changing back to just accelerometer still causes a similar drain. Here's a screengrab showing last night's typical usage set as accelerometer. I'll run another one this evening with the significant motion setting. Let me know if there's anything else I can do.

[crankycoder]

Thanks @sshvetsov and @dhawkshaw ! Getting real metrics on power drain from real devices is tough.

My expectation here for a normally function Nexus 5 is that the significant motion sensor will have dramatically lower power consumption than the plain accelerometer sensors. The code was originally written targetting the Nexus 5 and Samsung Galaxy S5

The significant motion sensor code runs partially in the driver layer and presumably in hardware so it uses very little battery. The regular motion sensor code has to run entirely in CPU so it will use more power, but there's not much we can do about that.

Some devices may have malfunctioning significant motion sensors. In fact, we've whitelisted only the Nexus devices and OnePlus One to use the significant motion sensor by default.

https://github.com/mozilla/MozStumbler/blob/dev/libraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/Prefs.java#L69

@dhawkshaw if your device still uses a lot of power with the signficant motion sensor enabled in 1.7.7 over night, I think something is wrong with either your device or your ROM. Please let us know what you find tonight.

[dhawkshaw]

Funnily enough. I think I might have fixed it. Following from my previous post, I thought it wise to do a full phone shutdown/reboot, which I'd already done prior to initially reporting my issue. However, switching back to Significant Motion, I was prompted to re-teach the sensor setting. Over the last couple of hours since posting my (sorry overly large) screenshot, Stumbler is happily pausing whilst laying on my desk.

I have a feeling that one of the updates (1.7.6 ?) may have glitched the significant motion settings, and that going through the re-teach, things are good again. I'm going to go through tonights run/idle test though and post my findings just to make sure.

If things do seem ok after tonight's test, it moves the goalpost to say 'why did the settings get glitched on the update' :)

I'll keep you posted.

cheers

Darren

[dhawkshaw]

Ok, I'm still stumped. Here's last night's activity. I made sure the nexus was fully charged before retiring. Stumbler is in Significant Motion mode.

I've turned on save logs under the developer screen, and when I get some I'll post some proper snippets. Before the current log disappeared from the screen view though, there were a significant number like this --

10:28:38 : Sleep for 20000ms 10:28:38 : Is motionless: true 10:28:38 : MotionSensor:NetworkLocationChangeDetector triggered. 10:28:38 : Is motionless: false

Which doesn't seem right.

Let me know if there is any further troubleshooting I can do.

[dhawkshaw]

Here's what the log looks like in a period where I would expect scanning to be paused.

[crankycoder]

That's really strange. The network location listener is used to help buggy significant motion sensors Wake up. In your case though, the network should be stable if it's really at rest.

Is your device rooted and/or have anything in usual relative to a stock android device?

[dhawkshaw]

My device is completely stock with google OTA updates currently on lollipop and no 3rd party app store sources. The strange thing for me is that it does indeed pause from time to time. Could one possible link be that there isn't an available GPS fix at the time, relying only on cell/wireless telemetry. I'm certain that the device hardware is ok, since I am getting occasional pauses, and prior to a couple of weeks ago Stumbler was working absolutely brilliantly.

I'm aware that this thread is getting longer, and I don't want to be wasting your time with it, I'm sure you've got much more important problems to solve -- If there's any thing I can do to help troubleshoot this, I'm more than willing, but equally I'm happy for you to close this with a 'can't reproduce' if required at your end.

[crankycoder]

I wonder if this is a 5.1 issue. We haven't tested against that.

We've got nexus 5 devices around, we'll try to reproduce it this week and follow up. On Mar 22, 2015 12:44 PM, "dhawkshaw" notifications@github.com wrote:

My device is completely stock with google OTA updates currently on lollipop and no 3rd party app store sources. The strange thing for me is that it does indeed pause from time to time. Could one possible link be that there isn't an available GPS fix at the time, relying only on cell/wireless telemetry. I'm certain that the device hardware is ok, since I am getting occasional pauses, and prior to a couple of weeks ago Stumbler was working absolutely brilliantly.

I'm aware that this thread is getting longer, and I don't want to be wasting your time with it, I'm sure you've got much more important problems to solve -- If there's any thing I can do to help troubleshoot this, I'm more than willing, but equally I'm happy for you to close this with a 'can't reproduce' if required at your end.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/MozStumbler/issues/1579#issuecomment-84651799 .

[sshvetsov]

Actually, my tests above were done on 5.1. I didn't notice any issues with power consumption.

[dhawkshaw]

Just to confirm, I'm still on 5.01 build LRX22C as the very latest build hasn't been pushed my way yet.

[crankycoder]

@dhawkshaw we just cut a v1.7.8 release on github - can you give it a whirl to see if this makes sleep better for you?

[cascheberg]

@crankycoder The v1.7.8 Github release crashes as soon as scanning starts, but my local debug build does not

[crankycoder]

Crap. We had to create a new build box which took all day. Something must be screwed up even though we had an EBS volume. On Mar 24, 2015 6:29 PM, "Christian Ascheberg" notifications@github.com wrote:

@crankycoder https://github.com/crankycoder The v1.7.8 Github release crashes as soon as scanning starts, but my local debug build does not

— Reply to this email directly or view it on GitHub https://github.com/mozilla/MozStumbler/issues/1579#issuecomment-85719449 .

[garvankeeley]

I just switched 1.7.8 to pre-release so 1.7.7 is reported as the latest

On Mar 24, 2015, at 6:30 PM, Victor Ng notifications@github.com wrote:

Crap. We had to create a new build box which took all day. Something must be screwed up even though we had an EBS volume. On Mar 24, 2015 6:29 PM, "Christian Ascheberg" notifications@github.com wrote:

@crankycoder https://github.com/crankycoder The v1.7.8 Github release crashes as soon as scanning starts, but my local debug build does not

� Reply to this email directly or view it on GitHub https://github.com/mozilla/MozStumbler/issues/1579#issuecomment-85719449 .

� Reply to this email directly or view it on GitHub.

[garvankeeley]

1.7.9 is up and working.

[crankycoder]

@cascheberg see #1594 for what happened with the crashers. proguard is terrible.

[dhawkshaw]

I've installed 1.7.9 and will let you know how I get on after a couple of days of testing.

[dhawkshaw]

Running 1.7.9 I think it may have even got worse. The previous version at least whilst it was on my desk at work was pausing ok. It's now not pausing at all. See screenshot of logs.

I'm starting to think that this is all about environmental conditions -- state of or lack of gps or unstable cell tower information.

[crankycoder]

@dhawkshaw Let's verify that.

Can you go into your Android location settings and use battery saving mode? That should disable the GPS.

Go into google maps and let's see what location google maps reports. I'm interested in the stability of the location fix that Google manages to get.

[cascheberg]

I can reproduce this, my setup:

• disable wifi and disable "scanning always available"
• disabled GPS
• enabled Google location service

The location estimation is now based only on cell towers. The location uncertainty overlay has a radius of ~1.3km, and the center is off by ~100m compared to my actual location.

In the motion sensor's onLocationChanged I computed the distances to the previously reported location. The average is ~60m, but it can be up to ~200m. Sometimes it's even below the 30m threshold (computed using location.distanceTo()).

[dhawkshaw]

Based on the comment above, I changed my settings to match. and the uncertainty overlay jumped to about a 1.3km radius with the epicentre about 0.8km from my actual location. Stumblers map view showed uncertainty with about a 5km radius. Is there anything else I need to provide.

[crankycoder]

@dhawkshaw, @cascheberg 1.7.10 is on github with some more changes to the network location listener. Let us know if this helps.

[dhawkshaw]

@crankycoder @garvankeeley @cascheberg 1.7.10 is looking good so far. Successfully pausing having heading into and back out of cell/gps range (I work in a bad reception area). I'll see how I get on tonight with the overnighter and post results. Thanks so much for all the hard work you guys do.

[cascheberg]

This is still failing sometimes, because (of course) I still get distance changes of up to ~200m with my cell only config. If you want to have less false positive wakeups, maybe you could require a higher threshold if the accuracy is low. For comparison, the accuracy in my area using wifi is ~20m, location distance diffs are ~2m.

[garvankeeley]

The cell-only config seems like a 1% use case we shouldn't spend time on fixing. Opinions?

[crankycoder]

I concur. If GPS and wifi is disabled, there's really not much value here. Realistically, the stumbler when used in the Android client is intended to be used as an active stumbling client to pull in as much data as possible.

I mean really - if you're on cell only - some places have only 1 tower and your possible position may vary a lot. Let's ignore this for now until we get a lot of problems.

I propose that if @dhawkshaw's overnight power consumption problems go away with this build - we close this ticket.

[cascheberg]

GPS is not used in the motion detector, I only disabled it for debugging purposes, but I see your point ;)

[dhawkshaw]

Good news everyone. Last nights test was a complete success.

There were only 2 movement blips measuring 5400m, which I think we can completely ignore as an unfixable error bar. During early evening, I got a handful of blips measuring 30 something to 68m where the device was on the cusp of picking up and dropping gps, but there was still enough pausing in between to not impact battery at all.

So for me at least, I'm happy for this to be marked as fixed. I'm just sorry I caused you guys so much trouble :) Keep up the excellent work !

[herrdeh]

On my Huawei y300, running slimkat 4.4.4, MozStumbler is eating an awful lot of battery power even when it's switched off. The symbol remains in the top bar, and I get around 17% / hr instead of round 2%.

So I ever have to kill it in order not to lose all my battery charge - quite annoying.

[Djfe]

While you are not moving? Or in general?

[herrdeh]

Ok, I'll check that.

But the app symbol ever remains in the menu bar, making me believe that the app doesn't close. I know, that's 'according to the book', but nevertheless confusing as hardly any app still is doing so.

[Djfe]

as long as you don't press the stop button in the app or in the notification bar, MozStumbler will keep on scanning in the background

if you pressed stop the service should be stopped though and there shouldn't be any icon in the notification bar anymore

[herrdeh]

Yes, so thought I.

But on my phone (Huawei y300, Slimkat 4.4.4) the menu bar icon remains in place and the menu bar message all the time says "Mozilla Stumbler is scanning, 92 reports, 8 cell towers, 474 WLANs". That only disappears when I'm killing MozStumb in settings -> apps.

Energy consumption seem to be allright - nothing, when MozStumb is not active - but the message is confusing and led me on the wrong track.