zlacker

>>openge+(OP)
From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064

> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.

>>jasonj+25
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.

Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.

>>izacus+vb
Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.

>>homebr+Kc
They did, the upstading app developers like this one just forced people to give them full access to all data in the app (or the app wouldn't run) and ended up not implementing scoped storage - something HNers outright demanded several times and exposed as a good upside of iOS.

So stick had to come out. The full filesystem access is now reserved for apps that manage full filesystem (e.g. file explorers) and that's it. Scoped storage APIs were introduced in 2013, 11 years ago and Play started enforcing them in 2020, so the experiment with scary warnings was running for 7 years and developers refused to give up on that sweet full private file access.

Granted, SAF is quite a shitty API.

>>izacus+Xd
I mean, syncthing is exactly the kind of app I would expect to have full filesystem access.

>>monoca+Ae
Why? I want it to have access to the folders I want it to sync, not everything on my device.

Seems like a perfect fit for SAF.

>>growse+ng
In a perfect world, what Syncthing does would be handled at the OS level and all OSes would seamlessly interoperate. In the real world the OS vendors are hostile to interoperability so the only way to get that is with a third-party tool that has OS-level access.

>>lukesc+2j
In reality, Syncthing is also pretty good at destroying battery life unless you go above and beyond to configure it in a way that then hampers Syncthing's ability to provide seamless file continuity between devices. I know that there will be disagreement here, but in my own opinion OS vendors are correct in being hostile to these apps under current circumstances. They could provide better ways to have third parties implement it and provide cross platform support for their platform solutions, but I've had Syncthing be the #1 cause of battery life drain on multiple devices and platforms before and it's honestly just not worth fighting with it. To get it under control relegates it to being not much better than rsync.

>>evildu+Dy
I think it's important to draw a distinction between OS providers and app store providers here. The fact that they're the same entity in most cases is or should be largely irrelevant.

OS vendors shouldn't make it impossible to create apps that have unlimited access to the filesystem or that suck battery in the background. There are reasons users might want to run apps that do either or both - a file indexer, for example. All the OS should do is ask the user if the app has permission to do those things.

An app store provider on the other hand might reasonably have many criteria for inclusion, such as F-Droid only allowing FOSS. This only becomes problematic when the app store in question is effectively a monopoly.