> 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.
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
There's going to be loud, destructive friction when a 10-15 year old platform reduces the functionality available to its apps. Security models do need to evolve, but Android was introduced as a platform suitable for deep personal customization with few mandatory boundaries.
This was a competitive distinction against Apple's closed "safety first" platform design in iOS and led to an ecosystem of applications that took advantage of all these extra possibilities. As Google tightens its grip over the platform and pursues more aggressive limitations for security reasons (and whatever other ones), it's inevitable that many publishers and users are going to be deeply frustrated when the features that made their device theirs are no longer available.
(And incidentally, the restrictions on the Apple side have nothing to do with the application development language. I don't know where you would get that idea from or how to even make sense of it. It's just the nature of Apple's original design philosophy for iOS, where apps were deeply isolated and had no more capabilities than were necessary. Largely, Apple has been gradually adding capabilities to heavily-restricted apps over the lifetime of iOS, while Google has been moving in the opposite direction because they each started from opposite ends of the design space.)
Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
Apple's position is different, because Apple never let you have this kind of access.
Android/Google Play review keep restricting APIs and replacing them with less capable APIs, or keeping the APIs and reducing functionality.
It works again, but I had a USB endoscope that stopped working because Google pulled APIs and took a while to replace them. I can't use location sharing in my choice of apps anymore because something on my phone blocks either app runtime, app internet access, app location, or gps decoding and I don't use it often enough to be motivated to delve through logcat to figure it out, if they even still let me use logcat?. I'm sure it helps my battery life, but it reduces the functionality of the phone.
On that note. what is with this modern trend of trying to pretend the filesystem does not exist.
why does google(or apple) need "special interfaces" to access the filesystem in a specific way, why don't they just use the existing file api and improve the file access permission system.
I think the unix single tree filesystem was one of their great innovations and see this multi tree api fragmentation bullshit as a sort of backwards regression.
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.
I think burn out on free projects is a real thing. Heck I get burn out on old projects and I’m being -paid- to maintain them. Good will and accolades only go so far and passion runs out eventually, especially if you’re only one person and there’s no one there to give you respite for a good recharge and you’re facing a hostile entity like Google.
it's how the cross platform software works and has always worked. demanding a total rewrite just to publish on a single channel is insane, especially since this used to be the ONLY way to do things.
google could always contribute to the open source app to implement the features they wish to see, but instead of using their billions for good they'd rather use it for evil.
I would have to disagree, so far the new file API has been the most buggy experience for many apps that have to use files every time that the app is running or is in background, and this is from a user experience perspective alone.
I can understand why the developers can't be bothered with a badly thought out new system.
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.
It sucks that the ongoing maintenance cost for the native mobile platforms is so high. Who wants to develop on top of a platform that is constantly changing out from under you?
It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).
But that's Scott's point. If the OS devs had thought through this from the beginning, app devs wouldn't have to keep dealing with breakage. iOS devs have other issues, but not these.
Apple and Google approached the mobile OS from opposite sides. Apple locked everything down and has gradually been adding access/features. Google left the barn door open, and is now trying to shut it. I know which OS/API I'd rather program against.
"Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app."
I've been using that one for a long time now. I recall that when I got started with Syncthing (some months to a year or two ago?), it seemed to have been the folk wisdom to use Syncthing-Fork, but I don't recall what the reason was.
Seems to work. Exported the config of the other one and imported it in this one. Seems all the settings are there. Sync seems to work too. Kudos to the devs.
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.
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.
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?
> 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
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.
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.
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.
The KeePass2Android app gains a bit of functionality if you use it with SFTP instead. You get the ability to, for example, merge changes in the event that there's a conflict. I recommend using SFTP to a machine that then runs SyncThing to the rest of your devices.
I would think that a user competent to use and want sync thing, is perfectly capable of depending on f droid as a source for the apk.
Can that not be enough of a distribution channel.
Well, I'll be putting the APK in a safe place, along with my Turbo Pascal floppies. ;-) Syncthing for Android has been vital to managing my sheet music collection.
Sharing files? Probably. Reliably syncing files without interaction, and especially without requiring a central server? i don't think so.
The truth is, the android app has existed for over 10 years now and it has never been good. It kinda mostly worked for some use cases, but always-on continuous sync on battery wasn't really one of them. And that's been true even before Google justifiably started restricting filesystem access in KitKat(!) 11 years ago.
If you are looking for an Android app that does syncing in the background well, I can highly recommend FolderSync.
That's a bummer! Can anyone suggest an alternative way I can get files from my macOS laptop to my Android phone? I "just" want to put my folder of music files and m3us there so I can play them (with PowerAmp).
Localsend is a great program - but no alternative to syncthing. Syntcthing is running in the background and syncing automatically. Localsend needs active user interaction. Is there a way how to use localsend similarily to Syncthing?
I've been considering making a new Android app for a while. A simple one to interact with a couple of my web services with some on-device storage, nothing complicated. More than anything, the thing that's stopping me is that I _know_ if I make it, a few Android versions later, it either won't work or won't be allowed on Play. I can't predict what random piece of the Android API/policy will change, but I know something will. And I'll have to waste my time fixing something that worked fine until Google arbitrarily broke it.
I built one app before for JellyBean. I haven't been able to install it for years and I can't compile it for a new version because of a cascade of errors and required changes that I'm unwilling to do. JellyBean hadn't even reached 10 years old before my app broke, it's pathetic that app support crumbled and rotted away that quickly. It'll happen again, so I've been turned off of Android development.
I totally understand the discontentment. It makes you feel powerless.
Pretty valid criticism. But as an android dev, it's quite normal. We got used to it.
Build your app in the recommended way, don't do weird stuff, read the guidelines. Accept drawbacks. That's more or less what you have to do, then the Play Store/App Store will be happy.
Build tools are mostly good with 1-2y old code, after that, yeah be ready to upgrade a lot.
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...
The catfriend fork works great (I use it) but to be clear, this post is about the official version. The official version will cease all development, it's not just limited to the Play Store.
If the Catfriend fork goes, I'll have no use for Syncthing at all, and it will be a very sad day in open source. I'll probably move to some proprietary app, since I'm definitely not interested in self hosting anything, and there's not really any FOSS equivalents other than Syncthing itself.
Android really needs to just allow direct file access to any file which is under a user selected folder.
This is very likely the reason that your fork no longer wishes to be on the Play Store:
> Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app.
>> Android really needs to just allow direct file access to any file which is under a user selected folder.
> It does.
I don't think it does for anything under Android/data/ directory though does it? Which might sound like nitpicking except that there are some apps which only store their data under Android/data with no option to put it elsewhere, which means that there is no way for syncthing to access that data.
People that aren't familiar with Android's proprietary labyrinth of a filesystem API, you mean? If you had provided evidence that it does instead of just saying so in your first revision, you probably wouldn't have been downvoted.
This is one of the few reasons I was still on Android over iOS. If Android becomes just as bad as iOS why would I keep putting up with Android?
It's exhausting dealing with operating systems that treat you like a child. If that's the choice I may as well not even have a "smart" phone. There's nothing smart about it anymore. It's become a toy with a camera.
This is disappointing. SyncThing is one of my reasons for picking Android over iPhone. I hope the author reconsidered. Would any GoFundMe-style donation goal make the hassle worthwhile?
When I migrated from Android to iPhone, syncthing was my main pain point. There is Möbius Sync, even though not open source, at least it’s an one-time small payment, which is fair considering the dev license cost. Unfortunately it’s not as reliable as the Android official app or the fork, I guess Apple is very strict with background processing, but hey it’s better than nothing.
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.
I'm in the same boats, I have an app on play store but that dev verification thing will cost me around 90 euros where its not making me money even though its commercially driven still, I just can't be bothered to spend extra money for Google for their company verification requirements
(ps: I tried to get support about it and was willing to provide the company info just to keep getting on the platform, but the only answers that I got were "you must use this (non free) system to have your company verified" and then I tacitly said "screw this")
The Google Play Store is a massive pain in the ass lately. For whatever reason Google wants me to continuously update my Android apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
The Apple App Store is a massive pain in the ass lately. For whatever reason Apple wants me to continuously update my iOS apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
I'm a big fan of Syncthing, and use it on Android as well as pc. But it seems they are relying MANAGE_EXTERNAL_STORAGE permission and I can't see a good reason for Google to go on permitting that in 2024. It gives an app too much power.
Android has had scoped storage for a decade now. Time to get with the program and start using the SAF.
It does feel very odd to be actually agreeing with the Goog on something...
When bad actors keep misusing and messing up user's folders & data, it was deemed necessary. I know I know, on desktop machines this is different. But they also suffer from hundreds of thousands of malware, ransomware, etc.
> An app that's supposed to sync your files having access to your files is "too much power" now?
An app that syncs your files just needs access to those file, not the entire filesystem - which is what MANAGE_EXTERNAL_STORAGE gives it. Scoped storage and the SAF would allow syncthing to do exactly what it needs to do. The problem is that the app maintainer is unwilling to do the work to bring this app into the modern era.
> It's hard to fathom just how much damage smartphones have done to personal computing, but statements like these are a grim reminder.
Grim? Really? Personal devices containing highly personal information, coupled to a virtually friction-free global app marketplace, need on-device and supply-chain protections. As an Android dev I can find plenty to be critical of when it comes to Google's api designs and app review criteria. But in this case I agree with them.
I tried Termux and found the application files I wanted to rsync aren't visible in Termux, except maybe by rooting the phone. But I need to use banking and auth apps daily on it, so I assume that isn't an option.
that would require you to set up a domain name and use DDNS and trust your registrar, or to just always have your computers at a static IP with no NAT blocking you whatsoever.
I am developing and supporting game engines for over a dozen years. It works pretty much on any device which can run games.
Supporting it for Android is the worst experience ever. This is by far the least reliable OS in terms of compatibility or changes they make. It gets more convoluted and crapier with every exec bonus and 'feature' google invents.
Thank you google for killing yet another great app. There should be special category for apps that are "Done, Complete, Perfect as is", as with decent backwards compatibility on Android there should be no issues with them. I bet apk compiled for Android 1 still runs perfectly on Android 15.
Depends on the exact functionality. I'm aware of some battery events you could listen to from the manifest file in 2, that were removed at some point after that and now you have to listen for them from a running service. It broke a bunch of battery monitoring apps when it happened.
Also with services, there's additional requirements to keep them running that weren't there early on.
Android is one of the few platforms on earth where anything interesting actually could be done and finished, since they have actual stable API levels unlike Linux.... And they don't allow it
The problem, as most of the time, are bad actors. Which is the reason some permissions, SAF, disallowing targeting lower SDK versions etc were introduced on the Play Store.
What the heck, I literally come from upvoting another submission's comment about combining LocalSend with Syncthing [1], because the idea seemed great...
Once again, Im also in the niche of avoiding pay-for dozens of small services and just getting my simple stuff synced. Bam, another blowback. Im eager to ready what alternatives HN crowd might come up with....
...Does the author not understand that the Google Play Store is not the only distribution mechanism for apps? Why not just continue to distribute APKs for users to install manually?
I suspect it could be, however it sounds like the author has lost all motivation to continue work on syncthing android and has formally announced that no further development will be done. And as much as I like syncthing-android I appreciate this sort of straight forward communications more and salute the author for clearly stating intentions.
Now seeing as it is open source (hooray) The way I think that will go is as follows, we will continue using the existing apk(I get mine off f-droid) for a few months to years, in the meantime seeing as the app is so useful to so many a few forks will arise, one will end up being the best, and we will eventually start using that one.
Presumably because most people don't know about F-Droid, and there's a question of whether it's worth continuing to develop the app for a tiny subset of the original audience.
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
They do set how permissions on upgrades of Android work so even if it’s on f-droid, when they enforce the SAF protocols fsync will stop working if you keep your Android up to date
I used Syncthing for a while between various Linux distros, and I used Syncthing-Fork on my Android tablet, and it was okay when it worked, but it often borked up, and there were so many arcane settings and weird failure modes. I realized that the only reason I was using Syncthing was because it appealed to the vestigial, ultra-paranoid crypto-fascist BOFH in me, and I had grown out of those attitudes.
So today I just use Google Drive and MS OneDrive like a normal person. They work great. I love 'em. They don't fail like Syncthing. They're way more secure, and fully supported. Come join me! The water's fine!
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.
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
There's going to be loud, destructive friction when a 10-15 year old platform reduces the functionality available to its apps. Security models do need to evolve, but Android was introduced as a platform suitable for deep personal customization with few mandatory boundaries.
This was a competitive distinction against Apple's closed "safety first" platform design in iOS and led to an ecosystem of applications that took advantage of all these extra possibilities. As Google tightens its grip over the platform and pursues more aggressive limitations for security reasons (and whatever other ones), it's inevitable that many publishers and users are going to be deeply frustrated when the features that made their device theirs are no longer available.
(And incidentally, the restrictions on the Apple side have nothing to do with the application development language. I don't know where you would get that idea from or how to even make sense of it. It's just the nature of Apple's original design philosophy for iOS, where apps were deeply isolated and had no more capabilities than were necessary. Largely, Apple has been gradually adding capabilities to heavily-restricted apps over the lifetime of iOS, while Google has been moving in the opposite direction because they each started from opposite ends of the design space.)
16 replies →
Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
44 replies →
Apple's position is different, because Apple never let you have this kind of access.
Android/Google Play review keep restricting APIs and replacing them with less capable APIs, or keeping the APIs and reducing functionality.
It works again, but I had a USB endoscope that stopped working because Google pulled APIs and took a while to replace them. I can't use location sharing in my choice of apps anymore because something on my phone blocks either app runtime, app internet access, app location, or gps decoding and I don't use it often enough to be motivated to delve through logcat to figure it out, if they even still let me use logcat?. I'm sure it helps my battery life, but it reduces the functionality of the phone.
On that note. what is with this modern trend of trying to pretend the filesystem does not exist.
why does google(or apple) need "special interfaces" to access the filesystem in a specific way, why don't they just use the existing file api and improve the file access permission system.
I think the unix single tree filesystem was one of their great innovations and see this multi tree api fragmentation bullshit as a sort of backwards regression.
7 replies →
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
2 replies →
I think burn out on free projects is a real thing. Heck I get burn out on old projects and I’m being -paid- to maintain them. Good will and accolades only go so far and passion runs out eventually, especially if you’re only one person and there’s no one there to give you respite for a good recharge and you’re facing a hostile entity like Google.
it's how the cross platform software works and has always worked. demanding a total rewrite just to publish on a single channel is insane, especially since this used to be the ONLY way to do things.
google could always contribute to the open source app to implement the features they wish to see, but instead of using their billions for good they'd rather use it for evil.
I would have to disagree, so far the new file API has been the most buggy experience for many apps that have to use files every time that the app is running or is in background, and this is from a user experience perspective alone.
I can understand why the developers can't be bothered with a badly thought out new system.
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
It sucks that the ongoing maintenance cost for the native mobile platforms is so high. Who wants to develop on top of a platform that is constantly changing out from under you?
It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).
But that's Scott's point. If the OS devs had thought through this from the beginning, app devs wouldn't have to keep dealing with breakage. iOS devs have other issues, but not these.
Apple and Google approached the mobile OS from opposite sides. Apple locked everything down and has gradually been adding access/features. Google left the barn door open, and is now trying to shut it. I know which OS/API I'd rather program against.
2 replies →
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
Good to know, although the Readme says:
"Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app."
It's on f-droid rather than google play.
I think for the people interested in using Syncthing rather than Dropbox or Google's syncing option, that's not _that_ much of a problem.
5 replies →
I've been using that one for a long time now. I recall that when I got started with Syncthing (some months to a year or two ago?), it seemed to have been the folk wisdom to use Syncthing-Fork, but I don't recall what the reason was.
For me, I'm pretty sure it had something to do with better and more granular run conditions on folders.
Weirdly enough, I cannot find either on Play right now..even though I have it (the original, I believe) installed through Play.
> Head to the "releases" section or F-Droid for builds.
It's in the description on GitHub. Get F-Droid.
Seems to work. Exported the config of the other one and imported it in this one. Seems all the settings are there. Sync seems to work too. Kudos to the devs.
Yep, that's what I use. Very happy with it for years!
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.
8 replies →
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.
6 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.
9 replies →
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?
4 replies →
> 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
2 replies →
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.
18 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.
Eek. That's how I get my keepass database on my phone. Anyone else in this predicament?
The KeePass2Android app gains a bit of functionality if you use it with SFTP instead. You get the ability to, for example, merge changes in the event that there's a conflict. I recommend using SFTP to a machine that then runs SyncThing to the rest of your devices.
Re merges: that's very compelling. I've encountered that issue many times using Dropbox for syncing.
Painful! But appreciate the tip
syncthing-fork has been working noticeably better for me for a couple years now: https://f-droid.org/en/packages/com.github.catfriend1.syncth...
I need a serverless approach because my machines at home are off most of the time so that discounts SFTP. I also use syncthing-fork.
Resilio Sync is pretty good although proprietary
I think ultimately KeepassDX must integrate Syncthing functionality into itself
Keepass and Joplin.
Likewise
I would think that a user competent to use and want sync thing, is perfectly capable of depending on f droid as a source for the apk. Can that not be enough of a distribution channel.
I guess we will find out in the next couple of months as people either migrate to the F-Droid based "syncthing-fork" or move to a different sync tool.
I hate mobile computing so much.
This situation is so bad that I miss the Pocket PC Win32 developer experience
Well, I'll be putting the APK in a safe place, along with my Turbo Pascal floppies. ;-) Syncthing for Android has been vital to managing my sheet music collection.
Does anyone know how long I could expect the current Syncthing Android app to continue working?
Please read the article before commenting. It is clearly stated.
Is it? I see
> The last release on Github and F-Droid will happen with the December 2024 Syncthing version.
but not even a hint as to whether that APK is likely to work in say 2027.
1 reply →
Thank you for your work. I'm sorry to see you go. I really hope Syncthing continues to have a presence on Android.
That's just great. It's literally the only use case I had for it. There are tons of better ways to share files on PC.
Sharing files? Probably. Reliably syncing files without interaction, and especially without requiring a central server? i don't think so.
The truth is, the android app has existed for over 10 years now and it has never been good. It kinda mostly worked for some use cases, but always-on continuous sync on battery wasn't really one of them. And that's been true even before Google justifiably started restricting filesystem access in KitKat(!) 11 years ago.
If you are looking for an Android app that does syncing in the background well, I can highly recommend FolderSync.
FolderSync with which protocol?
The main reason I use Syncthing is not to use Dropbox for sensitive stuff, which I also use since it's on-demand mobile sync is way better.
2 replies →
Do give KDE connect a try. It's great
I did, before syncthing. It... isn't great.
4 replies →
That's a bummer! Can anyone suggest an alternative way I can get files from my macOS laptop to my Android phone? I "just" want to put my folder of music files and m3us there so I can play them (with PowerAmp).
Syncthing-fork from f droid
Localsend
Localsend is a great program - but no alternative to syncthing. Syntcthing is running in the background and syncing automatically. Localsend needs active user interaction. Is there a way how to use localsend similarily to Syncthing?
1 reply →
This is one the reasons I root my phone and just run an ssh server on it, I can rsync anything anywhere, and do full efficient filesystem backups.
If you don't have root, it's not your phone.
I've been considering making a new Android app for a while. A simple one to interact with a couple of my web services with some on-device storage, nothing complicated. More than anything, the thing that's stopping me is that I _know_ if I make it, a few Android versions later, it either won't work or won't be allowed on Play. I can't predict what random piece of the Android API/policy will change, but I know something will. And I'll have to waste my time fixing something that worked fine until Google arbitrarily broke it.
I built one app before for JellyBean. I haven't been able to install it for years and I can't compile it for a new version because of a cascade of errors and required changes that I'm unwilling to do. JellyBean hadn't even reached 10 years old before my app broke, it's pathetic that app support crumbled and rotted away that quickly. It'll happen again, so I've been turned off of Android development.
I totally understand the discontentment. It makes you feel powerless.
Pretty valid criticism. But as an android dev, it's quite normal. We got used to it.
Build your app in the recommended way, don't do weird stuff, read the guidelines. Accept drawbacks. That's more or less what you have to do, then the Play Store/App Store will be happy.
Build tools are mostly good with 1-2y old code, after that, yeah be ready to upgrade a lot.
>Build tools are mostly good with 1-2y old code
This perfectly encapsulates the modern tech enshittification treadmill that I loathe.
Redesigning the wheel every 2 years because some braindead MBA dreamed up another way to arbitrarily ruin things that work.
I hope it can live on inside F-Droid somehow.
It can be hosted in any app store, but because it doesn't use the correct APIs - according to Google - it will not work on newer Android devices.
AFAIK, it's fine on later devices, but Google Play specifically restricts the permission which they need (`MANAGE_EXTERNAL_STORAGE`)
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...
The catfriend fork works great (I use it) but to be clear, this post is about the official version. The official version will cease all development, it's not just limited to the Play Store.
Exactly, thanks for the clarification!
I don't understand. Author of the linked forum thread states that he discontinues both Google Play AND F-droid verion
The catfriend fork is not by the original author!
If the Catfriend fork goes, I'll have no use for Syncthing at all, and it will be a very sad day in open source. I'll probably move to some proprietary app, since I'm definitely not interested in self hosting anything, and there's not really any FOSS equivalents other than Syncthing itself.
Android really needs to just allow direct file access to any file which is under a user selected folder.
[flagged]
>> Android really needs to just allow direct file access to any file which is under a user selected folder.
> It does.
No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
From their docs:
> It offers a simplified view of a tree of documents, but it has substantial overhead
https://developer.android.com/reference/androidx/documentfil...
----
Your fork uses `MANAGE_EXTERNAL_STORAGE` which Google Play heavily restricts:
https://github.com/Catfriend1/syncthing-android/blob/main/ap...
This is very likely the reason that your fork no longer wishes to be on the Play Store:
> Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app.
https://github.com/Catfriend1/syncthing-android?tab=readme-o...
EDIT: The dangerous permission for `MANAGE_EXTERNAL_STORAGE` doesn't appear in the "App Info", which may be what you're seeing.
2 replies →
>> Android really needs to just allow direct file access to any file which is under a user selected folder.
> It does.
I don't think it does for anything under Android/data/ directory though does it? Which might sound like nitpicking except that there are some apps which only store their data under Android/data with no option to put it elsewhere, which means that there is no way for syncthing to access that data.
> Take the downvote button away from imbeciles
People that aren't familiar with Android's proprietary labyrinth of a filesystem API, you mean? If you had provided evidence that it does instead of just saying so in your first revision, you probably wouldn't have been downvoted.
Google is in self-destruct model
It is self-destruct only if you have competition. They don't, so it's just destruct.
This is one of the few reasons I was still on Android over iOS. If Android becomes just as bad as iOS why would I keep putting up with Android?
It's exhausting dealing with operating systems that treat you like a child. If that's the choice I may as well not even have a "smart" phone. There's nothing smart about it anymore. It's become a toy with a camera.
1 reply →
Is Google treating Dropbox the same way? Sounds like it could be anticompetitive behaviour.
No, because Dropbox actually follows the API guidelines.
How about DropSync (which I find much more useful than the official app)?
2 replies →
This is disappointing. SyncThing is one of my reasons for picking Android over iPhone. I hope the author reconsidered. Would any GoFundMe-style donation goal make the hassle worthwhile?
When I migrated from Android to iPhone, syncthing was my main pain point. There is Möbius Sync, even though not open source, at least it’s an one-time small payment, which is fair considering the dev license cost. Unfortunately it’s not as reliable as the Android official app or the fork, I guess Apple is very strict with background processing, but hey it’s better than nothing.
Just discovered the synctrain iOS beta which is extremely promising.
2 replies →
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/
It works, and well, considering the constraints in iOS, but doesn't compare well with Androids version. Regular sync thing on Mac is awesome.
One of the top comments has a link to a fork in case you haven't seen it
I'm in the same boats, I have an app on play store but that dev verification thing will cost me around 90 euros where its not making me money even though its commercially driven still, I just can't be bothered to spend extra money for Google for their company verification requirements
(ps: I tried to get support about it and was willing to provide the company info just to keep getting on the platform, but the only answers that I got were "you must use this (non free) system to have your company verified" and then I tacitly said "screw this")
The Google Play Store is a massive pain in the ass lately. For whatever reason Google wants me to continuously update my Android apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
The Apple App Store is a massive pain in the ass lately. For whatever reason Apple wants me to continuously update my iOS apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
I wonder how many people using Syncthing actually obtained it from the Play Store and not F-Droid? The whole point of it is decentralization, right?
I don't mind centralized, as long as it's centralized to my own server.
I'm a big fan of Syncthing, and use it on Android as well as pc. But it seems they are relying MANAGE_EXTERNAL_STORAGE permission and I can't see a good reason for Google to go on permitting that in 2024. It gives an app too much power.
Android has had scoped storage for a decade now. Time to get with the program and start using the SAF.
It does feel very odd to be actually agreeing with the Goog on something...
An app that's supposed to sync your files having access to your files is "too much power" now?
It's hard to fathom just how much damage smartphones have done to personal computing, but statements like these are a grim reminder.
When bad actors keep misusing and messing up user's folders & data, it was deemed necessary. I know I know, on desktop machines this is different. But they also suffer from hundreds of thousands of malware, ransomware, etc.
> An app that's supposed to sync your files having access to your files is "too much power" now?
An app that syncs your files just needs access to those file, not the entire filesystem - which is what MANAGE_EXTERNAL_STORAGE gives it. Scoped storage and the SAF would allow syncthing to do exactly what it needs to do. The problem is that the app maintainer is unwilling to do the work to bring this app into the modern era.
> It's hard to fathom just how much damage smartphones have done to personal computing, but statements like these are a grim reminder.
Grim? Really? Personal devices containing highly personal information, coupled to a virtually friction-free global app marketplace, need on-device and supply-chain protections. As an Android dev I can find plenty to be critical of when it comes to Google's api designs and app review criteria. But in this case I agree with them.
2 replies →
Does anyone have any other opensource recommendations?
There's a fork called, rather creatively, Syncthing-Fork. It's available on F-Droid.
This one is way more battery conscious as well. Works great, I prefer it.
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/
rsync or rclone on termux
I tried Termux and found the application files I wanted to rsync aren't visible in Termux, except maybe by rooting the phone. But I need to use banking and auth apps daily on it, so I assume that isn't an option.
1 reply →
that would require you to set up a domain name and use DDNS and trust your registrar, or to just always have your computers at a static IP with no NAT blocking you whatsoever.
1 reply →
FWIW I use syncthing-fork from f-store and im quite happy with it. Development seems kinda slow lately but it's chugging along.
Can you please elaborate and link?
I am developing and supporting game engines for over a dozen years. It works pretty much on any device which can run games.
Supporting it for Android is the worst experience ever. This is by far the least reliable OS in terms of compatibility or changes they make. It gets more convoluted and crapier with every exec bonus and 'feature' google invents.
Thank you google for killing yet another great app. There should be special category for apps that are "Done, Complete, Perfect as is", as with decent backwards compatibility on Android there should be no issues with them. I bet apk compiled for Android 1 still runs perfectly on Android 15.
Depends on the exact functionality. I'm aware of some battery events you could listen to from the manifest file in 2, that were removed at some point after that and now you have to listen for them from a running service. It broke a bunch of battery monitoring apps when it happened.
Also with services, there's additional requirements to keep them running that weren't there early on.
Android is one of the few platforms on earth where anything interesting actually could be done and finished, since they have actual stable API levels unlike Linux.... And they don't allow it
The problem, as most of the time, are bad actors. Which is the reason some permissions, SAF, disallowing targeting lower SDK versions etc were introduced on the Play Store.
Welp, there goes this recommendation out the window. Back to suggesting Dropbox.
Suggest F-droid instead.
Shit, this was the app I used to sync my obsidian notes through multiple devices.
I just recently started using it. Going to have to switch to fork version.
Keepass and logseq for me
Without Android what's even the point? If all I have is laptop and desktop, I probably just run scheduled rsyncs or a systemd timer something.
You can run that on android? Sorry I’ve been out of the android world for a while :)
No, the OP said they'd do that if they weren't considering Android.
syncopoli does scheduled rsync from android
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]: https://news.ycombinator.com/item?id=41891983
There is a fork mentioned above.
Joining the IA Writer club on Android: https://news.ycombinator.com/item?id=41658023
Once again, Im also in the niche of avoiding pay-for dozens of small services and just getting my simple stuff synced. Bam, another blowback. Im eager to ready what alternatives HN crowd might come up with....
Syncthing is essential for syncing some very important data for me. I’d be so disappointed if it was discontinued for the platform I use.
Shit, this is the app I use to sync my obsidian notes through multiple devices. R.I.P.
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
[dead]
...Does the author not understand that the Google Play Store is not the only distribution mechanism for apps? Why not just continue to distribute APKs for users to install manually?
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?
I suspect it could be, however it sounds like the author has lost all motivation to continue work on syncthing android and has formally announced that no further development will be done. And as much as I like syncthing-android I appreciate this sort of straight forward communications more and salute the author for clearly stating intentions.
Now seeing as it is open source (hooray) The way I think that will go is as follows, we will continue using the existing apk(I get mine off f-droid) for a few months to years, in the meantime seeing as the app is so useful to so many a few forks will arise, one will end up being the best, and we will eventually start using that one.
It's stated in the post. They do not think F-Droid provides enough distribution because it's not as popular as Google Play.
1 reply →
Presumably because most people don't know about F-Droid, and there's a question of whether it's worth continuing to develop the app for a tiny subset of the original audience.
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...
They do set how permissions on upgrades of Android work so even if it’s on f-droid, when they enforce the SAF protocols fsync will stop working if you keep your Android up to date
I used Syncthing for a while between various Linux distros, and I used Syncthing-Fork on my Android tablet, and it was okay when it worked, but it often borked up, and there were so many arcane settings and weird failure modes. I realized that the only reason I was using Syncthing was because it appealed to the vestigial, ultra-paranoid crypto-fascist BOFH in me, and I had grown out of those attitudes.
So today I just use Google Drive and MS OneDrive like a normal person. They work great. I love 'em. They don't fail like Syncthing. They're way more secure, and fully supported. Come join me! The water's fine!
How is Google Drive "way more secure" than a peer-to-peer encrypted solution?
Most of us do not have IDS/IPS/DLP tooling in our home networks, nor do we have a 24/7 on-call SOC team monitoring their SIEMs dashboards.
Google and Microsoft provision this stuff, even for consumers, with secure authentication and good protections.
2 replies →