Scheduled syncs seems to cause more battery drain due to frequent wakelocks

[Context6016]

I noticed that when I use the sync every hour option, my phone's deep sleep state seems to be interrupted more often and overall it causes more battery usage than letting syncthing run all day.

I'm using the accubattery app to track this and normally with my usage, the time in which the phone is in wake state is around 2 hours, if I use scheduled syncing it seems to increase it to almost 4 hours.

I'm assuming it's because of increased wakelocks due to the app trying to start syncthing while the phone is sleeping? (Pure speculation on my part, just from observation, I don't actually know how to read the code)

[chenxiaolong]

Hmm, does accubattery show any additional details, like the name of the wake locks? I would be very surprised if those wake locks were associated with BasicSync because BasicSync does not have the WAKE_LOCK permission.

[Context6016]

Hmm, does accubattery show any additional details, like the name of the wake locks? I would be very surprised if those wake locks were associated with BasicSync because BasicSync does not have the WAKE_LOCK permission.

Unfortunately it doesn't. My bad on the wake lock it's just a pure speculation on my part since that's what usually causes unusual battery drain on android.

In any case it doesn't actually increase it by a lot, normally I would charge my phone every 2 days but with scheduled I would need to do it in about 1 and a half day but I was just wondering if there might be an issue because it seems like the scheduled option should reduce battery usage.

[chenxiaolong]

Is there any chance the "Keep Syncthing alive" setting is disabled? That's the biggest battery drain I can think of when using the sync schedule, since Syncthing has to do a full rescan of every folder whenever it starts up after a full shutdown.

The only other thing I can think of is maybe the exact alarms causing issues on some devices. BasicSync uses those to set the time that Syncthing should start and stop. If the device is asleep at those two points in time, Android will wake the device and give BasicSync 10 seconds to process the alarm (starting/stopping Syncthing in this case). The device is meant to be able to go back to sleep after that 10 seconds since BasicSync doesn't hold any wake locks.

Ideally, fuzzy/inexact alarms would be used since Android tries to group multiple apps' alarms together and wake the device fewer times. But unfortunately, Android's delay for this is so unreasonable (upwards of 40 minutes) that it would make the sync schedule feature useless, so we're stuck with exact alarms.

[Context6016]

Is there any chance the "Keep Syncthing alive" setting is disabled? That's the biggest battery drain I can think of when using the sync schedule, since Syncthing has to do a full rescan of every folder whenever it starts up after a full shutdown.

The only other thing I can think of is maybe the exact alarms causing issues on some devices. BasicSync uses those to set the time that Syncthing should start and stop. If the device is asleep at those two points in time, Android will wake the device and give BasicSync 10 seconds to process the alarm (starting/stopping Syncthing in this case). The device is meant to be able to go back to sleep after that 10 seconds since BasicSync doesn't hold any wake locks.

Ideally, fuzzy/inexact alarms would be used since Android tries to group multiple apps' alarms together and wake the device fewer times. But unfortunately, Android's delay for this is so unreasonable (upwards of 40 minutes) that it would make the sync schedule feature useless, so we're stuck with exact alarms.

It's enabled, I've kept the settings at default.

[chenxiaolong]

Got it. If that's the case, I don't really know what could be causing your device to stay awake more often when the sync schedule feature is enabled.

If it really is the exact alarms, there's nothing I can do about it without ruining the feature. Android doesn't really provide useful tools for determining if that's the issue though.