Time schedule syncs don't work when device idle

[ChimaeraXY]

I've noticed my syncs weren't triggering when I set long cycle durations (3+ hours) and leave the device idle for long periods.

Disclaimer: I know nothing of Android development, but I suspect the issue is SystemClock.uptimeMillis() under-reporting uptime when the device is idle (/DeviceState.kt, https://developer.android.com/reference/android/os/SystemClock). I can somewhat confirm this is happening because logcat time and "Time window updated:" list a time since boot much shorter than actual uptime.

Would elapsedRealtime() work better?

Big fan of your work. Keep on keeping on.

[chenxiaolong]

Glad you like the app and thanks for reporting this!

Oof, this is a nasty bug. I knew this could happen, but forgot about it because the apps I run on my test device rarely allows it to enter deep sleep. Most sleep and delay functions, like the Handler.postOnTime() currently used, only operate based on SystemClock.uptimeMillis(), so I'll need to switch to some other mechanism. Just switching to elapsedRealtime() won't be enough.

AlarmManager probably makes the most sense, since it allows for explicitly specifying the realtime clock. I can use the AlarmManager.set() variant, which allows for some wiggle room for when it fires to save battery, but does not require alarm clock permissions.

The original syncthing app used JobScheduler + https://developer.android.com/reference/android/app/job/JobInfo.Builder#setMinimumLatency(long), but it's not clear to me which clock is used and whether that's guaranteed to never change.

[chenxiaolong]

Could you give #84 a try and see if it behaves like how you'd expect? I've uploaded a test build below. These are signed with the release key, so can you update to them without reinstalling (and also update to future stable versions).

• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.20.r1.ge3c9287-arm64-v8a-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.20.r1.ge3c9287-armeabi-v7a-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.20.r1.ge3c9287-x86_64-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.20.r1.ge3c9287-x86-release.apk

[ChimaeraXY]

Unfortunately I don't have a test device I can deploy this on -- happy to report back how well this works when it goes to release.

[chenxiaolong]

No worries! I'll just merge #84 for now then. I think it should fix the problem, but even if it doesn't, it shouldn't make it any worse.

[ChimaeraXY]

One more thought; I have a different (backup) device running 1.11 (the device exhibiting this bug is running 1.16) and I could swear this issue didn't happen with the older version. Any changes since then which could have introduced this? I also suspect an Android software update.

Anyway, I've turned on that device and am monitoring it on 6h cycles. If it does sync on time, I'll dive deeper into its logs.

[chenxiaolong]

I can't think of any reason why the behavior would differ between 1.11 and 1.16. The time scheduling logic was completely unchanged between those two versions.

Android's doze mode is notoriously nondeterministic and painful to debug though. I wouldn't be surprised if the behavior changed just due to something mundane, like how long the app was installed.

[ChimaeraXY]

Hi, an update on this, as promised;

Definitely not fixed but better than before; when device sleeps during an interval, both sync and 'sleep' periods are still prolonged until the device wakes up again but the good news is that the alarms seem to trigger consistently as soon as the device wakes up for any reason, or within 45 minutes or so of the intended time based on interval.

Would alarmManager.setAndAllowWhileIdle() (and/or even maybe but probably not AlarmManager.ELAPSED_REALTIME_WAKEUP) work better? Maybe not an ideal solution since you'd need two of them in a row, one to start the service and one to pause it.

Thanks for looking into this.

PS: On further investigation, I wonder if this is worth fixing so absolutely if it would be overtly convoluted or cost significant battery power. It seems to be working as "Android" intends it to. Maybe there needs to be a disclaimer that, due to Android power-saving measures, syncs may start and stop up to 60 minutes later or longer than the user intends? It's just a bit odd to setup a 5m sync and watch the node stay up for about half an hour before it finally pauses. It's not something I would notice in day-to-day use. Shortening the sync time in my use-case (to be within the awake time) would probably resolve 90% of my issue.

[chenxiaolong]

Thanks for the update!

If it was only delayed a few minutes, I wouldn't mind, but a 45-60 minute delay makes the feature quite useless or at least not intuitive at all.

Would you mind running the build below to see if it helps at all? (No reinstall required.) This is 1.21 + switching to ELAPSED_REALTIME_WAKEUP with no other changes (#96).

• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.21.r1.g81daf66-arm64-v8a-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.21.r1.g81daf66-armeabi-v7a-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.21.r1.g81daf66-x86_64-release.apk
• http://files.pub.chiller3.com/issues/BasicSync/issue83/BasicSync-1.21.r1.g81daf66-x86-release.apk

I'm hoping this is enough to make things work more reliably. setAndAllowWhileIdle() (and even setExactAndAllowWhileIdle()) are constrained to 1 alarm per 9 minutes.