Those of you using termux and stuff, which Syncthing build is it you’re running? Where does it come from? Is it built for Linux or for Android? (There are a few Android-specific fixes in the actual Syncthing binary as well, which only kicked in when built for the Android platform.)
Building for android/arm64 seems easy nowadays, at least on my computer go run build.go -goos android -goarch arm64 build just works without any special Android stuff installed.
I want to echo the statements of gratitude already expressed as well as the disappointment that this is the state of affairs. Of all the streaming services and digital garbage we spend our money on, it is absurd that we struggle to maintain a piece of software as amazing as this, and one that is so valuable in the daily lives of so many people.
The relationship to Syncthing-Fork and its future are still not clear to me. What I understand is that at this point, Syncthing-Fork is now the only maintained Android app for Syncthing, and the maintainers are not affiliated with the core Syncthing development team. Syncthing-Fork does not publish on Google Play (fine by me), but they plan to continue maintaining the app to address security issues and Android OS evolution. Does that summarize the situation? Is there any reason not to switch to Syncthing-Fork? (no offense intended to its developers of course)
@imsodin@calmh In response to your comments above, which state that Syncthing will continue to function on Android despite the discontinuation of the official app, I wanted to ask some clarifying questions:
Will the Syncthing team continue to officially support building and running the Syncthing binary for Android? Will there be fixes for any Android-specific bug reports?
@calmh posted an example command for building the Android binary: go run build.go -goos android -goarch arm64 build; However, I just want to confirm that it is only possible to run executables directly on Android with root privileges, correct? So, building the binary alone would not be sufficient for users with non-rooted devices? And, if so, then the only way to run Syncthing on a non-rooted device would be to install it via an APK or to use Termux?
If my understanding is correct (i.e. that Syncthing can only be run on non-rooted devices via APK or Termux), then would the Syncthing team consider maintaining a minimal version of the APK build on GitHub and/or F-droid, whose only function is to launch Syncthing and open the GUI in the user’s default web browser? This way, there would be no need to release on Google Play or maintain a native Android GUI; the only maintenance would be to ensure that the APK continues to build and is able to launch the web UI.
There isn’t much of official support, whatever that means, but if someone proposed Android specific bug fixes that don’t have adverse effects on something else there is no reason not to merge them. We did that as recently as today.
I’m not involved with Android and won’t be doing any such fixes, and can’t answer the other two questions, other than with ”no, not by me at least”.
But this is open source. If you want such an apk, build it.
You can run the compiled binary without root directly from ADB (see https://developer.android.com/tools/adb) if you copy it to /data/local/tmp and make executable with chmod +x. Of course, this is only useful if you don’t reboot the device very often (as the binary needs to be started manually every time). Otherwise, the aforementioned Syncthing Fork app or Termux are more streamlined solutions.
This is so sad! But I understand where you’re coming from and I support you!
I have tried switching to syncthing-fork. It … worked, but it rescanned everything which meant half an hour of hot phone, and some weird issues. One folder couldn’t properly sync fully because of permissions errors on android, but I guess that’s on par for the course here, and exactly the kind of issues that makes writing such software so difficult in android…
While the official statement is clear, I think we would all like to hear what the Syncthing-Fork’s maintainer @Catfriend1 has to say about the situation and their plans.
And of course, a BIG Thank You to the team and to everyone involved in developing and supporting this so useful app
That maintainer is now the difference between an android app with syncthing or no android app with syncthing - I for one am super grateful for him doing that work and would suggest you try to cut him as much slack as you can. Here that means before asking for statements, go check out his repo to see if you can answer that yourself. Unsurprisingly the question has already been asked, and got an answer: Official Syncthing Android App will be discontinued · Issue #1149 · Catfriend1/syncthing-android · GitHub
Hi,
Syncthing-Fork is a personal project, originally meant to keep the Android app alive for my friends and family. I’ve shared this work from the very beginning and will do so when I hit the code for updates. I will primarily do compatibility with the Android phones “we” use here, so that’s currently the range from Android 10 to 14. Feature development is currently not on my roadmap. I myself use the app and depend on the availability of Syncthing on the Android platform for my own workflows.
You’re welcome to use the releases on F-Droid or my GitHub if you like the fork.
Bummed to hear this app is done. I use Syncthing on five devices including my Android mobile.
Thank you for the development work that went into the project up to this point. Here’s hoping someone picks up the torch down the road. Not sure if this matters, but I’d be happy paying for this app if that could provide stable maintainership into the equation.
There’s another issue with Termux: it doesn’t work with Work (no pun intended) Profiles! To make things worse adb can’t pull any files from Work Profiles too. I tried everything I could find, I think honorable mentions are primitive ftpd and rsync server from F-Droid but NOTHING works reliably with any sprawling directory structure. Syncthing was (well, is, and hopefully it’ll remain for a good while) THE thing that’s working without any drama.
In the light of this discussion I’d like to mention that I’m currently extending Syncthing Tray to provide Android integration. (Syncthing Tray could be built and run on Android for a while simply because Qt supports Android. However, it was basically unusable without further platform integration and a mobile-optimized UI.)
The motivation for this is not that the official Syncthing app was discontinued. I started developing Android/mobile related bits in Syncthing Tray before that. I’m also actually using @Catfriend1’s fork anyway and can only recommend it. (@Catfriend1 Thanks for maintaining the fork! It has been very useful to me and I hope you keep maintaining it as my approach with Syncthing Tray is probably not going to cover all use cases - see caveats below.)
The motivation is the following:
It will be great to streamline user experience between Syncthing Tray on the desktop and the Syncthing app on Android. (This actually came up quite quickly after I mentioned Syncthing Tray on these forums.)
It is kind of neat from a technical perspective to share lots of code between Syncthing Tray on the desktop and on Android. The entire client code to access the Syncthing API but also status strings, icons, data models and more can be reused. Also build system code including code for building Syncthing itself as a library can be reused. Of course this is not relevant for end users but it means I will probably be able to maintain an Android app “just on the side” as there’s not that much additional effort involved.
I want to provide a few features from Syncthing Tray on Android that the current app does not provide (without duplicating code between Syncthing Tray and @Catfriend1 fork; so I’m not contributing to that and do my own thing instead). This includes the (so far admittedly rather clunky) UI to browse the global filesystem tree of a folder and modify ignore patterns based on that. This also includes the tray icon and status.
The mobile-optimized UI can be written with Qt Quick and thus can to some extend also provide a good user experience on the desktop. So UI code for the app can in turn be re-used again to implement some features in Syncthing Tray users were asking for like allowing to add folders/devices via the setup wizard.
There are (of course) caveats:
I will probably not be able to support older devices. I am currently testing with Android 14. Maybe I can make it work as of Android 10 but I can probably not support older versions.
The app will use more resources than the official/fork app due to the use of Qt. It seems acceptable on my 3 years old low-budget Samsung phone with 4 GiB of RAM so far. On weaker/older devices the fork app is probably still going to be the better option.
Development is still in the works and it will take a while to get everything in place. I cannot make any promises on when it will be in a usable state.
There won’t be a Google Play release. Arguing/fighting with Google is nothing I want to spend time on.