Feature (Android App): Folder Override Run Conditions

Allow a synced folder to bypass global run condition rules.

A use case would be to allow a folder containing small files permission to use mobile data for more timely updates.

This was already asked several times.

This cannot work as proposed, as the current run conditions start and stop the syncthing binary. So either syncthing is running, or not.

But you can use something like tasker to react to network change and (un)pause the folders that should not run on mobile data.

Any chance the last five years of development might make this feasible? I would expect that app starts or stops could first check if there were folders that had an exception?

I’d prefer it to work this way because the way it currently works, if I must enable it to be on for mobile data globally, across multiple phones there’s a good chance I forget to set a custom condition for each folder not to run. It’s much easier in my flow to opt in the folders I want to override a global preference.

Just to be clear, are you using Syncthing-Fork? The official application is no longer developed.

That’s correct, using the Syncthing Fork for Android. Hope this is the right place.

I got here by attempting to make a new issue in Github at GitHub Ā· Where software is built and when I selected ā€˜Request a new feature’ it redirected me to this forum.

Hi,

I’ve already answered ā€œrun conditionsā€ related suggestions in multiple places. In short, I am no longer interested in adding more code/complexity to the run condition monitor (the part of the app is called like this). At first it was fun improving that part - now it’s a bad stomach feeling for me that those kind of ā€œbackground conditions monitoringā€ is very likely to break or then end up partly working after major Android version upgrades in the future.

We’ve had this for the wifi condition… as far as I recall, one example:

Android 8 - location was necessary to get the ssid

Android 10 - the saved ssid list could no longer be read

Looking at how much work the ā€œTasker devā€ or similar apps’ devs put into their background condition monitoring to still work on Android’s modern ā€œdon’t run foreground services forever, don’t waste battery, don’t hold excessive permissions the app’s main purpose doesn’t requireā€ ecosystem like my perception is, I am not interested to do the ā€œsameā€ or ā€œsimilarā€ work to put this into the Syncthing-Fork app and test if it works. Costs a lot of time… sorry.

But there’s one good news: a fix is incoming these days for the remote control by intents the app already has builtin. Some users said, intents hadn’t fired due to a bug. I’ve fixed this :slight_smile: . So if you need more granular run conditions, you could be able to use Tasker and similar tools again. I also recall Tasker was able to send rest api requests when I last used it years ago. That could also help pausing and unpausing folders or devices more granular instead of using the fork app’s builtin options.

4 Likes

Thanks for this explanation @Catfriend1 and sorry to make you repeat. Given what you’re describing, particularly the churn in Android’s performance and security changes, I can relate to not wanting to disrupt what’s working well even if the flow could be streamlined. Carry on!

1 Like