Maybe we can have a discussion thread here, instead of spreading it over various issues in our issue trackers.
Right now, I got some questions about discovery:
What are the service name and service type required here?
What is the node parameter to /rest/discovery/hint and how can I get it?
I assume I still need to set localAnnounceEnabled in config to false to avoid any errors, right?
The link looks like it’s an implementation of DNS-SD on mDNS. That is not what syncthing uses; https://github.com/calmh/syncthing/blob/master/discover/PROTOCOL.md describes the protocol. I just commited a change that moves from multicast to directed broadcasts; you could start by testing if this works better, perhaps it does not need external support any more.
Anyway, the node parameter is the node ID, as it is usually shown. You should not disable local announcements, you are still relying on that being enabled, just feeding it data externally.
I just tried to do a new build, but I get this from ./build.sh tar or ./build.sh all:
beacon/cmd/mctest/main.go:8:2: cannot find package "github.com/calmh/syncthing/mc" in any of:
/usr/lib/go/src/pkg/github.com/calmh/syncthing/mc (from $GOROOT) /home/felix/golang/src/github.com/calmh/syncthing/Godeps/_workspace/src/github.com/calmh/syncthing/mc (from $GOPATH) /home/felix/golang/src/github.com/calmh/syncthing/mc godep: go exit status 1
Not sure why the paths are like that (the source is in /home/felix/golang/src/github.com/calmh/syncthing/). Maybe it’s because of this error I get during ./build.sh setup? . go install code.google.com/p/go.tools/cmd/vet: open /usr/lib/go/pkg/tool/linux_amd64/vet: permission denied
Don’t want to bother those who are arguing about the code to develop, but with the consent of the moderator I’d like to report this link to Google Play where Mr. Felix Ableitner seems to have brought Syncthing on Android. I have not tried if it works, but I think it is a useful information for users. If the moderator believes that it’s advertising, can erase the post and link and I apologize.
That’s exactly my app which we are discussing here 
So I guess it makes sense to have the link here, thanks.
Yeah the tests were broken there for a while, they are OK now.
You probably want to do a “sudo go install code.google.com/p/go.tools/cmd/vet” once and for all to get the vet tool installed. It’s not critical as such but it runs as part of the tests so things will be unhappy without it.
Okay I did another pull and the build works now (haven’t tried it yet).
I have go through apt-get, and vet seems to be included there (I can execute it manually). Installing it with sudo or as su doesn’t work as I can’t set $GOPATH for some reason.
If you have go vet from the go package then that’s fine, there is no need to install it again. The error from ./build setup can be safely ignored.
Alright. What about a check if go vet is already installed? (to not confuse people). Eg by running go help vet and checking the return value.
Pull requests acceptable. 
I’ll give it a try
Local discovery works now, great! But there’s a new warning dialog (did you add that or was it not displayed earlier because it already failed at local discovery?), that says “Global discovery: error reading DNS config: open /etc/resolv.conf: no such file or directory; no external announcements”. Do you access that file manually, or is that something Go does?
Btw exiting the Android app (that’s with calling rest/shutdown) gives “Connection to phone closed: unexpected EOF” on the connected node.
I made an android target for build.sh here. Does that look good to you? (I’ll wait for a release before doing a merge request, in case I did anything wrong).
Also, did you see me previous question about global discovery?
Okay I did some digging around about the dns problem:
Go reads /etc/resolv.conf in ./pkg/net/dnsconfig_unix.go
we can get the dns from shell with getprop net.dns1, but there seems to be no shell command on Android to resolve a host
I didn’t find a way to supply our own dns in Go, but maybe go-dns-resolver or godns might do?
Right, so there were a few changes in v0.8.7 to the logging infrastructure. One result of that is that warnings that were previously only shown on the console are now also shown in the GUI. That’s probably the cause for the new DNS warning. The Go DNS resolver does read /etc/resolv.conf, yes. Does this not exist on Android? That will mean no DNS, then…
Edit: If you build the binary on Linux, or perhaps even on Android itself, does the DNS resolver work?
Looking at the android build target, that’s fine by me but I wonder if it’s sufficient and generally useful? I.e. if I download just syncthing and run “./build android”, I don’t actually get something I can run on android, right?
Yeah, this is what happens when a node “disappears”. https://github.com/calmh/syncthing/issues/122 is relevant.
Nope, /etc/resolv.conf does not exist on Android. I looked up some workarounds there, and hoped you might have more insight into using those.
As I said, the filename is hardcoded in /pkg/net/dnsconfig_unix.go (as there is no real way to build Go for Android), and building on another platform won’t change that.
No you don’t get installable apks from that, but I use this target from my own build script. I could use build.sh all, but that would mean building unneeded stuff and unpacking the .tar.gz files, which might be complicated.
Right, looks like DNS won’t work on Android from Go right now at least. Might be worth filing an issue on Go for this, could be that it’s simple to fix. The libraries you linked to are for implementing your own DNS resolver, which would be some amount of work and would not integrate with the existing resolver. Currently though, DNS is only used to look up the global announce server. You could work around that by hardcoding the IP (I’ll let you know if I plan on changing it…).
For building, you could also GOOS=linux GOARCH=386 ./build.sh ; mv syncthing syncthing.x86 etc - that way you get a binary for your platform and can utilize the existing build steps (as they change, if they do). I’m not sure I want to include a build step for something that doesn’t work out of the box.
RIght, I could probably hardcode the ip into the syncthing source (which means maintaining a fork again), maybe I’ll do that if there’s no other way.
I didn’t think about building like that, it’s actually easier and I can change stuff myself. I’ll change it to work that way.
Hello Nutomic, I wanted to thank you for the good work you are doing to bring this to android. Will this port be opensource as well? Please consider it as I would love to see this tool be included into https://f-droid.org.
Thanks!
It is open source (github).
I’m not sure how f-droid handles native libraries, especially as this one is not officially supported by the ndk. I’ll look into that at some point (but I also wouldn’t mind if someone else submitted it).