The Syncthing-android app has been updated to target Android 11 / API level 30. That changes how Android lets Syncthing interact with the filesystem. Which is both a good and bad thing, bad first: There are some potentially dangerous behaviour changes, that’s why a database reset needs to happen, and it might reduce performance. On the bright side, Android 10 and above should now have access to external SD cards (except some paths like /Android, which are now not accessible, also not on internal storage). Anyway what I really would like to know is:
Do you use Syncthing-android from the beta channel and did upgrade to v1.19.0-rc.2? Please write about your experience here, regardless of if you encountered any problems or not - I am also very glad to hear “All good, nothing interesting to report”
The external SD card access is limited to Android 10 and later, so does this mean that the behaviour in Android 9 and older should basically be the same as with the current stable app release? The database reset is unavoidable no matter which Android version is in use, right?
That’s my understanding, as Android <= 9 didn’t have scoped storage. It’s not at all clear though to me what exactly will happen with older versions and a newer target API, i.e. what behaviour changes, if any. That’s why the db reset is done on all devices (except rooted ones). @tomasz86 Did you try it?
For now I can only confirm that the app starts and seems to work properly under Android 4.4 KitKat.
I originally wanted to perform a direct upgrade on one of my devices, with real data, etc., but the problem is that I normally install and use the app from F-Droid, which’s got a different signature, so a direct upgrade is impossible. I did try to back the data up, then replace the app with the GitHub release, and then upgrade it while also restoring my old data, but in the process I also kept ending up restoring libsyncthing.so, which eventually resulted in a weird combination of a v1.19 app and a v1.18.3 Syncthing. I spent around 2 hours on the testing, all in vein so far, so now I need to take some rest before going on with it later .
tested it on a pixel 1, worked without any big flaw.
i still have probably a few unrelated issues (which i will report more in specific on later) such as a file that i deleted having returned, anther file not getting synced, and broadcasting apparently buggy, but all those issues were there before.
if anything, this update even helped with a reported sync status which was at less than 50% and now shows 99%, which is probably more accurate.
close enough to “all good, nothing interesting to report”, i would say.
Tested without issue on Oppo (model CPH1979) Android 11, ram 8GB. Tried Received Encrypted and unencrypted all seemed very smooth. This was a new installation, not an upgrade of database from an earlier installation.
Folder is at the main storage location, there is no SD card in this phone.
Edit: next I’ll try updating an exiting ST version 18.3 on Pixel 3a running Android 12 unencrypted folders with several thousand files, and report results.
Thanks a lot @tomasz86, @cregox and @rustycanb for responding. I have to cut any ongoing investigations short, as I am releasing 1.19.0 now. Of course feedback is still welcome.
So yeah, scoped storage here we come - brace for impact and so on and so forth xD
Hi there!
I’m using Syncthing on four phones: two with Android 11 and two with Android 10 which syncs ~70 and ~40 GBs of photos and videos. All of them have app installed from Play Store and partipiating in beta-test there. I’ve seen an information\request screen about this API 30 and Scope Storage change a while ago and have agreed on all it asked for. It took some time to rebuild database but all worked flawlessly: no issues or conflicts or missed files.
More like as Jakob’s animation for me, unfortunately.
My Pixel 3a (Android 12) was on 1.18.3 with three synced folders, other nodes (routed through one Receive Encrypted RPi4) are on 1.19.0-rc.2. I foolishly did not disconnect them before upgrading the Pixel to Android 1.19.0-rc.2.
Although appearing initially smooth and progressing towards 100% sync, it stalled at about 80-90% on each folder, seeming to add 77 document files out of several thousand, which propagated to other nodes. At this point, I waited a few hours but nothing progressed.
Unhelpfully, I did not collect any logs. It was late at night and I needed the documents to be reliably sync’ed for work the next day.
I restored the Pixel 3a using Syncthing-Fork (1.18.6) and deleted then rebuild the connections, ensuring the all files were checked against by backup with rsync.
Folders other than the three from the Pixel, were unaffected. I’ll try again later with limited test folders and one other device.
Edit: As mentioned earlier, all went well on a clean installation on my Oppo (Android 11), probably the problem was with the database conversion. Maybe I should try a clean install on the Pixel.
Hmm, thanks for the feedback. The weird bit here is that the upgrade process did not convert anything, it did create a clean start - that’s what that welcome screen on upgrade announces. No idea what happened there for you.
I got the update this morning and went through the wizard, resetting the DB. Most of the scanning looked good afterwards, but now I have two folders with a strange state. They are both configured as receive-only on the Android side and shared with multiple devices, two of which were online at the time of scanning.
Now these folders show a correct local state from scanning the previously synced contents (on internal storage). But the global state has dropped to zero and it shows the “revert local changes” button. But if I were to use that, the local files would obviously get deleted.
Still need to check on the other side what state it’s showing and will update this post when I have a screenshot from there as well.
UPDATE: Never mind, the problem was that these two folders were shared with an online remote device, but not mutually. Logging into that remote’s Web GUI revealed they were still listed as pending folders. Meanwhile the problem disappeared as soon as another remote device which did actually share back the folder went online.
I have an idea cooking for a few weeks now that I want to implement: Mark such folders in the GUI where we know the connected remote device does not include it in their ClusterConfig message although we share it with them. Stay tuned for a PR within this year
.
