proposal: android support

[David Crawshaw]

http://golang.org/s/go14android

Comments welcome on this thread. Thank you.

[Andrew Gerrand]

LGTM

[Dave Cheney]

LGTM. brb, gotta buy a Nexus 5.

On Sat, Jun 21, 2014 at 9:25 AM, David Crawshaw <craw...@golang.org> wrote:
> http://golang.org/s/go14android
>
> Comments welcome on this thread. Thank you.
>

> --
> You received this message because you are subscribed to the Google Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[chrs...@gmail.com]

This sounds fantastic.

I previously tried writing a simple web server (targeting ARM) and dropped it on an Android device, which worked fine - but I was unsure as to the best way to actually package it as an application. Having full Android support built in would be much, much easier.

just for reference, the easiest way I've found to run Go on Android is to something like Dennis Forbes outlined here: http://dennisforbes.ca/index.php/2014/03/19/go-golang-and-android/

[Jeromy Johnson]

LGTM, this would be awesome. 

On Friday, June 20, 2014 4:25:50 PM UTC-7, David Crawshaw wrote:

[dyso...@gmail.com]

Are you aiming for full-blown support (like Java) or something akin to C/C++ on the NDK? Should I expect any announcements regarding this on Google I/O?

Go would make for a great competitor to Swift. 

[Andrew Gerrand]

On 21 June 2014 11:26, <dyso...@gmail.com> wrote:

Are you aiming for full-blown support (like Java) or something akin to C/C++ on the NDK? Should I expect any announcements regarding this on Google I/O?

Read the doc. It is one page.

[Stefano Casillo]

On Saturday, 21 June 2014 07:25:50 UTC+8, David Crawshaw wrote:

http://golang.org/s/go14android

yess!!! Please, please, pretty please.. just do it, this is going to change everything in how Go is used.

This has to be the best news since I have been following the project.

 

[cyber...@gmail.com]

I use Go on both x86 and ARM - so my questions are (pardon me if I don't understand Android internals sufficiently well)

1.  Why can't the Go code generator output Dalvik VM code ?

2.  Shouldn't the support be for ART, AFAIK it is becoming the new VM for Android

I would much rather code in Go than Java.  Other than that I would prefer to see similar access to Application Framework and Libraries.

NDK level access is a separate issue.  

Which suggests to me that there are two broad use cases:

(a)  For folks who'd rather code in Go than C / C++; and

(b)  Folks who would rather code in Go than Java.

I think that the cleanest approach would be to treat Android as two different targets for each of these use cases.

[a...@laher.net.nz]

I'd imagine there will be a massive uptake in Go as a result of this project - there must be gazillions of app developers who'd rather write games with Go instead of C.

Do you think there will be any particular limitations on NDK features which would be available to Go, as opposed to C? 

I guess there's potentially a slight performance hit, but anything beyond that?

Cheers, exciting news. 

[Elias Naur]

No comments, just a simple: yay!

- elias

[andrea...@alcacoop.it]

Oh that's a good news!

[Vincenzo Prignano]

It's one good news after another, NaCl and Android NDK. Thanks to everyone in Google Go Team for the fantastic work.

[Aram Hăvărneanu]

Sounds good, but where are the implementation details?

--
Aram Hăvărneanu

[beancin...@gmail.com]

Awesome, looking forward to this,

Mo

[Daniel Bryan]

I have a question that might reveal my ignorance of Android more than anything.

> Dalvik-loadable .so files will be produced using the external linker provided in the Android NDK.

Does this imply that a separate effort will be needed for ART support? Or are they equivalent?

[David Crawshaw]

I haven't tried running with ART builds yet, but my understanding is
it can dlopen the same shared library.

[小菜]

I hope golang fully supports the andorid platform, like the swift support for the IOS platform, I very hate Java verbose syntax, because didn't like Java, I always do not want to learn Android development technology. If golang does well on the Android platform, he will achieve rapid development and great success. Golang is my most loved programming language!

在 2014年6月21日星期六UTC+8上午7时25分50秒，David Crawshaw写道：

[小菜]

This is really a good news, I look forward to a long time. I look forward to the future can be very easy to use golang to develop Android program!

I can't visit http://golang.org/s/go14android , I am in China.

There are many many gophers in China who have difficulties accessing the official golang web site which is banned from inside China by the notorious GFW. 

-_-

在 2014年6月21日星期六UTC+8上午7时25分50秒，David Crawshaw写道：

[Stephen Gutekanst]

LGTM so much. I really look forward to adding Android support to the Azul3D game engine when Go 1.4 is out.

Stephen

On Friday, June 20, 2014 4:25:50 PM UTC-7, David Crawshaw wrote:

[Leslie Zhai]

Hi David,

Where is the Android-support Committed Changes? I can not find it via https://code.google.com/p/go/source/list

Thanks a lot!

[Gour]

David Crawshaw <craw...@golang.org>
writes:

> http://golang.org/s/go14android
>
> Comments welcome on this thread. Thank you.

Everything which does not require Java for Android LGTM.

However, being more interested for the desktop apps (go-qml), what do
you think about using Qt (bindings) for Andorid?


Sincerely,
Gour

--
The work of a man who is unattached to the modes of material
nature and who is fully situated in transcendental knowledge
merges entirely into transcendence.

[Leslie Zhai]

Go QML is cool, but there is QtQuick2 QML right now since Qt 5.3 released ;) how about Go QML status?

