←back to thread

Syncthing Android App Discontinued

(forum.syncthing.net)
397 points opengears | 4 comments | 20 Oct 24 14:51 UTC | HN request time: 0s | source
Show context
_fat_santa ◴[20 Oct 24 15:55 UTC] No.41896183[source]▶
Looking at the underlying thread[1], the author mentions that it's very hard to publish on Google Play

> 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...

replies(3): >>41896256 #>>41896453 #>>41896704 #
izacus ◴[20 Oct 24 16:25 UTC] No.41896453[source]▶
In this case the author doesn't want to use Storage Access Framework APIs to access the file system which were mandated a few years ago as the way to access data outside the app sandbox.

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.

replies(5): >>41896541 #>>41896556 #>>41897277 #>>41897403 #>>41898485 #
fph ◴[20 Oct 24 18:24 UTC] No.41897403[source]▶
To be fair, you're making the most used mobile operating system in the world and can't be bothered to make API bindings for more than one language? Or at least make the process easy so that someone else creates them? I am not an Android developer, but that seems also part of the problem.
replies(3): >>41897794 #>>41897923 #>>41903591 #
pjmlp ◴[20 Oct 24 19:38 UTC] No.41897923[source]▶
Android has two official languages for userspace Java and Kotlin.

NDK is only for writing native methods, reuse C and C++ libraries, and better performance for 3D and real time audio.

Anything else, is not officially supported by the Android team.

replies(2): >>41899835 #>>41899872 #
1. NotPractical ◴[21 Oct 24 01:17 UTC] No.41899872[source]▶
fopen(), fwrite(), etc. are a part of libc and as such are officially supported [1], but they become somewhat useless with SAF. (It makes sense that you'd at least have to use some Java to open a file picker and request access, but why not provide native access as well when a file is picked?)

[1] https://developer.android.com/ndk/guides/stable_apis

replies(2): >>41901322 #>>41903600 #
2. pjmlp ◴[21 Oct 24 06:43 UTC] No.41901322[source]▶
And they can be used the same as java.io.File, inside the application sandbox.

Other than that, it boils down to:

" - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries. "

From https://developer.android.com/ndk/guides

And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files.

replies(1): >>41910523 #
3. izacus ◴[21 Oct 24 12:48 UTC] No.41903600[source]▶
Yeah, I personally think Scoped Storage on Android was a bit misdesigned and it would probably be much easier for all app developers if they (ab)used FUSE to present allowlisted directories inside app-specific mounts.
4. NotPractical ◴[22 Oct 24 02:14 UTC] No.41910523[source]▶
Those are vague examples of what the NDK could be used for, not an exhaustive list of all supported use cases. And Syncthing is really just trying to re-use their existing code on Android (example use case #2). It doesn't even require low-level syscalls, it just needs to be able to call fopen() on files which the user has explicitly granted to the app, which you'd expect would be available within the application sandbox.

> And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files

You might as well just axe the entire NDK if you're worried about unsafe code.