←back to thread

397 points opengears | 1 comments | | HN request time: 0.001s | source
Show context
_fat_santa ◴[] 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 ◴[] 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 #
ihuman ◴[] No.41898485[source]
> 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

Syncthing-android is already written in Java, so shouldn't there already be JNI glue code? https://github.com/syncthing/syncthing-android

replies(2): >>41901420 #>>41903646 #
1. carstenhag ◴[] No.41901420{3}[source]
It's an app that ships with/downloads the synching (go-based) binary. (I am pretty sure this is still the case, I looked at it some years ago)