On Mon, Apr 13, 2015 at 13:09:30 -0400, Nathan Freitas wrote:

...

...

One interesting issue is that GoLang 1.4.1, which we are using to cross-compile the Meek and Obfs4 pluggable transports to Android, only supports targeting Android ARM for right now... I assume that will change soon, but if not, we may have to add Obfsclient back into Orbot for supporting x86 devices.

Hmm, maybe I should add obfs4 support to obfsclient. I have code for all of the crypto I would need to add.

Let me reach out to the GoLang Android community and see what the blocker is... I was thinking the same thing though, it wouldn't be hard to still support Obfsclient, along with the Go-based PT's.

All I could find is this:

https://groups.google.com/forum/#!msg/golang-dev/BtGFDUmJX-U/YEoQz0eP4rgJ

But there is no android/x86 in the current changelog for 1.5 (to be released in ~july) so I don't know.

Possibly stupid question, but wouldn't a static linux/x86 binary work just fine as long as you're executing it directly? As far as I know the Android port is just for all the bindings involved in e.g. writing a game in Go that does OpenGL calls back to Android.

For example, I found this bit in a blog post online:

Copy myexectuable under your Android project’s ./libs/armeabi/ folder. If you’re targeting one of the rare x86 Android devices, build to x86/Linux and copy the resulting binary to ./libs/x86 (and yes, you can include both in a single APK, and it will deploy whichever one is appropriate).

But then this would mean that we wouldn't need android/arm either, since we could just use linux/arm instead :)