Preview for Syncthing-Android 0.4.0

The new version of Syncthing for Android is almost finished. But this was a major change (~800 lines of code to ~2800), so I’d like to get this tested before releasing it into the wild.

As a bonus, this version already works on Gingerbread (post here if it doesn’t).

Please post any issues or possible enhancements in this thread.

KNOWN ISSUES:         - restart notification not completely working (as a workaround, restart the app)         - crash on screen rotate

PLANNED FEATURES:         - qr scanner (#39)         - file browser (#40)         - actionbar icons, it would be great if anyone wants to create those (for “create repository” and “create node”)


No luck with my Liftab (unrooted Medion Lifetab P9514, Android 4.0.3).

The app starts, displays “Waiting for API”… nothing happens, eventually the app gets killed by the OS.

The logcat is here:

Some entries show that the API is active, and I could access it with a normal browser (as long as the app was running).

Wild guess: API key?

Ok. It’s not the API key. :slight_smile:

I’ve checked out the native-gui branch, added some log calls and tried to find out what is happening.

It turned out to be a problem in PollWebGuiAvailableTask

I’ve determined that doInBackground eventually finds the web GUI, but onPostExecute is not called. If you check the above mentioned logcat the message “Web GUI has come online at …” is missing eventhough the native binary is clearly active.

Using Google, I found this post. I’ve noticed that PollWebGuiAvailableTask is already wrapped in a task and I’m not sure if the mentioned “UI thread” condition is valid.

Sorry for the late response, I’ve been busy the last days.

Looks like this might be the same problem as #41.

Could you give this diff a try? It should call the AsyncTask from the main thread.

No, that didn’t work either.

However, I found this post. Further down it states:

“The AsyncTask class must be loaded on the UI thread. This is done automatically as of JELLY_BEAN.”

The Lifetab is on Android 4.0.3 (Ice Cream Sandwich). This might explain why you never encountered it.

Yeah, the code in the diff should do exactly that.

Btw it’s the same thing that chr15m added in his pull request for Gingerbread. I’m still kinda busy, so don’t expect an update before thursday.

Has anyone had any crashes with this version? It crashed on me once now it is refusing to run properly(constant crash). I reinstalled, wiped the cache no solution. I will try to capture some logs later. I was just wondering if anyone had similar problem.

Ok here is the crash log for me

I/ActivityManager( 638): Displayed com.nutomic.syncthingandroid/.gui.MainActivity: +633ms (total +11s139ms) I/SyncthingService(21848): Web GUI has come online at I/RestApi (21848): Syncthing version is v0.8.14-22-g34bd5b9 W/SyncthingService(21848): : [6EDZZ] 04:36:31 INFO: syncthing v0.8.14-22-g34bd5b9 (go1.2.1 linux-arm android) felix@T420 2014-06-13 18:45:57 UTC W/SyncthingService(21848): : [6EDZZ] 04:36:31 INFO: My ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx W/SyncthingService(21848): : [6EDZZ] 04:36:31 INFO: Starting web GUI on W/SyncthingService(21848): : [6EDZZ] 04:36:31 FATAL: Cannot start GUI: listen tcp bind: address already in use W/dalvikvm(21848): threadid=11: thread exiting with uncaught exception (group=0x4161dc50) E/AndroidRuntime(21848): FATAL EXCEPTION: Thread-1377 E/AndroidRuntime(21848): Process: com.nutomic.syncthingandroid, PID: 21848 E/AndroidRuntime(21848): com.nutomic.syncthingandroid.syncthing.SyncthingService$NativeExecutionException: Syncthing binary returned error code 3 E/AndroidRuntime(21848): [6EDZZ] 04:36:31 INFO: syncthing v0.8.14-22-g34bd5b9 (go1.2.1 linux-arm android) felix@T420 2014-06-13 18:45:57 UTC E/AndroidRuntime(21848): [6EDZZ] 04:36:31 INFO: My ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx E/AndroidRuntime(21848): [6EDZZ] 04:36:31 INFO: Starting web GUI on E/AndroidRuntime(21848): [6EDZZ] 04:36:31 FATAL: Cannot start GUI: listen tcp bind: address already in use E/AndroidRuntime(21848): E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService.runNative( E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService.access$1000( E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService$ E/AndroidRuntime(21848): at W/ActivityManager( 638): Force finishing activity com.nutomic.syncthingandroid/.gui.MainActivity W/DropBoxManagerService( 638): Dropping: data_app_crash (989 > 0 bytes) W/InputMethodManagerService( 638): Starting input on non-focused client$Stub$Proxy@4203a198 (uid=10155 pid=970) I/SyncthingService(21848): Shutting down service I/Process (21848): Sending signal. PID: 21848 SIG: 9 I/HK/LatinKeyboardBaseView( 867): closing org.pocketworkstation.pckeyboard.LatinKeyboardView{420091d0 V.ED… …ID 0,0-1200,820 #7f07000a app:id/LatinkeyboardBaseView} I/ActivityManager( 638): Process com.nutomic.syncthingandroid (pid 21848) has died.

I am also having one more issue with the Android version.

I added some 20gb of music files to the sync folder on Android (for test purposes). I started using super high cpu all night, roughly 10 hours and it still has not synced any of the files (from android to another node). Before that I did some tests it synced couple hundred mb fine. That is when I decided to do heavy testing with the mp3 files.

This error (usually) happens because the syncthing binary is already running.

The old binary should be shut down automatically, not sure why this doesn’t work here (maybe you have a second syncthing apk installed and running?)

Anyway, a restart should definitely fix it.


the is not killed after a crash, I do not know why. I tried it many times and it looks like libsync persistently staying open in memory after a crash therefor only solution is to restart, however that is not very convenient.

The other issue is that the android version does not like heavy sync folders as I stated above. I am unable to to get it sync if it goes above 1gb. It just stays there for hours using alot of cpu without doing anything in reality.

Does that problem only occur with the version posted here, or also with 0.3.x? It might be that some commits are missing in the preview.

@calmh Do you have any idea about the sync problem?

Nutomic, this is a 0.4 issue. I did not try it with previous versions.

Okay, you should probably use 0.3.8 for the time being, as I haven’t updated this recently. (you can just install it over this version).


3.8 is better, it seems like I do not get the crashes anymore. It seems to be syncing as well however I am not %100 sure about what is going. This has the idle %100 cpu situation going on here

I am on 4.4 Arm7 rev0 CyanogenMod

If you guys can test out with alotf of big mp3 files , that would be great.



Ok I was wrong about 0.3.8 a bit.

I do not get crashes as often. However when it crashes once, it keeps crashing afterwards. So I have to restart. I believe that you might need to do heavy testing with big binary files to see what I am seeing here.

And the weird thing is that after crashing, the syncthing keeps running in the bg and using around %40-%50 cpu.


Okay could you post a full logcat (from first, working syncthing start to the first time it fails). And also describe the exact steps to reproduce.

And best post it as a Github issue :wink: Though I’m not sure myself whether it should be at syncthing or syncthing-android, but either way is fine.

I also get ‘Waiting for API’ with the latest (0.4.19) Syncthing app on Android. What to do?

edit: forget about it, it has to do with that there is already a daemon running on :blush: However, it would be nice to check this and give back an error message instead of hanging on waiting for API indefinitely :wink:

Hm yeah this is difficult.

After some update, syncthing now logs “failed to start” and tries to restart whenever the GUI port is taken. Before that, I could note when the binary exited and show a message, now I just don’t know.

@calmh Is there a way to get the old behaviour back? Maybe STNORESTART also fixes this?

Other than that, I hope with official Android support in Go 1.4, golang binaries will be killed properly when the calling Java code is killed.