Background: Syncthing is an open source automatic file synchronisation project. As such it needs permissions for full access to a device's filesystem. Since Feb 2024 Google Play has been rejecting updates to the app because it requests this permission, but without any sensical reason. The maintainer who handles this has repeatedly re-submitted with clear reasoning, but has no option but to cease requesting reviews as a result of repeated insubstantial rejections.
When I use Syncthing-Fork, it uses the Android storage system to request access to the specific folders it syncs too. Does the OG SyncThing not have this? Is that somehow still not sufficient?
I've been using OG Syncthing from the Play Store for a long time but was just looking through F-Droid and noticed this Syncthing-Fork and then I see this comment about it. Looks interesting. You recommend it?
FWIW, I just checked and the only permission I have granted to SyncThingFork is "notifications".
I think it optimistically requests all, but I can testify that it works fine without granting it all storage access. I just had to create/select a subdir in my SyncThingFork directory.
I don't really know how the restricted storage access works. Maybe it's that if /another/ app has already claimed a directory, that SyncThing needs more permissions to be able to sync it? But that seems unlikely, just speculating.
Sync in background can be achieved using Storage Access Framework APIs, where Syncthing can get access to directory trees without requesting any special extra permissions - that's right, no need for READ_EXTERNAL_STORAGE or the one I'm guessing the OP uses, MANAGE_EXTERNAL_STORAGE.
The API is available since Android 4.4. The requirement to use it instead of asking for access to all documents, private photos, personal data and other data on the phone is there from Android 10 (that's 4 years now).
It's telling that the author isn't actually saying why they're rejecting him - I bet they're telling him the app doesn't need access all private photos just to sync a directory and that the app should use the API that's been mandated 4 years ago. There's even a fork that does exactly that and is published just fine.
In other GitHub Issues (I don't have the tab open, they might have closed it) the author discusses using that permission but says they are not able to because the Storage Access Framework is only available for Java/Kotlin apps, where syncthing is written in go.
The author of Syncthing-fork has actually said they've had similar problems with Google and believe it's only a matter of time before their app is locked in a similar way - so much so that they are planning to surrender their Play developer account:
> It's telling that the author isn't actually saying why they're rejecting him
Have you ever tried to publish apps on the play store? They often don't give you a reason that it fails, you're just left to keep trying different things randomly until it works, and then later fails again when you changed nothing... there is a documented history of this happening to many projects.
I know several FOSS projects that do not have the knowledge/time/desire to implement SAF support, and for some projects it doesn't make much sense or might be invasive to the user experience, and their play store versions have since been stuck at old versions and they just moved on to F-Droid and other appstores.
Yes, I've been doing this for a long time now and I've also helped convert several apps to the new SAF framework when the restrictions came out. I've also helped many companies and people with these kind of issues and in most cases it's been self-inflicted.
The policy there was always very clear - you need to use SAF unless you're building something that absolutely function with it (these are pretty much exclusively file explorers).
Syncthing can use SAF, the author just refuses to according to their bugs. This counts as "self-inflicted" and I'm not sure why they think they can complain their way out of it.
I'm in a similar boat with one of many android app updates on Google Play. Over the last couple of weeks I pushed out updates to dozens of app listings with one app review rejected due to failing to disclose data my app absolutely does not collect. Specifically, a user's phone contacts. An app has to disclose on the store listing that type of data if it's transmitted off of the device. So I have this false positive with my initial appeal denied. I'm not sure how to move forward. Concede and change my Data Safety form on the listing? Insist false positive again? I'm in a bit of deadlock.
I like having one-purpose simple apps with no ads, and OSS if possible.
I have switched to FDroid and download apps from there even if the same apps are available from Google Play Store. Like VLC, Syncthing, Ankidroid, etc.
I also switched to OSS alternatives from FDroid, deleting Play Store apps, and I have zero regrets. Some examples-
1. Antennapod is better podcast player than anything on Play Store, like Pocket Casts, Podbean, etc.
2. Voice is the best audiobook player for local files for Android.
3. Feeder is a great RSS reader. Can't use anything else here.
FDroid is not only useful, it is fun, too. I have an app called Bubble which is a spirit level app using the phone's sensors. It's like using Windows in the 00s, and discovering indie apps and playing with them.
It also has apps like Exodus where you can check permissions used by apps to check suspicious permissions.
22 comments
[ 4.8 ms ] story [ 58.1 ms ] threadPerhaps it only does this if the user wants to sync data outside the SAF?
I think it optimistically requests all, but I can testify that it works fine without granting it all storage access. I just had to create/select a subdir in my SyncThingFork directory.
I don't really know how the restricted storage access works. Maybe it's that if /another/ app has already claimed a directory, that SyncThing needs more permissions to be able to sync it? But that seems unlikely, just speculating.
The API is available since Android 4.4. The requirement to use it instead of asking for access to all documents, private photos, personal data and other data on the phone is there from Android 10 (that's 4 years now).
It's telling that the author isn't actually saying why they're rejecting him - I bet they're telling him the app doesn't need access all private photos just to sync a directory and that the app should use the API that's been mandated 4 years ago. There's even a fork that does exactly that and is published just fine.
Do you think Apple would accept that excuse?
https://github.com/Catfriend1/syncthing-android#about-play-s...
Have you ever tried to publish apps on the play store? They often don't give you a reason that it fails, you're just left to keep trying different things randomly until it works, and then later fails again when you changed nothing... there is a documented history of this happening to many projects.
I know several FOSS projects that do not have the knowledge/time/desire to implement SAF support, and for some projects it doesn't make much sense or might be invasive to the user experience, and their play store versions have since been stuck at old versions and they just moved on to F-Droid and other appstores.
Many of those FOSS projects keep thinking Android is Linux, and then act surprised when it is not.
The policy there was always very clear - you need to use SAF unless you're building something that absolutely function with it (these are pretty much exclusively file explorers).
Syncthing can use SAF, the author just refuses to according to their bugs. This counts as "self-inflicted" and I'm not sure why they think they can complain their way out of it.
I have switched to FDroid and download apps from there even if the same apps are available from Google Play Store. Like VLC, Syncthing, Ankidroid, etc.
I also switched to OSS alternatives from FDroid, deleting Play Store apps, and I have zero regrets. Some examples-
1. Antennapod is better podcast player than anything on Play Store, like Pocket Casts, Podbean, etc.
2. Voice is the best audiobook player for local files for Android.
3. Feeder is a great RSS reader. Can't use anything else here.
FDroid is not only useful, it is fun, too. I have an app called Bubble which is a spirit level app using the phone's sensors. It's like using Windows in the 00s, and discovering indie apps and playing with them.
It also has apps like Exodus where you can check permissions used by apps to check suspicious permissions.