Increased Battery Consumption with Positioning Enabled in Manifest

Of course it's a bug. I don't know if it's the same bug, but I remember that a few weeks ago I saw a thread about something similar here in the forum from a few years ago. There was some developer who even found out what workaround he can do to completely disable the sensors (something like setting null fir callbacks). If I remember correctly he said that not doing this means that the sensor keeps being enabled even when the app exited and obviously the battery gets a hit. I wonder if something similar could have happened: your user maybe tried it with gps on, then even though he turned it off the gps could still be active when he expected and thought that it's off?

Seems like a bug to me.

Rick said:

Obviously, this is a very subjective test,

Here's one way to possibly verify what's strongly suggested in the video.

- on your own device, manually set the time to an incorrect value.

- change the time setting back to automatic (but do not allow the time to be synced via gps -- i.e. don't open an activity or an app)

- sideload the original version of the app (with positioning enabled in manifest)

- don't enable activity recording in your app

- open your app, go outside, and wait a few minutes (long enough to acquire a gps fix)

If the time changes to the correct value, then you can be sure gps is active.

Hey - I've just tried this on an Epix 2 and it works as I would have expected it to. My process was:-

1. Disable bluetooth on phone

2. Set time to Manual and adjust time so that it's wrong

3. Set time to Auto

4. Wait a few minutes under open sky - Time did not update

5. Start my App with Activity Recording (GPS) disabled. Wait a few minutes under open sky - Time did not update

6. Enable Activity Recording (GPS) in my app. Wait under open sky - Time updated within 15 seconds

Anybody with a Fenix 6 who could help out and do the same with a sideloaded app ? Please DM me.

That's a good start, but it doesn't eliminate the bug I mentioned above. What you should do now is : 1st open your app with gps enabled, then disable it, then change the time and then open your app with gps still disabled. If you hit the above bug, then MAYBE you'll see the time is setting. However maybe the bug is such that it does consume more battery but it doesn't receive gps,time updates.

Less scientific, but you could open your app with gps enabled for 1 hour, and measure the battery percentage lost in an hour, then do the same with gps disabled, and then restart the watch and wait another hour to see what happens when your app couldn't have done anything (maybe best is to delete it before you restart the watch)

I actually did that as well on my Epix 2 and the time did not update after quitting my app. All I can say is that the Epix 2 seems to work ok. I haven't experienced any noticeable change in battery life on the Epix either and I personally use this app around 8 hours a week. It may very well be isolated to the Fenix 6 and similar devices. I need to find someone with a Fenix 6 who's willing to test.

I found it: https://forums.garmin.com/developer/connect-iq/f/discussion/872/battery-drain-when-connectiq-app-is-not-running/1661071#1661071

See if it helps

Thanks I'll have a good read

My intuition says to call, as you do:

Position.enableLocationEvents(Position.LOCATION_DISABLE, null);

but the RecordSample uses:

Position.enableLocationEvents(Position.LOCATION_DISABLE, method(:yourMethod));

Might this be the problem? If we really need to pass the same method to unregister it, then this should be definitely added to the documentation.

And if passing null is ok (or better?) then that should be added to the documentation (and the RecordSample should be also adjusted)

Kyle.ConnectIQ can you clarify this in the next SDK release?

I think many developers would like guidance on this Kyle.ConnectIQ