But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB.
If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes.
Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.
And not for any actual good reasons.
And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.
In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM.
Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern.
I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice.
So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly.
C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix.
Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).
I don't think that failure occurred due to anything other than mismanagement.
The Win8 cycle produced many things:
* An OS for desktop PCs
* Under the hood improvements vs. Win7, like faster boot
* A tablet UI
* A tablet
* A port of NT to ARM
* A tablet based on the above which could only run code signed by Microsoft
* An app store with a new set of APIs that nobody cares about
Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.
I want write-once-run-everywhere.
It's more true that GUI-heavy apps can be harder to get right, cross-platform. But it's a no-brainer for game development.
None of this applies to regular app though.
Sadly.. still programming in Java (most of the time).. but one step at a time I guess