as a consequence of the discussion in topic ( Folder creation broken in Android app ) and recurring questions on the github issue tracker why things that have been fixed by commit are still broken in the release version, I’d like to offer help for people that don’t mind installing a beta build on their phone. I understood that @AudriusButkevicius doesn’t have the time to build releases and beta’s repeatedly. Currently, a lot of development is going on regarding Syncthing Android and I need the early feedback from users to find bugs or improve feature enhancements that don’t fit to everyone for a reason.
What to find here?
You’ll find an unofficially built syncthing-android version offered as an APK file. The APKs are built on my private build server from the official code residing at https://github.com/syncthing/syncthing-android , based on cherry-picked commits I consider “safe” for end users. To avoid the beta colliding with the officially released version, the APK has “.beta” appended to its android package name. ( see https://github.com/syncthing/syncthing-android/compare/master...Catfriend1:buildBeta ) If you’d like to see what has been exactly used to build the latest beta, please refer to https://github.com/Catfriend1/syncthing-android/tree/buildBeta .
How can you get support for the beta?
This version lives only within this thread, so if you’d like to provide feedback, please do it here mentioning which version you downloaded. If your feedback is also relevant for the official master, I’ll carry it over to the issue tracker.
Switching between release and beta?
To switch from release to beta, please open the release app first. Head to the options menu on the left drawer, open sub menu “Backup” and export your settings. Then, please make sure you exit the release app (best way is to force-close it). After that, you can install the beta app from the download link below (requires “unknown sources” to be enabled in Android). Start the beta app, head to the options > “Backup” menu > “Import configuration”.
My intention here is to offer a “ready-to-use” syncthing-android app and working updates to it. Even though I’m only building this with having well thought about which code is safe and which should wait to get into the beta, I am not taking any responsibility if you did not do backup your data first or in case you even lose data. If you want to use a release grade syncthing-android, please head to google play or f-droid for the official releases.
2018-08-03 BETA 0.10.13+6a04d640bd0c7dcded028d39a162fb0fa6166127 (commit)
- Syncthing 0.14.49
- Added welcome wizard on first app launch
- Improved run conditions and run conditions UI
- Fixed “folder is read-/writeable” detection broken since release 0.10.13
- Fixed race crashes during refresh of the devices list
Source code if you’d like to build yourself:
This is not, then, a beta of the thing that will actually be released at some point - more a “Catfriend1 edition” that is different from the official version?
@calmh My intention is to build it from the officially approved and commited code in the github.com/syncthing/syncthing-android master. I’m not bringing new code in on my own. If I have new code, I’ll continue to open pull requests to the master repo. The reason why I’m building from github.com/Catfriend1/syncthing:buildBeta “fork” is that I need ten lines of the build script changed so I get a new package id for android (com.nutomic.syncthingandroid.beta).
So, yes, the code I used to build is already on the official syncthing-android master and will get released sometime.
I cannot use com.nutomic.syncthingandroid as this would conflict with Audrius’ releases and as I don’t have the proper signing keys to use this specific package id.
The “official beta” channel is also locked as I don’t have permission there to assit Audrius.
Right, so we may be talking past each other. “Cherry picked commits” to me means divergence. “Beta” means a certain commit hash is first released as v1.2.3-beta and then, once it’s proven itself, released again as v1.2.3 without any further changes. You seem to be wanting to do the latter, which sounds fine to me, but also means there’s no cherry picking involved.
(That there is currently a diff for the beta suffix and whatever build fixery is beside the point.)
The reason I’m being picky about this point is that it is the difference between a beta and a fork. A beta we should assist with and coordinate, I think. A fork you are welcome to do, but that’s your thing then.
If you (the collective you as in the people who do the Android thing) want to do betas I think the first thing to do is to decide on a release schedule / policy of some kind. This is what Syncthing does.
And of course, releasing commit A as v1.2.3-beta and then a different commit B as v1.2.3 defeats the point entirely as there may be any number of new regressions between A and B. So the beta releases and the regular releases really need to be coordinated.
It’s actually easier with Android. As you release 0.10.95 (as in a real release), just don’t roll it to the production channel, it lands in beta. If that is fucked, you release 0.10.96 to the beta channel, and if that did not break the planet you roll that to prod. The only difference is that fdroid will pick up all this garbage along the way as prod. I think we might have to mark these as pre-releases in github, and mark them as real releases once we put it on the prod track in gplay, meaning we need a magical script for that.
Does f-droid do its magic as soon as you create a tag, or can you just avoid creating a GitHub release until it’s time for a stable release?
Otherwise it sounds like all pieces are in place. I still suggest you decide on a schedule and stick to it, barring disasters. I.e., something like our “stable release every first Tuesday of the month, beta the week after”.
I think it works off git tags, but yeah, we could push the tags upon actually releasing.
I just tried this build:
2018-08-03 BETA 0.10.13+6a04d640bd0c7dcded028d39a162fb0fa6166127
and created a new test directory on my external SD card (storage permission granted). This is on a LineageOS (Android 7.1.2) device.
It created the new directory just fine using the SAF framework and then says:
“Your Android version only grants Syncthing readonly access to the selected folder” in the folder settings page.
Let me know if there is anything I can do to assist you in debugging this.
P.S. F-Droid can work in “manual-only” mode, on any new commit or looking for tags with a certain version numbering scheme AFAIK. There is also a way to automatically distinguish “beta” and “stable” releases based on this.
@spaetz If the message says android treats this directory read-only that’s correct. It’s an android limitation that even if you’ve granted storage permission the android os will force the directory to be readonly for the syncthing (native linux binary). This problem has been written up a lot of times and is mainly coming from the go binary not having appropriate ability to communicate read-write permissions to android SAF. You can workaround with:
- using root privileges
- placing the directory on extSdCard/Android/data/com.nutomic.syncthingandroid.beta/files/[your_folder_name]
- patching your android os (very ugly!)
@AudriusButkevicius @calmh I’d suggest throwing the beta out every two weeks on friday. I picked this plan randomly you wishes to adjust it are welcome.
@AudriusButkevicius Could you please assist in making the “magic script” as I’ve no permissions to be able to develop and test a script. Maybe we can also put an extended build.gradle like the one in Catfriend1/buildBeta on a branch in the main repo. This would assure to build on the lastest official commit when the master is pulled in before every beta build. (That’s what I’m currently doing on my repo to follow calmh’s guideline to make a beta with stuff later to be officially released.)
Everything would be easy if it wasn’t for f-droid.
I have to figure out how to prevent them from picking up releases.
Looks like they can be told to just look at tags that match a given regexp, so you could for example let them release tags matching
^fdroid-v([0-9.]+)$ or so.
No idea how to get that policy into the system though.
Or just let f-droid be your beta channel. Hey ho lets go.
@Catfriend1 For what it’s worth, the build process should ideally not differ either. For Syncthing the “betaness” of a release is decided completely by what
git describe returns. If the resulting version string contains a dash it’s not a release version. Some other policy could apply for you guys as appropriate.
Making a stable release involves pushing a new tag and rebuilding. From what I understand for Google Play you don’t need even that. The only thing would be maybe a new tag to poke at f-droid.
Our current process is as follows:
- We decide to release
- I run ./prepare-release.sh which updates translations, bumps some number important to google, updates version info, asks for a changelog.
- I push these new commits to master, together with the new tag.
- I manually run
Release Syncthing-Android specifying a commit/branch to build from which rolls it to beta channel
- I manually roll beta to prod after some time (or gradually roll out).
In the background, f-droid picks up the tag and builds a version itself.
Essentially I am thinking of doing the following:
Release Syncthing-Android job runnable by @Catfriend1.
- Change the job to require a changelog upon trying to build. The job itself would run ./prepare-release, pull in translations etc. This would also push a version tag, and land the version in G-Play in the beta channel. Potentially looks for last released version, so that changelog is “accumulating” between all unreleased versions until we actually release (Not sure if it’s possible).
- Change f-droid to not pick up generic version tags, but ask them to look for f-droid-123.123.123
- Have another
Release Syncthing-Android to prod, which checks for the last 123.123.123 tag, checks that that’s the tag (or the other magic number) in the beta channel, if it is, rolls the beta to prod, and tags 123.123.123 tag with f-droid-123.123.123.
The annoying this is that we will have gaps in versions (as in 0.10.99 might be a beta that was never release), but I guess that’s ok.
I can do the F-Droid stuff if you’d like me to. I am already set up to do the necessary changes (it’s essentially just PRing against their metadata repo). Possible only build on tags matching
[0-9].[0-9][0-9].[0-9]$ to exclude any
.*-beta$ or similar versions or by building on custom tags as you proposed (
I asked but didn’t get an answer yet on the f-droid irc about pre-releases. Potentially we could add an exact clone of the existing Syncthing app to the reop except that it’s called e.g. Syncthing-dev (or -beta, …) and there’s no restriction on which tags are built.
I think we should move f-droid to build from
release-\d+\.\d+\.\d+, and all other tags will be considered as beta tags.
release- prefix instead of just normal semantic versioning as it is currently?
I guess it doesn’t matter much, we can use 0.10.10-prerelease or something like that before pushing to google play.