<p>The android-go project aims to provide a platform (namely an SDK) for writing native Android apps in Go programming language. Today it got JNI calls support, so users can now use Android SDK inside their Go programs.</p>
<p>This example shows how to toggle the native Android keyboard using JNI introspection:
<a href="https://github.com/xlab/android-go/blob/master/android/jni_util.go">https://github.com/xlab/android-go/blob/master/android/jni_util.go</a></p>
<p>Demo (with Nuklear GUI): <a href="https://goo.gl/photos/TFkYFKC48Re6RnbUA">https://goo.gl/photos/TFkYFKC48Re6RnbUA</a></p>
<p>Many other SDK classes can be used, facilitating access to native platform and hardware features.</p>
<hr/>**评论：**<br/><br/>throwlikepollock: <pre><p>For those "in the know" about Go & Android, what is the current "best" method to create 100% Go Android apps? Ideally, i want Native UI components too, not custom drawn OpenGL stuff.</p></pre>JTandler: <pre><p>What's the difference to go-mobile which supports jni calls, too?</p></pre>xlab_is: <pre><p><code>go-mobile</code> has another goals and priorities. This project appeared to fill the niche and do things differently where go-mobile doesn't help, for example, go-mobile is targeted for mobile developers who want to play with Go.</p>
<p><code>android-go</code> on the other side is a project for Go developers who want to do Android development without touching C or Java code.</p>
<blockquote>
<p>which supports jni calls, too?</p>
</blockquote>
<p>No it doesn't, they generate JNI code to do calls from Java to Go, like I said that's a tool for Java developers.
To do calls from Go to Android SDK, they write C shims like this:
<a href="https://github.com/golang/mobile/blob/master/exp/audio/al/al_android.go#L20-L23">https://github.com/golang/mobile/blob/master/exp/audio/al/al_android.go#L20-L23</a></p></pre>JTandler: <pre><p>What I meant was "reverse bindings" (see <a href="https://godoc.org/golang.org/x/mobile/cmd/gobind" rel="nofollow">https://godoc.org/golang.org/x/mobile/cmd/gobind</a> ) which looks like calls from go to java/coca for me. Am I wrong with that?</p></pre>xlab_is: <pre><p>Poking around links from "reverse bindings" doc section I stumbled upon these 2 beautiful threads:</p>
<ul>
<li><a href="https://github.com/golang/go/issues/10588" rel="nofollow">https://github.com/golang/go/issues/10588</a></li>
<li><a href="https://github.com/syncthing/syncthing-android/issues/29" rel="nofollow">https://github.com/syncthing/syncthing-android/issues/29</a></li>
</ul>
<p>This perfectly shows the issue I was trying to avoid here.</p></pre>xlab_is: <pre><p>Looks cool, however that's a DSL (domain-specific language) kind of language constructions here that have no sense without invoking <code>go-bind</code> generator that will generate Java code and C shims that will setup a bridge between Java and Go. No JNI calls from Go.</p>
<p>My approach allows to access SDK without code generation, in a very direct and explicit way, using Go.
I'm not stating that it's better, it's just different and I like it to be that way.</p></pre>JTandler: <pre><p>Ok, I see what you meant. Thanks for the information.</p></pre>JTandler: <pre><p>Found it:
<a href="https://github.com/xlab/android-go#on-existing-tools-or-why-not-just-use-gomobile" rel="nofollow">https://github.com/xlab/android-go#on-existing-tools-or-why-not-just-use-gomobile</a></p></pre>dobegor: <pre><p>This is awesome. Maybe someone will create an easy to use SDK wrapper.</p>
<p>/offtop Pixel XL Black 128 is still out of stock from the end of November. Argh.</p></pre>ericzhill: <pre><p>I got in on the preorder and the Pixel XL 128 I'm typing this on is fantastic. /bragger</p></pre>dobegor: <pre><p>I've made a usual mistake 'oh seems nice I'll wait for some reviews'.
Enjoy your device :)</p>
<p>OP, sorry for off-topic conversation.</p></pre>xlab_is: <pre><p>I hope this wrapper would be generated automatically for entire SDK using class definitions, would be amazingly useful to have autocomplete on these.</p></pre>
