Android

The Androids book by Chet Haase provides a good look at the early history and design decisions of the platform and how they came to be made.

At the time there was a debate inside the team over what language their app development framework should use, with native C++ and Java being the two main options (I think there might have been another option or two, I can't recall). In the end Java won out, and from memory one of the main reasons was to make it easier to make apps and not need to think about the lower level parts of the platform, i.e. the platform takes on the complexity internally in order to lower the barrier to entry for app developers. The idea being that a lower barrier to entry would result in more apps being developed for the platform. For a brand new platform that lives and dies by the apps available for it, that's a pretty sensible trade-off.

And yes, Android has a lot of vestigial remnants of the past, the Android framework team has been very particular about maintaining as much backwards compatibility as possible within the framework.

First of all, since the very early days Android has always allowed apps to make use of native code using the "NDK", and in fact most games and most apps that do any sort of AI, image processing, or anything else complex like that make heavy use of native code already, for performance reasons.

Keep in mind that the decision to base Android apps around Java was made back in 2003 when Android was founded. Some of the reasons they picked Java were:

• It's one of the most widely known languages by developers
• It's hard to write code in languages like C and C++ without introducing memory bugs and security bugs. Using a higher-level language makes those bugs far less common.
• It's portable - you note that Android only supports arm64 now, but at the time it was arm32, and Android has actually always had some level of support for x86 - you can run the emulator for x86, and some x86 Android devices exist. Using a bytecode language means Android is future-proof
• It's not limited to just Java - the JVM has a rich ecosystem of languages that developers can use

Now 20 years later I think it's worked out pretty well. It's hard to imagine picking a different language would have worked out better. Java is still just as popular as ever, and Android developers can take advantage of all of the Java tools from any other platform or application.

Apple's original option for iOS apps was just Objective-C, which is higher-performance, but overall it's a more obscure, difficult to use language. Developers adopted it despite Obj-C, not because of it. Apple had to invent Swift to provide a more modern alternative, because Obj-C is basically not used anywhere else and it felt very ancient. While Swift is a pretty great language, it's still somewhat obscure, only used for iOS and Mac apps - while Java and JVM languages are used everywhere.

Anyway, let's say that Android really did want to switch, for some reason. I'm not sure why you think switching to compiled code would be less complex. How would all of the millions of existing Android apps migrate? What native languages would be supported? It'd be a huge transition for dubious benefits.

As it is, Android is extremely flexible. While the official APIs require a JVM language, because of the NDK you can basically write Android apps in whatever language you want. People have built frameworks enabling you to build Android apps in nearly every language under the sun.

I think there are a couple of things to consider. Number one is that Android at the very beginning never was designed for large touchscreen phones, rather it was supposed to be a small portable Software Stack that would run on digital cameras where Java would be good enough.

Another historic thing that must have played into this is that Android was fighting an uphill battle. At the time iOS, PalmOS, BlackberryOS, Symbian and Windows Mobile all were shipping units. So I think they knew they had to keep the barrier of entry for creating Apps as low as possible and Java was (and still is) an incredible easy to understand language with a very gentle learning curve. Plus it was one of the most widley used language with robust tooling.

Also for implementation - Android actually was AOT compiling Apps during installation during the Android 5 and 6 days however starting with 7 they went away from that by using a hybrid approach. Basically if you download an App and launch it the first time, it would run in JIT mode and collect data and than compile and optimize cirtical parts while the phone is idle and charging. There even is an adb command (adb shell cmd package compile -m speed -f my-package) to manually compile apps. But I have played around with this a lot, trust me, and I can't notice a difference.

Also more generally I think that Android Apps being mostly made up of intermediate bytecode instead of raw CPU instructions is overall a massive benefit for security and incredible futureproofing. It allows for things like x64 Chromebooks and Asus Zenfones with Intel Atom SoCs (yes that was a thing) and would make a transition to a new ISA like RiscV somewhat managable I think. Also I don't think Java and its performance overhead matters - usually its badly coded Apps or these god awful wrapped webview "apps" that cause issues. Simple as that. If you today compare a Nexus 5 and an iPhone 5S, the Nexus 5 is faster 8/10 times, and that despite having a slower CPU and the whole java stack.

X86 android devices exist, wether they are officially supported or not, I don't know. C/C++ is prone to memory corruption vulnerabilities, using a higher level language like Java nearly entirely cuts out that class of vulnerabilities. You mention the complexity of Java, but Java is just a lot easier to write than c/c++. So I ask you, why would android switch to the complexity of c/c++ for applications where Java is sufficient?

There are many benefits. For example great exception handling. We're paying very little performance cost for having the conveniences of a managed runtime. Let me flip it, we don't want unmanaged runtimes, we are forced to run in native, because we need the absolute highest performance in some cases. If the hardware could understand Java bytecode and provide all other JVM facilities, that would have been spectacular. Unfortunately that would be very expensive and pointless as we've demonstrated over the decades. If anything we're moving towards reduced instruction set chips - ARM, RISC-V. And so in many ways the complexity you see is well understood by the folks that have to understand it, it's well managed, it's worth it and it's not at all a performance problem worth tackling.