> Reason is a combination of Google making Play publishing something between hard and impossible
Can someone expand on what's going on here?
[1]: https://forum.syncthing.net/t/discontinuing-syncthing-androi...
They're Java-only APIs and since Syncthings core isn't written in Java, the author would have to write JNI glue to call Android when writing/reading files (and honestly this would be quite tedious, because the way SAF works is to assign Uris to each file and you need to keep querying it to get folder structure since you can't just concat paths like with files).
The author didn't want to do that and tried to persuade Google to continue letting them access all files, all photos and all documents directly and Google said no. That was the "difficulty" - turns out it's really hard to publish on Play if you refuse to follow the guidelines. Just like on AppStore.
But that's really hard to do if you didn't begin with cross platform architecture that doesn't take into account having to modularize the filesystem layer for Android/iOS :/
I think it's because he doesn't have a time machine and doesn't have time to donate to rewrite someone else's project that the owner expressly doesn't want rewritten.
n.b. it wasn't arbitrary
This is what we call "Put up or shut up". It's easy to bash someone for not wanting to spend many hours of their time to work they have no interest in, just because some third party is now demanding it. The change is absolutely arbitrary, also. There used to be no way to grant apps access to specific folders. This is when the app was written. This still works. Google's own apps work that way. But now Google has also implemented additional ways to access the filesystem, and they are demanding people who don't even work for them to rewrite their projects.
It would be understandable if they demanded new apps to adhere to these new policies. But blocking older apps, that were written when there literally wasn't an alternative available, to do a full rewrite or be banned from updating? Absurd.
If you are now claiming your question was rhetorical, it doesn't mean that when answered, it is snark.
> It's easy to bash someone
No one's being bashed. Lets put it in stark relief. Here's the bashing you replied to: "But that's really hard to do if you didn't begin with cross platform architecture that doesn't take into account having to modularize the filesystem layer for Android/iOS :/"
> The change is absolutely arbitrary
No, it isn't.
We can tell you know that, because you immediately say "There used to be no way to grant apps access to specific folders."
> But now
"Now" == "3 years ago"
> demanding people who don't even work for them to rewrite their projects
They're not demanding anything, other than Google demanding Google can't keep taking updates to an app they put on their store, with full filesystem access, 3 years later, unless they patch the filesystem access. As other comments note, there's plenty of storefronts for these situations.
n.b. it's dangerous to take updates with unpatched security flaws, because bad actors buy apps/browser extensions. This is roughly the minimal action Google needs to take to avoid being liable - it's been 3 years, it looks like complicity to claim its store is safe and secure, then repeatedly take updates to products on the store with known security vulnerabilities, for years.
> But blocking older apps, that were written when there literally wasn't an alternative available, to do a full rewrite or be banned from updating
Though interpretative charity, I'm guessing you mean Google won't put updates from the vendor on the store, unless the update includes stopping asking for full filesystem access with 0 alternatives.
> to do a full rewrite
No ones demanding this