You can try to whitelist the app as doze exemption manually by adb command. More info about this is on the wiki. For Android 7.0, I never found a solution as doze was there on the most aggressive level.
Yes that’s right in case apps register for the wake up. SyncthingNative is a Linux binary so it can’t tell the Java world to wake up using Android methods.
Some time ago I thought about a solution with jobscheduler , that would raise min API level higher and cause the app to be incompatible with older Android versions. Since Android 7.1 the behavior is better again what leaves me unsure if it’s worth to try the scheduler solution just for a single Android version.
Ok terminating Android 4.x since release (tbd) could be done as it’s very old. Here’s another workaround:
Enter tcp4://phone_ip_addr on the computer’s syncthing instance. Does it help? (Confirmed working on Huawei devices)
We are exempting from doze and thus don’t need those maintenance windows. Hmm I recall your GitHub name crocket, so we’d already had a long discussion about this doze issues.
SyncthingNative (go process) is about continuous file synchronization so will not fit your approach of letting it work in an Android defined maintenance window as there nothing would take care of starting or stopping the binary correctly.
It seems partial wakelock is the only reliable way to keep the connection alive. Disabling battery optimization has little or no effect on connection reliability.
With partial wakelock, disabling battery optimization is unnecessary.
Disabling battery optimization has no visible effect on connection reliability.
I suspect that syncthing does its work in doze maintenance windows without partial wakelock.