Complete
over 2 years ago

Issue was unable to be reproduced. Issue most likely patched in a newer firmware update/SDK release.

Venu 2S Battery Drain with the Sensor Permission

The Venu 2S appears to have a bug where there is significant battery usage once you add the `Sensor` permission to your app. This is even for simple apps that never update the display, and don't use the sensors, as soon as you add the Sensor permissions, even if you never call its classes, this problem occurs.

On our Venu 2S unit we are using for testing, our test setup is as follows:

- Our battery test app - an app that just displays a digital clock, request update from watch UI every 30 seconds. We believe the issue would occur even if you never requested Ui updates.

- connect iq sdk 4.0.2

- Venu 2S firmware: 3.40

- Test hours - 11:30pm - 7:30am

- pulseOx set to measure at night

- Display Timeout medium

- Gesture sensitivity low

- Battery saver off

- Watch Battery drain without Sensor Permission <10% (this is the same whether you run the app or just are running the default watch face)

- Watch Battery drain with Sensor Permissions >25%

We've been trying to narrow down on the battery drain for a few weeks. In one of our other apps we noticed the problem, where the Venu SQ wasn't seeing a noticeable difference in battery while using our app, vs without. But the Venu 2S was seeing a significant difference which would result in us needing daily charging.  In our real app we changed our timers to only use the Sensor classes every 15 seconds (from 4) and were surprised to see no difference in the battery usage. We finally found that it happens the moment we add the Sensor permission on the Venu 2S

twk3
Parents
  • over 3 years ago in reply to jim_m_58

    The test app doesn't crash, because it doesn't actually use the sensors. And never calls enableSensors. But uses significant battery as soon as you add the permission.

    The real app also never calls enableSensors(), because it only ever calls getInfo in the timer, and doesn't attach listeners. Which according to the api docs would be 'on demand' but appears more like it just returns the last value it had. (Which is fine in my use-case)

Comment
  • over 3 years ago in reply to jim_m_58

    The test app doesn't crash, because it doesn't actually use the sensors. And never calls enableSensors. But uses significant battery as soon as you add the permission.

    The real app also never calls enableSensors(), because it only ever calls getInfo in the timer, and doesn't attach listeners. Which according to the api docs would be 'on demand' but appears more like it just returns the last value it had. (Which is fine in my use-case)

Children
  • over 3 years ago in reply to twk3

    Reboot didn't help. It still used >25% battery overnight when the app has the Sensor Permission.

  • over 3 years ago in reply to twk3

    But we will do another watch reboot and try again tonight (and with sdk 4.0.3). I'm sure we did a restart during our earlier testing of the issue, but its been at least a week since the last restart. (We've been running different versions of the test app nightly for a couple weeks to try and identify what triggers the drain)