Battery drain when ConnectIQ app is not running

I've had several users mention that they believe the Activity Recorder app is responsible for battery drain that they are seeing since installing. In my mind this is not possible; the application would need to be active in some capacity for this to happen. I've audited my code and noticed that I enable sensor and position events in some cases, but do not explicitly disable them on app exit. I've since updated my code to do disable them, but I'm still curious if this could be the source of problems.

I'm guessing that they're both affected by some sort of Bluetooth or WiFi issue, but have no evidence at this point.

Any thoughts?
  • noticed that I enable sensor and position events in some cases, but do not explicitly disable them on app exit. I've since updated my code to do disable them, but I'm still curious if this could be the source of problems.

    There is a chance this is the cause of the issue your users are seeing, but if it is, it is a device bug, and not something you should need to handle. However, if it is the issue, then the steps you have taken should resolve it.

    We will double check that the devices are disabling sensors/GPS when apps close as they should be.
  • Sir, 7 years elapsed, did you fix the issue? ;( 

    Some users have pointed out that my app is the culprit for the continuous power consumption.

    I don't think I should be responsible for the fast-drain after app exiting

  • Yeah same here. One user reckons by installing and not even running my app it drains the battery in 24 hours Uninstalling my app solves their problem apparently. Not sure how this is even possible. Garmin?

  • You have seen this thread has such a long history, 8yrs. Perhaps no one cares except we developers.

  • Be sure to close all sensors, set sessions and timers to Null on exiting. 

    Position.enableLocationEvents(Position.LOCATION_DISABLE, method(:yourMethod)); //not in the api but good to do if using GPS
    
    Sensor.unregisterSensorDataListener(); // if using a data listener, unregister
    
    Sensor.setEnabledSensors([]); // this is in the CIQ api
    
    Sensor.enableSensorEvents(null); // this is NOT in the CIQ api and is a Garmin bug.

    Sensor.enableSensorEvents(null);   This is the 8 year battery bug!!!  This setting to null is not in the CIQ api and needs to be done to close the event handler, otherwise the event handler will keep handling events after the app is close and will continue until a watch restart or the battery is 0%.

    The CIQ is not unregistering the callback and is being kept alive after the app is closed, thus causing the battery drain.   place a Null in the Sensor.enableSensorEvents(null) this will force the event to be canceled.   This unregistering bug will be patched in the 2023 4th quarter CIQ update. 

    I found this out last week from working with Garmin Engineering on the battery burn found in the Venu2, FR965, 955 265 and 255 lines.

    The battery drain will be reduced or eliminated entirely.

    Brian 

    Owner F3b Software

  • Thank you. Brian. I will try your method.

  • Hmmm, my app does not use any Sensors. It does however record an activity. ActivityRecording.SPORT_TRAINING but without GPS. I make sure the activity is stopped, discarded or saved on exit.

    Users still complain about battery drain after the app exits.

    Wonder if a similar issue with other callbacks not being released properly?

    I use a Timer.Timer() callback to update the screen. I did just assume it died when the app exited, maybe I need to stop on exit.

  • Bump this topic.  This is a serious issue with the Venu 2/3 and most FRx55 lines and newer.  My previous reply helped but this bug is not resolved.

  • Very interesting!

    Can you "update" the code example in the comment to include the following information: which one of the 4 of those are required in which case? What I mean is that obviously after Sensor.registerSensorDataListener i use Sensor.unregisterSensorDataListener(), but is that enough? Or the main takeaway of your debugging is that even then I need to use some of the other 3 "unregister" methods you posted? If yes which ones?