[David Crawshaw]

On Mon, Jun 23, 2014 at 2:23 AM, Gour <go...@atmarama.net> wrote:
> David Crawshaw <craw...@golang.org>
> writes:
>
>> http://golang.org/s/go14android
>>
>> Comments welcome on this thread. Thank you.
>
> Everything which does not require Java for Android LGTM.
>
> However, being more interested for the desktop apps (go-qml), what do
> you think about using Qt (bindings) for Andorid?

I hear good things about QML, but UI toolkits are beyond the scope of
this project.

>
> Sincerely,
> Gour
>
> --
> The work of a man who is unattached to the modes of material
> nature and who is fully situated in transcendental knowledge
> merges entirely into transcendence.
>

[Gustavo Niemeyer]

Very nice, thanks for organizing this, David. I'm looking forward to
playing with this too.

By the way, does it make sense to call the repository go.android
rather than go.mobile? It looks like all the components there are
very specific to Android.

--

gustavo @ http://niemeyer.net

[Brad Fitzpatrick]

Don't rule out Windows Phone and Tizen support in the future.

[David Crawshaw]

On Mon, Jun 23, 2014 at 12:17 PM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> Very nice, thanks for organizing this, David. I'm looking forward to
> playing with this too.
>
> By the way, does it make sense to call the repository go.android
> rather than go.mobile? It looks like all the components there are
> very specific to Android.

My intention, after Android is working, is to explore iOS. As we are
avoiding the platform UI toolkits, the Go packages for app management,
touch events, drawing, etc should be common to both.

I would call it go.app if it didn't overlap so much with app engine.

[Gustavo Niemeyer]

It works in the Ubuntu Phone today, too. The point is just that it
looks like all the proposed content for the repository is not
applicable to anything but Android. If that's not the case and I'm
mistaken, then surely that's great.

[Gustavo Niemeyer]

The document reads clearly like avoiding the platform-dependent
Java-based UI is a consequence of the technical difficulty in doing
so, rather than a design decision, and that the goal is wrapping and
supporting the Android NDK specifically, rather than focusing on
multi-platform APIs.

If that's not the case, I suggest making the high-level plan more clear.

[David Crawshaw]

It is. Multi-platform APIs are a secondary concern, that's why it is
not strongly mentioned. It is however, an entirely possible outcome
due to the decisions being made.

Being careful as I go, like naming the repository go.mobile instead of
go.android is not something I want to call too much attention to. If I
err, I want to err on the side of supporting Android well.

[Gustavo Niemeyer]

That's what I thought, and why I suggested naming it go.android.. it's
really not a multi-platform effort from the looks of it. But I won't
bikeshed any more on it than I already did.

Thanks for pushing this forward. Looking forward to having it available.

[Tony Constantinides]

Hi,

 Have you guys considered calling Java APIs on Android using RPC using Google Protocol buffers?

The use of this ope source project is of interest

https://code.google.com/p/protobuf-rpc-pro/

The idea is that a Google Go client can send messages using its Google Protocol Buffers packages which can translated to RPC calls (which are ran salted to Java Android Calls))

to a Java Activity on Android. Its bi-directional so the java code can call back the Go Client.

Done this way, the Go team does not need to support the whole Java Android API as users can define future message that do, but provides

a Go packages that allows communication with an Java Android App using the efficient Google protocol Buffers over RCP as a transport and communication method.

I can provide a library that receives the RCP messages and forwards them to Java API calls on Android.

You thoughts?

 

On Friday, June 20, 2014 4:25:50 PM UTC-7, David Crawshaw wrote:

[Stephen Gutekanst]

Tony,

I don't think RPC is appropriate. Through CGO we'll have access to the Java C API (JNI) and can interact bidirectionally with Java, creating instances of classes, invoking methods, etc, from Go. We can even do callbacks such that Java can call Go functions. More appropriately this method wouldn't have the overhead of RPC.

Stephen

[Tony Constantinides]

Stephen,

 That great, I always thought CGO will rely on Java JNI which seems to support java calling C and not the other way around.  How would resources(bitmaps. layout, fonts, strings in XML files)  be handled as Android has a strict directory structure? How do we handled android security permissions in the Android manifest file? Do we just manually code this on the native side and use Go like a scripting language over Android API? 

[Andrea Fazzi]

Hi Stephen, you may be interested to look at how I handled some of the issues related to resources management in mandala:

https://github.com/remogatto/mandala

Cheers,

Andrea

 

--

[Stephen Gutekanst]

Wikipedia mentions that JNI is bidirectional (Java -> C; C -> Java) with CGO it only implies that Go could call Java, and Java could call Go. Of course a nice interface to JNI (perhaps using some, a lot of?, reflection) would probably be preferred. As far as permissions I imagine you would still have to specify them in the manifest file just as you normally would.

The main point of this proposal is that it would let you compile Go to .so files -- which on Android could normally only be written in C or C++ through the NDK. All standard points of the NDK still remain (needing a simple Java application to load the .so file, needing to use JNI to call any Android Java API, etc).

About resources: I don't really know, I haven't looked into resource management on Android in-depth and don't know what problems arise. From briefly looking at Andrea's mandala project below it looks like there are certainly some issues to tackle (resources live in the .apk file and must be unpacked, etc).

Stephen

[John Vilsack]

This will have a dramatic impact on the adoption rate of Go in the wild.  I cannot wait!