Be careful: Do NOT use this in a production environment. It is a work in progress to revive Syncthing-Lite. To be able to build the app, I had to replace an outdated repository reference by “appodeal.com” which I don’t know if it’s a trustworthy source for the aar/pom artifacts used by the build of “anko-commons” which is deprecated.
Always backup critical data first before testing.
credits go to the authors of … and their contributors with respect for the work they have done years ago before the project has been abandoned.
Please provide feedback if you can access your Syncthing share successfully with it.
It crashes out on 0 byte files and the welcome slide “share folder” is broken (it works when you just skip it , force-close the app, accept the device request on the other side and reopen the app).
I didn’t repair the slides yet as the used AppIntro dependency also is deprecated and needs a transition to sth newer.
If anyone interested. This was really a coincident sighting, nothing to do with the work on syncthing-lite. It’s root cause was not malicious. This happens under normal circumstances on my Win11 24H2 machine when I open GitHubDesktop and go to the command line. Sometimes I’d like to open Windows Explorer within a folder opened in the cmd window at that moment, so I type “explorer .” and hit enter. This spawns the explorer.exe /factory process mentioned above. Analyzing with the help of ProcMon (Sysinternals) shows that there are no foreign dll/modules involved. .
just informative: In the meantime, I was able to replace the deprecated slf4j-android and anko-commons libraries by plain kotlin code. I thought I’d required this to be finally able to use a newer Android Gradle Plugin (AGP) to compile the app. But unfortunately didn’t had the outcome I had expected. I’m still stuck with the old AGP version 4.0.1. As soon I update it to 4.1.0 (or higher), the APK builds fine but the app is “just a UI” and the functional code from the syncthing-java library is no longer executed. When this happens, no log lines are visible to logcat to let me find out the root cause. I’m also missing a crash log line. The app just stays there, stalled and spinning the “please wait” dialog.
I need to dig further. Comparing both APK, one built with AGP 4.0.1 and the other with AGP 4.1.0, there’s not much difference to see with my human eyes. They are almost the same size, but the count of “classesXY.dex” files is very different.
The app is still non-functional and crashes. I’ve to rewrite some code which is not “kotlin 1.7+ compatible” yet. My last week of work was about getting the project to build within a modern java, kotlin, gradle, agp environment and replacing deprecated logger, anko (…) dependencies by rewriting code.
My first milestone is reached: It builds again and i was able to set-up CI which will empower my development fixing issues.
Thank you . The revive work on this app is horrible. For example, one simple call to File.canWrite() broke the whole thread library of the app after updating beyond android gradle plugin 4.1.0+. From my point of view, it’s unbelievable that a simple java file api broke down with it, no matter if I stayed on jdk 1.8 or moved on to jdk 1.11. I am now reaching the end of my dependency and code migration to the current “state of the art”. Got a compile using the most recent kotlin 2.2.0, most recent room database 2.7.2 and gradle 8.13 . Meanwhilst, I’ve fixed again a lot of deprecation and lint issues popping up with every gradle and kotlin version bumps, turning them finally down to zero and re-enabling lint.abortOnError for the builds to get notified when quality will go bad in the future.
What I still do not understand is why my index is no longer coming in from the “real” Syncthing “server” instance communicating with the app. This was broken a fews days back in conjunction with Syncthing v1.18+ and I fixed it. Then upgraded my Syncthing test instance to v2.0.0-rc.23 and the index does come in fine. As soon as I fire up a new fresh test instance using v1.30.0, I see the file entries correctly and completely driving in, but Syncthing-Lite does not handle them. Let’s see if I can solve this too… on the other side, I could save my time and just say, let it be. If communication with Syncthing v2.x works that will be a good start for the first “fresh” release of Syncthing-Lite. (I will still need a lot of time to get other bugs crushed…)
It would be funny, though, but I do not want users to spam the issue tracker or forum with “What’s the spoon good for?”. Sure, the readme answers this, but who reads readmes …
Syncthing-Lite was there years ago and maybe is still known by some users(?). Lite suggests, there is no full syncthing functionality, so I hope for some users this will already imply what it maybe so they won’t ask. Could be that I’m proven wrong on this, but somewhere I need to start. A name change could still follow later if it proves necessary.
There is also no name collision, as the publishing of Syncthing-Lite in F-Droid and GPlay is inactive.
Be careful: Do NOT use this in a production environment. It is a work in progress to revive Syncthing-Lite. To be able to build the app, I had to replace an outdated repository reference by “appodeal.com” which I don’t know if it’s a trustworthy source for the aar/pom artifacts used by the build of “anko-commons” which is deprecated.
Always backup critical data first before testing.
File transfers get stuck sometimes but smaller files sync instantly in most cases.
and the welcome slide “share folder” is broken (it works when you just skip it , force-close the app, accept the device request on the other side and reopen the app).
.
. The revive work on this app is horrible. For example, one simple call to File.canWrite() broke the whole thread library of the app after updating beyond android gradle plugin 4.1.0+. From my point of view, it’s unbelievable that a simple java file api broke down with it, no matter if I stayed on jdk 1.8 or moved on to jdk 1.11. I am now reaching the end of my dependency and code migration to the current “state of the art”. Got a compile using the most recent kotlin 2.2.0, most recent room database 2.7.2 and gradle 8.13 
. Meanwhilst, I’ve fixed again a lot of deprecation and lint issues popping up with every gradle and kotlin version bumps, turning them finally down to zero and re-enabling lint.abortOnError for the builds to get notified when quality will go bad in the future. 
.