Go would require building a whole new set of APIs and massive work since Go does not interop with Java.
Kotlin, however, interops with Java nicely since it compiles to jvm bytecode. So there's no new APIs to build and no transition performance costs.
Although that said you can actually use Go on Android ( https://github.com/golang/go/wiki/Mobile ) but since Go is native code you're stuck with Android's NDK or dealing with JNI and the performance costs of that.
1) interoperability between existing ecosystem and APIs
2) development environment support.
In case of Kotlin Google had to do nothing: Kotlin is 100% interoperable with existing Java code and libraries, including Android APIs; as for the development environment, JetBrains (the company behind Intellij IDEA and Kotlin itself) provides the same level of development experience for Kotlin as for Java, which means that Android Studio gets the very same nice features for Kotlin.
Now, how would they get the same with Go? For interoperability they would need to either generate tens of thousands of bindings for existing APIs and provide a convenient way to include compiled Go binary as a static library. It is highly doubtful they actually can do, since they have been having troubles to do it for C or C++ code for a very long time. Or as alternative they can improve their support for native code, which then can be used as a base for interoperation with Go code; however it is still considerably less pleasant way to do things than in case of Java + Kotlin.
Now, as for the development environment, Google will have to basically create yet another IDE on top of Android Studio to support Go; they might take an existing plugin (which is not that great, compared to Kotlin support in AS/Intellij), but it means that they would have to collaborate in development on it, which in case of Google takes too much time. Another indicator of how difficult for them implement at least someway decent support for another language on their own is situation with native code - it's being in development for like 3 years, and still is highly unusable.
Java, Python and C++ are the actual workhorse languages at Google.
Go doesn't seem to be used that much other than a few known projects like the stuff that got re-written for YouTube or the download server.
You see this when new Web APIs are released, usually Go isn't part of the preview SDKs, and on Android all the work done on Go mobile has been done by people on the Go team or from the community at large.
Dart runs the AdSense code, because the AdSense team rescued the Dart team when the decision came to them stop being part of Chrome development efforts.
Regarding Go at Google, if you have better sources of information to share with those living outside Mountain View, it would be very helpful.
I think Go needs and does very little marketing inside or outside Google. Despite what Go baiters say about its usage and lack of features like generics etc, it is now reasonably successful in industry. Unlike Dart they do not need to do constant hammering that a huge/critical application X inside Google is written in Go.
The story as I heard/read somewhere I cannot at this moment recall (InfoQ, conference networking, Podcast, blog,...), goes like this.
Many of the important devs on the V8 team, like Gilad Bracha, were getting tired of working on the project and started to look elsewhere for a career change.
Allowing them to create their own vision what a JavaScript replacement might look like (aka Dart) motivated them to stay on the team and at Google.
When the Chrome team decided that they wouldn't be merging the Dart VM into Chrome at all and would rather focus on JavaScript, including their efforts for adding type annotations to JavaScript, the Dart team was going to be assigned new tasks.
However in the meantime the AdSense team had started using Dart and they enjoyed using it quite a lot, so a decision was made to move the Dart team away from Chrome into supporting the AdSense team as main role.
If this is not true, I would welcome any Googler that knows better, to correct me.
it's fair to say that Go is actually used more outside Google than inside Google. And to be fair I don't see Java or C++ specialists moving to Go when they'll loose a lot of their tooling and language features in the process. I like my enums explicit and my generics ,personally.
Total guess, but maybe they see the actual usage numbers of developers that use Go? AND that number is not very high. Also, how well does Go translate into Android apps? Just a guess.
I like writing Go, and it's my go to (pun intended) for writing web API's. Building a framework around it for Android apps would be a mighty task. Kotlin makes more sense considering it's connection with the JVM.
I'll keep writing Java to build Android apps though. I'm sure it's "more fun" or whatever, but Java's worked just fine for me thus far. I'm used to the verbosity, and have no desire to start from scratch with another language. If some huge benefits were presented, I would. But, I'm failing to see any.
You can mix Kotlin and Java in the same project easily. I have a project where we have a bit of both. All the new code is written in Kotlin and some older features are converted to Kotlin when we feel like it.
I kind of gave up on Java and Android a few years ago and picked up Python. I have given Go a whirl... but it doesn't tick all the boxes for me. I really, really want to build apps for all the platforms with one language and awesome GUI's.
I think one of the things that get people excited about Go on desktop is it is one of the few well supported GC langs that compiles to an exe. There isn't anything else super compelling about it.
On android, everything gets AOT compiled on install already.
Kotlin, however, interops with Java nicely since it compiles to jvm bytecode. So there's no new APIs to build and no transition performance costs.
Although that said you can actually use Go on Android ( https://github.com/golang/go/wiki/Mobile ) but since Go is native code you're stuck with Android's NDK or dealing with JNI and the performance costs of that.