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?

  • MajesticNubbin@lemmy.worldEnglish
    4·
    1 year ago

    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.

  • minorninth@lemmy.worldEnglish
    2·
    1 year ago

    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.