More concretely, I’m asking this: why aren’t applications compiled fully to native code before distribution rather than bytecode that runs on some virtual machine or runtime environment?
Implementation details aside, fundamentally, an Android application consists of bytecode, static resources, etc. In the Java world, I understand that the main appeal of having the JVM is to allow for enhanced portability and maybe also improved security. I know Android uses ART, but it remains that the applications are composed of processor-independent bytecode that leads to all this complex design to convert it into runnable code in some efficient manner. See: ART optimizing profiles, JIT compilation, JIT/AOT Hybrid Compilation… that’s a lot of work to support this complex design.
Android only officially supports arm64 currently, so why the extra complexity? Is this a vestigial remnant of the past? If so, with the move up in minimum supported versions, I should think Android should be transitioning to a binary distribution model at a natural point where compatibility is breaking. What benefit is being realized from all this runtime complexity?
I think the main issue is who it’d be simpler for. Let’s say that they switched to AOT compiling. That enables them to “simplify” the way Android works internally.
Who does that actually make things simpler for?
Literally ONE subteam of the Android team at Google. Nobody else.
It wouldn’t make things any simpler for developers. In fact, it’d make things worse because AOT compilation is slower and doesn’t allow things like hot-swapping code while your app is running - something you can do now with Java.
It wouldn’t make things any simpler for OEMs. They don’t have to worry about the Java runtime at all, they just worry about drivers.
It wouldn’t make things any simpler for the other 99% of the Android team that builds new APIs, new drivers, etc.
Basically you’re proposing a radical change that would make the platform worse for almost everyone, just so that one pretty small team at Google that builds the Java runtime portion of Android could make it a little simpler???
You say the current system seems “too complicated”. I agree it’s complex, but for a reason. Actually just about everything in tech is complex if you peek behind the curtain and learn how it works inside. The only difference here is that the code is open so anyone can see how it works. But for the most part these are just hidden details.
I guarantee that if you looked into how video frame compositing on Android works, or how low-latency audio works, or any of a hundred other things, you’d realize they’re incredibly complex too - probably “too complicated” at first. But that complexity is for a reason.
QED, I think this response completely addresses my concerns. I often miss the social aspect of systems that involve people. I can’t think of any further questions.
I reverse native binaries across a few different platforms for a living, but I’m just getting into Android. I will definitely take a look at those systems!