Syncthing Android App Discontinued

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

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.

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.

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.

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 :/

Is that so that users who no longer have/want to use the app can still delete their account?

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.

How do users use the API?

This is the best analogy I have yet read. It perfectly sums up my experience.

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.

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.

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?

The only Linux thing on Android is the kernel, use anything else at your peril regarding portability between updates and OEM custom forks.

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

Since you have such strong opinions on the matter, and experience, why don't you contribute to the SyncThing android app and implement this? Alternatively you could grab your time machine, travel back several years and let them know to anticipate this arbitrary change google would pull in the future.

The point is you can't use the regular filesystem syscalls on android, it has to go through a weird java layer

how are you going to authenticate the user? now you need to solve that if you didn't have a web login before.

---

Guess @dang decided to rate limit my account again so I can't post replies :-)

> Some token that every account gets generated? It's really not that much to ask honestly.

How is the user going to know this token when they visit the website on their laptop? Keep in mind that the Google requirement is that you link to this delete page from the play store, where the user is not authenticated with your app. You can't just generate an URL containing this token.

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.

> (aggro question)

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

> (snarky response)

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.

The only linux thing is always the kernel. Userspace isn't linux by definition on any* system. That might seem like a pedantic point to make, but I would like to point out that gnu utils aren't required to make a system "Linux", and whether you're using a drop-in replacement like uutils or go a more different route doesn't make it any less "Linux".

Android Apps are and mostly always have been restricted to the Java virtual machine (or its modern equivalent) exactly because that makes them portable between sometimes quite different base systems from different vendors. If you insist that makes it less of a Linux system I'd like to know what you think of flatpak apps on top of immutable distros. I hope you agree that, conceptually, they're quite close actually.

Some token that every account gets generated? It's really not that much to ask honestly.

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.

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.

It certainly makes it less Linux, as most people mean Linux kernel plus GNU userspace with glibc, or possibly muslc as alternative to glibc.

Nothing of that is expected to be supported on NDK, at least officially, Google and partners have the freedom to break those expectations as much as they feel like it.

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.

> (snarky response)

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

But it does behave like GNU/Linux where it matters, other than Google's arbitrary restrictions.

Regulatory capture for fun and profit!

> Guess @dang decided to rate limit my account again so I can't post replies :-)

There are automatic rate limits that apply to everyone. IME you can still click on the comment's timestamp to be able to 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

And perhaps more to the point - you USED to be able to use normal Java file apis and syscalls outside of Java, but that functionality has been gradually whittled away (in the name of legitimate security improvement) over the years, meaning "basic" IO functionality your apps relied upon could be taken away at any point and replaced by less ergonomic Java-only APIs with less functionality.

Fun fact: the official Dropbox Android app used to use inotify to watch for changes to the publicly writeable synced files in order to sync back to the cloud! Had to be replaced by java Storage Access Framework APIs later.

Another fun fact is that the Android sdk came with a JNI wrapper around inotify but it buggily stored inotify handles in a static (global, within an app vm) dictionary, meaning you'd silently lose tracking if you created more than one Java file watcher object that happened to be for the same path, so I had to rewrite that JNI wrapper back in the day to avoid that global state bug.

If you post something the moderators don't like, your account can be manually rate limited to a max of 5 comments per X (24?) hours.

Source? What does this look like?

After you've written your comment and when you click reply you get the message:

> You're posting too fast. Please slow down. Thanks.

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

I'd just like to interject for a moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!

It probably doesn't help that Syncthing is a direct competitor to Google Drive.

Yes we have a delete account option in our settings screen. But Google asking for url webpage for this scenario is just unnecessary.

Apple accepted it with no questions.

We can’t tell for sure since this url will be added to the Play Store. Problem is how to authenticate users.

That sounds like the automatic limit. Maybe there's a manual one as well with the same message though.

Yes, we've rate limited your account because it posts comments that obviously break the site guidelines, such as https://news.ycombinator.com/item?id=41880814.

Could you please review https://news.ycombinator.com/newsguidelines.html and use the site as intended instead? I don't want to ban you but it's not cool when people keep posting like that.

Btw, if you (or anyone) don't want to be rate limited on HN, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.

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.

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)

Yeah now it's just like developing for Apple. Have been suffering from Apple's vague and canned responses for years.

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.

I professionally contribute (and have contributed) to many projects to make them compatible with Play Store policies (that's my job after all), but I have limited time and generally the attitude of SyncThing developer kinda annoys me since it's an attitude of that developer in your PR that will spend weeks of time arguing over code implementation instead of fixing the comments in a day.

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.

The actual file monitoring, access nad upload is handled by syncthing cross-platform Go library wrapped with the Java app.

The triggering of the limit is automatic, but being subjected to the limit is something the moderators can turn on per account.

If I make a new account it'll be free of the limit until dang gets upset again.

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.