5 ms·

"Go 1.4 can build binaries for ARM processors running the Android operating system. It can also build a .so library that can be loaded by an Android application

"Go 1.4 can build binaries for ARM processors running the Android operating system. It can also build a .so library that can be loaded by an Android application using the supporting packages in the go.mobile repository." http://golang.org/s/go14android http://golang.org/s/go14android

Igglyboo 12y ago
These aren't actual APKs right? I'm assuming this is an actual binary that would get called by an FFI from java land.
- giaour 12y ago
  You're correct; these aren't APKs. I saw the lead dev present the project at a meetup and it appears that they're targeting games and apps developed using the Android NDK rather than standard Android Java apps.
  - melling 12y ago
    How much of the Android API can you access from the NDK? My understanding is that it's for OpenGL and building regular apps isn't something you want to do.
    - giaour 12y ago
      Not much. The presentation I saw positioned Go as an alternative to C++, not Java.
personZ 12y ago
Worth noting that Go has been able to generate Android-compatible binaries for some time -- Linux ARM binaries -- however they are executables, not libraries. Still possibly usable, but more awkwardly. So now they added the ability to generate libraries. Which is interesting because, to my knowledge, they still don't support building libraries on any other platform. It would be useful.
deleted 12y ago
[deleted]
mwsherman 12y ago
I just saw David Crawshaw do a demo of a “full Go” program on Android, a 3D gopher rendered and rotatable by touch. I don’t claim to understand the details but, if I understand correctly, Go was handling the whole thing – touch events and OpenGL – without depending on interop with Java APIs.
- xkarga00 12y ago
  Can you give a bit more info about that 'happening'?
- pjmlp 12y ago
  > without depending on interop with Java APIs. This is impossible, unless the device was rooted. NDK code can only produce shared objects, which are loaded into the Java application processes. The so called Native Activity is just a Java wrapper with a pre-defined set of methods, like touch events that map into a set of pre-defined export symbols. The so called native activities run on their own thread and get the Java events, like touch, over an UNIX domain socket. 3D graphics programming is one of the few blessed NDK APIs. Even 2D is not accessible to the NDK in a developer friendly way, except for a bare-bones framebuffer, even though Android UI makes use of SKIA. Outside 3D graphics, sound and partial POSIX support there isn't that much available in the NDK world without interop to Java APIs (sensors are actually JNI wrappers). It will be nice to have Go available, but most likely the Android team will keep the same cage for Go code.

Igglyboo 12y ago

These aren't actual APKs right? I'm assuming this is an actual binary that would get called by an FFI from java land.

giaour 12y ago
You're correct; these aren't APKs. I saw the lead dev present the project at a meetup and it appears that they're targeting games and apps developed using the Android NDK rather than standard Android Java apps.
- melling 12y ago
  How much of the Android API can you access from the NDK? My understanding is that it's for OpenGL and building regular apps isn't something you want to do.
  - giaour 12y ago
    Not much. The presentation I saw positioned Go as an alternative to C++, not Java.

personZ 12y ago

Worth noting that Go has been able to generate Android-compatible binaries for some time -- Linux ARM binaries -- however they are executables, not libraries. Still possibly usable, but more awkwardly. So now they added the ability to generate libraries. Which is interesting because, to my knowledge, they still don't support building libraries on any other platform. It would be useful.

deleted 12y ago

[deleted]

mwsherman 12y ago

I just saw David Crawshaw do a demo of a “full Go” program on Android, a 3D gopher rendered and rotatable by touch. I don’t claim to understand the details but, if I understand correctly, Go was handling the whole thing – touch events and OpenGL – without depending on interop with Java APIs.

xkarga00 12y ago
Can you give a bit more info about that 'happening'?
pjmlp 12y ago
> without depending on interop with Java APIs. This is impossible, unless the device was rooted. NDK code can only produce shared objects, which are loaded into the Java application processes. The so called Native Activity is just a Java wrapper with a pre-defined set of methods, like touch events that map into a set of pre-defined export symbols. The so called native activities run on their own thread and get the Java events, like touch, over an UNIX domain socket. 3D graphics programming is one of the few blessed NDK APIs. Even 2D is not accessible to the NDK in a developer friendly way, except for a bare-bones framebuffer, even though Android UI makes use of SKIA. Outside 3D graphics, sound and partial POSIX support there isn't that much available in the NDK world without interop to Java APIs (sensors are actually JNI wrappers). It will be nice to have Go available, but most likely the Android team will keep the same cage for Go code.