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.