Comment by _fat_santa
7 months ago
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...
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.
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.
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.
5 replies →
Yeah, Android has an immense churn of very low quality APIs with spotty support outside JVM languages and worse documentation.
Combine that with the fact that Android users are magnitudes less willing to fund apps (either by buying them or donating), and the result is an abysmal ecosystem that does not reward continued participation in it.
To be fair, it's really messy to do Go on Android calling back into Java because of how its runtime works. I'm not surprised they don't want to do it if it's a hobby project and it'd require making substantial changes to Syncthing's core logic.
It is - the way I always structured our architecture in this case was to write as much as possible of file handling in Java side and keep JNI surface minimal (it's also better for performance).
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 :/
5 replies →
Many folks keep thinking that just because Android uses the Linux kernel, it is supposed to behave like GNU/Linux.
Likewise they will be rather surprised to insist in targeting iOS/iPadOS/watchOS as if they are UNIX clones.
Android being linux has exactly nothing to do with the fact that apps can't access resources outside their sandbox if they aren't mapped in somehow. Just like with lxc or docker containers on linux, jails on *bsd, or any other sandboxes.
7 replies →
But it does behave like GNU/Linux where it matters, other than Google's arbitrary restrictions.
Wait, I seem to remember this discussion from years ago and thought it was resolved. Back then, Google wanted to drop the "access all files" permission from Android's permission system entirely but IIRC Syncthing & file manager devs then convinced them to keep it. But now Google comes back at them with a Google Play policy that prevents them from using that permission in practice?
You have to ask permission via a form from Google and your app must closely fit a white list of use cases (file manager, etc.) Obviously there's a high chance they just say "nah". Definitely sucks.
1 reply →
Yeah, but the legitimate use-case for that permission is VERY narrow - as in, if there's ANY way to implement your use-case using SAF, you MUST use SAF.
And SyncThing can be implemented using SAF - it's "just" a lot of work and that's usually not enough for Play Store to grant exception.
1 reply →
> 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
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)
The actual file monitoring, access nad upload is handled by syncthing cross-platform Go library wrapped with the Java app.
While I don't know about this developer's specific issues, I can comment on my own issues with Google Play as an Android developer. Google Play continues to become more and more stringent with app permissions and the approval of these permissions is very vague. With my own app, from one minor release the next, one day I'll receive approval for my app's permissions and the next week I will not even though only minor changes to the app have been made. When I reach out to Google Play support, the answers are always extremely vague, canned and repetitive and I never know if an update to my app will get approval or not. It's a horrible way to develop anything.
Sounds just like Apple’s stores!
The most annoying requirement is their Play Store delete account url. We have an API where we can delete the user’s account. But no, Google wanted a stupid url.
Is that so that users who no longer have/want to use the app can still delete their account?
1 reply →
How do users use the API?
Is it really that hard to set up a small proxy tool that calls your fancy api when it receives those requests? As an outsider, it does seem quite reasonable to me - Google couldn't possibly support all APIs there may possibly exist for every app there is.
14 replies →
Yeah now it's just like developing for Apple. Have been suffering from Apple's vague and canned responses for years.
I've done a few apps as part of my day job. And my best explanation and/or analogy is government regulations. The store requirements, apis and rules are documented up to the upteenth degree in 49 pages spread across many areas, and unless you're "in the know", you have no way to implement it to a reliable degree. And then all this ends up doing is punishing small / low-budget / low-time developers, leading to consolidation around the big players.
The big players can push their weight around to some degree, they get an element of built-in trust, and they have the sheer budget/time to implement all the ridiculous and sometimes onerous requirements. All in all, they're cementing their market position and trying to make "sticky" and invested players that will prop-up the play store for the coming decades.
Regulatory capture for fun and profit!
This is the best analogy I have yet read. It perfectly sums up my experience.