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”)
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.
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.
I/ActivityManager( 638): Displayed com.nutomic.syncthingandroid/.gui.MainActivity: +633ms (total +11s139ms)
I/SyncthingService(21848): Web GUI has come online at http://127.0.0.1:8080
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 http://127.0.0.1:8080/
W/SyncthingService(21848): : [6EDZZ] 04:36:31 FATAL: Cannot start GUI: listen tcp 127.0.0.1:8080: 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 http://127.0.0.1:8080/
E/AndroidRuntime(21848): [6EDZZ] 04:36:31 FATAL: Cannot start GUI: listen tcp 127.0.0.1:8080: bind: address already in use
E/AndroidRuntime(21848):
E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService.runNative(SyncthingService.java:175)
E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService.access$1000(SyncthingService.java:53)
E/AndroidRuntime(21848): at com.nutomic.syncthingandroid.syncthing.SyncthingService$3.run(SyncthingService.java:347)
E/AndroidRuntime(21848): at java.lang.Thread.run(Thread.java:841)
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 com.android.internal.view.IInputMethodClient$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.
the libsyncthing.so 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.
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.
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.
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 127.0.0.1:8080 However, it would be nice to check this and give back an error message instead of hanging on waiting for API indefinitely
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.