[1]: https://github.com/xamarin/XobotOS [2]: https://blog.xamarin.com/android-in-c-sharp/
They had motion sensor support in J2ME devices that they used mostly for fishing/golf games circa 2003-2004 (don't hold me at the dates my memory is the gray equivalent of Swiss cheese).
Anyway, J2ME had a lot of levels CDC was pretty much Android equivalent but it didn't have GUI API on top of it because Sun disallowed MIDP on top of CDC and didn't offer anything other than AGUI which nobody used... I can go into endless details here but generally, the reason J2ME failed was that it was a tool built in 1999 with a single moderate update in 2004 and nothing else!
It was really amazing to play games like [1] on phones like [2]
[1] http://java.mob.com.de/game/anno_create_a_new_world.html
[2] http://www.siamphone.com/spec/lg/images/kp501/lg_kp501_1.jpg
Has no one in this branch of the thread ever heard of a little thing called Go?
You could also bring up Dart, although Google's apparent commitment (and my own interest) in that is far lower.
Work IS coming along on being able to write full Android apps entirely in other Google-originated languages. You might reasonably ask why they're not pouring dramatically more resources into accelerating that process. I don't know, but I can only speculate that the enormous scale of the existing Android ecosystem makes it risky to send the wrong signal prematurely.
If we're looking at a matter of years before full featured Android apps in pure Go is feasible, then you probably wouldn't want to talk that up TODAY. The perception would be that Java on Android is dead, and major new app development for Android would halt.
Go team is just doing what everyone else does, by making use of the NDK and writing Go wrappers manually on top of JNI calls to the official Android APIs.
So far there have been zero interest from Android team to support anything other than Java. Even the C and C++ support is just to write performance code to be consumed from Java, not to write full blown apps.
The absence of generics and exceptions makes Go a step backward compared to Java. It was also absolutely not designed for Android (its driving design goal was to compile fast).
Dart's type system is also much weaker than Java so it would be a step back as well.
Right now, Google doesn't have any in-house credible alternative language to Java.
Interestingly, Kotlin is growing on Android without Google having anything to do.
Check out the flutter project (http://flutter.io) for a hint of what Dart on Android and iOS looks like.
All that being said, the longer I work with Go, the less I really see its lack of generics as a significant shortcoming. Go simply doesn't emphasize object-orientation to the same degree as idiomatic Java. Given the choice, I'd prefer to have that tool available than not have it. However, I haven't yet personally run across a real-world scenario in which lack of generics was an actual big deal.
I am QUITE comfortable in asserting that Go's error handling exceeds that of Java's, not lags it. The "try-catch" concept is still there (as "panic-recover"), albeit discouraged in many of the cases that an experienced Java developer would want to use it. The convention of having every function return a possible error struct, and the compiler's insistence that you do something with that that returned struct, pushes Go developers into a much more disciplined mindset of approaching exception handling.
The two points above are subjective, of course. Reasonable people could argue them either way. The third response is a bit more objective. Regarding the notion that Go is "absolutely not designed for Android" and its memory constraints, I must point out that neither is Java! As a matter of the Java language's syntactical suitability, the obvious observation is that Java PRE-DATES Android by more than 12 years. Considering the laws of physics and space-time, it was clearly not designed by James Gosling with Google's OS in mind. Secondly, the memory constraints of carrying a built-in garbage collection runtime also apply to Java. The only difference is a matter of maturity, and the level of resources that have gone into developing a custom Java solution for Android. There's no reason why Google couldn't do the some with Go (or almost any other language), and given Go's comparative simplicity it would probably take far less time to get there.
But it doesn't. You can write `ok, _ := Foo()` and poof, the error is ignored.
Java's checked exceptions don't let you get away with this kind of sloppy programming.
It is glaringly obvious in a code review that you have done this. Also, although I'm not personally familiar with any Go tools similar to PMD or Sonar in the Java world... it would be fairly easy to write a static analyzer that could scan code, recognize this pattern, and report on it (along with other code smells) in an automated manner.
Nevertheless, idiomatic Go functions return an error structure, and you must do something with that error structure. There is no ambiguity as to where the error structure came from.
Contrast that with Java's model, which is much more (pardon the expression) catch-all. There is endless debate on how wide or narrow to make your try-catch blocks, when to handle an exception locally vs. throwing it back to the caller, etc.
It is very common to deal with bugs that stem from silently "swallowing" exceptions at an inappropriately low level. It is just as common to see patterns where nearly all methods throw nearly everything without a catch at all... and there's a monster try-catch block at the top level catching the base "Exception" class.
Worst of all, there are entire classes of runtime exceptions which are NOT declared as throwable in the method's signature. The compiler has no means of insisting that you do anything about those, because the compiler doesn't know which ones are possible during a given method call. Go's error handling model is safer and better thought-out in that regard.
When you think about issues stemming from Java's handling of checked vs. unchecked exception types, it makes a lot more sense why Go went in the direction it did. Also, why Go application developers are discouraged from using "panic-recover"... and why Go library developers almost always recover from panics and create error structs for passing back upstream.
Why doesn't Google ditch java ?
Because such a switch would be very costly and there are many more cost effective ways to improve the platform (like for example databinding).
I also doubt that Google would choose a language controlled by Microsoft, they had enough trouble with the java lawsuit..
if the rumors of the merge of Android & ChromeOS are true, maybe this will be accompanied with with a big framework change ? It will depend on how this plan materialize exactly but that would be the right time for that.