
Go and Android - stickhandle
http://dennisforbes.ca/index.php/2014/03/19/go-golang-and-android/
======
aray
Every six months or so another way to run go code on android devices is
published. Sometimes it's SDK wrappers, other times (like this) it's native
executables.

The author's approach is interesting, but lacks MIPS support (though would
extend successfully to x86 devices, as the author notes).

My almost equivalent attempt was to rebuild the Android NDK (native
development kit) toolchain with --language=go added, and built all the GCC/GNU
toolchain support for it for _all_ targets. (Granted the rebuild-the-toolchain
solution can be a bit hairy if you're not familiar with it.)

~~~
justincormack
Yes MIPS support will be needed for an official solution I guess (at least
there seems to be only one ABI spec for MIPS Android, o32, MIPS32r1).

I really don't know how many MIPS Android devices there are out there.

------
pjmlp
This is nothing more than a pure hack as it is not supported by Google and
does not allow distribution via Play Store.

The ticket for Go support is open since 2012, so clearly there isn't any
interest from Android team to do so.

[https://code.google.com/p/android/issues/detail?id=39482](https://code.google.com/p/android/issues/detail?id=39482)

~~~
RyanZAG
You didn't read his post to the end - you can include the Go binary into your
normal Android app and then manually execute it. It certainly does allow
distribution via Play Store and many apps currently available through the Play
Store do similar things with Python and other languages.

Many apps also use this method as a way to get around GPL'd code by
distributing the GPL executable as a separate runnable application inside the
.apk (.zip) file which allows their app to be closed source while containing
GPL code.

~~~
pjmlp
> You didn't read his post to the end - you can include the Go binary into
> your normal Android app and then manually execute it.

Yep, you are right, as I have seen too many of these _workarounds_.

And what is the benefit? Bending ourselves just not to touch Java?!

I rather be productive with the _officially supported_ tools.

~~~
RyanZAG
I wouldn't confuse productive with officially supported - sometimes an
unofficially supported tool can be far more productive.

I agree completely with _productive_ though. Anybody choosing a language for
any reason but the quality of the output is just wasting their own time.
Nobody really cares what language you used at the end of the day, only what
you produce with it.

~~~
ithkuil
sometimes its just the fun. If I could write android apps in Go I would play
with it, and perhaps I would get some ideas about what to build on mobile
platforms.

------
mikhailt
I'm not sure why Google hasn't adopted Go as another supported language to
develop on Android. It seems naturally and would expand the usage of the
language.

~~~
ancarda
Go 1.3 is going to target android/arm:
[http://talks.golang.org/2014/go1.3.slide#12](http://talks.golang.org/2014/go1.3.slide#12).
I'm not sure if this will lead to a full blown SDK for Android.

~~~
aray
Android runs on more than just arm -- anything supported by the platform needs
to support MIPS and x86 as well.

~~~
yebyen
It does have support, but I've seen exactly one MIPS droid (a budget tablet
called a 'Cruz' that had great battery life and terrible performance) and zero
x86 androids (other than ones I put together for myself from android-x86.org).

So, I wouldn't say it needs to support these platforms. Just that not
supporting them would be a glaring omission.

------
DominikR
Using the NDK is already such a pain in the ass (we are using pjsip in some of
our apps) that I couldn't imagine why I would want to switch from C to Go,
which isn't even officially supported.

And you have to consider that soon everyone will switch to the Gradle build
system, which adds amazing possibilities, but also adds a lot of complexity
with build types and product flavors on top of the existing complexity with
the NDK.

------
d0ugie
Hey Microsoft, if you want to blow my mind and have a good chuckle, implement
Go into the Windows Phone NDK before Google does with Android's.

~~~
camus2
Why would Microsoft in their right mind do that? unless you port go to the
CLR,it's not going to happen.

------
habosa
This is awesome, one of those posts that reminds me why I read HN so much.

I'm an Android developer (they exist!) and I'll definitely try this out in my
next app, just for fun. Anyone have any ideas for something I could do with
this that I can't do, or do easily anyway, with a regular Java Android app?

------
dottrap
Is there a way to build your Go stuff as a real, embeddable library and then
call into it from C (via the NDK)?

I think this would be a more natural way of doing it, and also be potentially
more reusable on other platforms like iOS (which forbid launching processes).

I would be interested in writing a simple HTTP server for my app in Go, and be
able to invoke it (start, stop, etc) through a simple C-API. Then I could
write the rest of the GUI in the native platform language (Java for Android,
Objective-C for iOS).

~~~
RyanZAG
I don't believe this would be possible as Go requires a runtime environment
and garbage collection. If you called into a Go library through a function,
you would need to manually set up the runtime environment and garbage
collection before hand (and manage it).

I think you'd be happier just using sockets to communicate with your Go
process. I've done something similar before and it works well.

~~~
dottrap
So many languages allow doing this. Lua and Tcl are famous for this, but many
other languages/runtimes also can do this, Python, Ruby, Javascript, C#, Java.
They have a formal C API you can call through and define some memory
management policy you need to conform to to interact with the garbage
collector. This is pretty common stuff, albeit that some languages are much
harder to embed than others.

As I said, spawning processes and IPC isn't an option on all platforms.

Are you sure Go doesn't have this ability?

~~~
icebraining
You can call Go from C, but the process main entry point must still be Go's,
since that's the only way to launch its runtime. So technically you could
embed it, but then you wouldn't be able to do any allocations or running
goroutines.

------
kashif
Dart is what is coming to Android with ART eventually - not Go.

~~~
ahomescu1
Dart has nothing to do with ART, AFAIK. ART is an installation-time compiler
for Dalvik binaries (essentially an AOT compiler for Java).

------
higherpurpose
Would be nice if they started adding support for Go in Android 5.0, which
won't be out until the end of the year at the very least.

