>>openge+(OP)
There is an Android Syncthing fork [1] which is active and 1.3K stars (for whatever that's worth).

[1] https://github.com/Catfriend1/syncthing-android

>>openge+(OP)
From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064

> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.

>>lopken+W6
The app is on F-Droid, which is mentioned in the article: https://f-droid.org/en/packages/com.nutomic.syncthingandroid...

I’m not sure why it can’t continue to be. Does anyone know why?

>>openge+(OP)
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...

>>openge+(OP)
What the heck, I literally come from upvoting another submission's comment about combining LocalSend with Syncthing [1], because the idea seemed great...

That's gone very fast from "oh yeah!" to "oh no!"

[1]: >>41891983

>>lopken+W6
they do, but google play is the main distribution channel for android apps, and without that many people will not use it (and many will complain). from the actual announcement:

> without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance

https://forum.syncthing.net/t/discontinuing-syncthing-androi...

>>openge+(OP)
Joining the IA Writer club on Android: >>41658023

>>xnx+f8
I'm using Syncthing to sync documents between devices and I own a mac fleet and an iPhone. The Möbius Sync[1] client (no affiliation) works great for me.

[1] https://mobiussync.com/

>>openge+(OP)
Url changed from https://old.reddit.com/r/Syncthing/comments/1g7zpvm/syncthin..., which points to this.

Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html

>>bmicra+fo
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

>>kstrau+NA
> We both know that first bit is a strawman, so we can move past it.

Privacy and security are literally the reasons for these APIs. I don't see how you could possibly call that a strawman.

> I would have assumed there was a middle ground like asking for permission to a specific folder's contents,

Isn't that what OPEN_DOCUMENT_TREE does? https://developer.android.com/reference/android/content/Inte...

>>treve+Aw
syncthing-fork has been working noticeably better for me for a couple years now: https://f-droid.org/en/packages/com.github.catfriend1.syncth...

>>growse+ng
> Seems like a perfect fit for SAF.

Except SAF is slow as hell, working on multiple files means separate calls for every little thing like file size via java API. Means everything going to be VERY slow and drain battery a lot. I've seen test from 2019 where directory listing operation is 25-50 times slower in SAF

https://issuetracker.google.com/issues/130261278

>>izacus+Rb
> 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

>>openge+(OP)
I used to develop Android professionally (at Dropbox in the 2010s, so I have some familiarity with older Android filesystem APIs) and made a very conscious decision to switch to devx and backend work and get out of Android (as did most of my former Android colleagues). The unending hoops you had to jump through and API changes to keep your app working were too much of a pain.

As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...

Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.

All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.

[0] Bug 18512473 fixed in https://android.googlesource.com/platform/frameworks/base/+/...

[1] Proof of concept video: https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0

>>meowst+ti
I have heard good things about git-annex [0]

But don't expect the same polished user experience as with SyncThings

- [0] https://git-annex.branchable.com/Android/

>>kstrau+WO
> . It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.

iA -- one of the cases you mention -- balked at needing a standardized security assessment to access the full Google Drive.

> In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit.

https://ia.net/topics/our-android-app-is-frozen-in-carbonite

Googe Drive as part of Workspace is HIPAA compliant (https://support.google.com/a/answer/3407054?hl=en), meaning medical offices can and do host medical records on Drive. It's not mentioned in the article why iA needs access to all files on a HIPAA compliant service.

Workspace is also (at least partially) FedRAMP compliant (https://support.google.com/a/answer/13190816?hl=en). So similar questions arise as to whether iA needs to access federal data.

>>trav42+5I
> I wish there were an alternative (a practical pocket computer), but there really isn't.

There really is: https://puri.sm/products/librem-5.

And it's my daily driver.

>>izacus+vb
SAF is a slow, buggy mess, and it only works in Java/Kotlin, so it's understandable that they don't want to use it. GrapheneOS manages to allow native access (via Java or machine code) to only specific user-selected directories through its Storage Scopes feature [1]. They basically did SAF but correctly and without the funding of a megacorp.

[1] https://grapheneos.org/features#storage-scopes

>>pjmlp+zz
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

>>beeboo+Wq
Yes, we've rate limited your account because it posts comments that obviously break the site guidelines, such as >>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.

>>trav42+5I
I use Sailfish OS as my daily driver since 2013.

https://en.m.wikipedia.org/wiki/Sailfish_OS

>>NotPra+051
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.

>>hparad+OB
Sadly there is no real alternative to Android at the moment. Replicant are also just 2-3 developers afaik. https://replicant.us/

>>openge+(OP)
For everyone using Android and fearing not to be able to use Syncthing anymore: fear not. This is only affecting the Google Play Store version of Syncthing. You can get Syncthing-Fork here on F-Droid http://f-droid.org/packages/com.github.catfriend1.syncthinga...

>>fny+7D
Correct. A big part of the issue here is that Syncthing's Android app is more of a wrapper over the desktop app than an actual native Android implementation, so a lot of the code assumes the availability of certain features (like full filesystem access, and the ability to run continuously in the background[1]) that are suboptimal to have on a modern mobile OS.

Android has been pushing to restrict the usage of such features for a while. It sounds like now they finally pushed hard enough that Syncthing broke.

As a longtime Syncthing user I'm personally fine with this. I think its fair for Google to demand a certain minimum bar of polish for apps on the Play Store. I'll continue to use Syncthing on F-Droid so long as its feature set continues to make it superior to those more polished alternatives. Hopefully the absence of Syncthing on the Play Store will create an opportunity for another file syncing app to fill that void, or incentivize contributors to eventually bring Syncthing up to snuff to get back on the Play Store. (Or possibly, incentivize Google to develop tools to make it easier for low-budget apps like Syncthing to meet their quality standards.)

[1]: https://github.com/syncthing/syncthing-android/issues/1048#i...

>>dang+8X5
Amplifying on dang's comment: from my own experience moderating, many people respond in a strongly negative fashion to moderation, up to and including prolonged attacks on the site itself and threats to moderators. Effective moderation on large sites is a careful balance between transparency and pragmatism, to the extent that even well-intentioned initiatives such as the Santa Clara Principles (<https://santaclaraprinciples.org/>) may not be practical.

Something I note having been caught up on both sides of this issue: as moderator and moderated.

HN itself is not one of the super-sites, but it is amongst the better discussion platforms on the internet here and now (boys), and has been for far longer than virtually any other instance I can think of (dating to 2007). Metafilter would be the principle other exemplar.

Usenet, Slashdot, Kuro5hin, Google+, Reddit, Ello, Diaspora*, Imzy, FB, Birdsite, and others, would be amongst the failures IMO. Not all are now defunct (though about half that list are), none remain usable.