On Mon, Apr 13, 2015, at 02:05 PM, Daniel Martí wrote:
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.
There a few more changes in there, as well, such as how DNS works on Android, and few other small underlying differences.
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 :)
We were previously using linux/arm for the PT compiling, and it mostly worked, but it turns out there are enough small differences in the Android API from Linux, that it does matter to target Android specifically. This is similar to why we need the Android NDK for tor cross-compile, and not just a generix linux ARM build.
+n
On Mon, Apr 13, 2015 at 14:30:04 -0400, Nathan Freitas wrote:
We were previously using linux/arm for the PT compiling, and it mostly worked, but it turns out there are enough small differences in the Android API from Linux, that it does matter to target Android specifically. This is similar to why we need the Android NDK for tor cross-compile, and not just a generix linux ARM build.
Fair enough. It would then be good to know whether android/x86 is planned for 1.5. Either way, that won't be out until july/august, so perhaps using obfsclient in the meantime is for the best.