deleted by creator

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!

Hello, and thank you for taking the time to compose this response.

I think that I may have conflated the choice of language with the choice of distribution. I believe the choice of language is independent of the choice to distribute apps as native or not, for at least Java because Java has solutions for AOT compilation not the least of which was actually used before in Android 5 according to another response, and it was used prior to Android 7 according to this resource.

For the sake of discussion, I propose that this existing AOT compiler for Android Java applications (used today in the hybrid solution) be run in its entirety on a server instead of on the user devices. I don’t see a motivating reason to have the compiler on every user device to include a complex profile-guided optimization framework and hybrid JIT compiler (described in my third link in the original post) when we could ship the finished code and be done with it.

The benefit would be lower maintenance of the Android platform through a simpler design. (This benefit might shake out, but I get to that later.)

The migration process would consist of doing nothing for the typical app developer making this change quite cheap. The same languages would be supported as they are now. Indeed, this transition has already happened before and shows that this approach works, except with the build process happening on the device in earlier Android versions. I don’t understand why Google did not go a step further and ship the binaries, instead choosing to take a step back and ship a JIT compiler with the AOT compiler. Why ship the intermediate bytecode representation and insist on a complex on-device build and optimization runtime?

From the responses that I have received so far, I think the true answer as to why distribution isn’t native is likely composed of a combination of the following factors:

• Android’s heritage and if it ain’t broke, don’t fix it mindset (very respectable IMHO).
• Android practically supports more platforms than arm64 even if not officially stated, such as Chromebooks and some x86 tablets. Shipping native would make this cross-arch support a lot more complicated.
• Loose coupling between hardware and software platforms as a good design decision.
• JIT performance can actually exceed AOT because more information is available at runtime.
• Backwards compatibility is very important to Android, and the impacts of not shipping bytecode to these old versions could be profound or practically impossible depending on how far back we wish to consider.

I’m sure that I’m making further assumptions, and surely there are oddball apps out there that really depend on having dynamic optimization to be performant, but I suspect these apps are in the minority. At a glance, the current solution seems too complicated, but I think understanding the history of the platform and the selection of devices that are supported today mostly answers my original question. Briefly, arm64 is absolutely not the end of the story even if it’s listed as the supported CPU architecture, and officially committing to just one now and forever could come home to roost.

Thank you; I will definitely add this to my reading list.

Thank you for the insight, however, I think that my question is somewhat different because I’m interested in the implementation choice rather than the language choice. To answer your question, I don’t think Android should switch to C/C++. Instead, I don’t understand why Android goes to such great lengths to avoid compiling whatever language is in use in advance. Naively from the outside looking in it appears this would greatly simplify the platform.

For example, I think it would be an improvement to use Java but compile the whole thing to a native image in the cloud and distribute the compiled binaries. We already have Java AOT capabilities in Android, therefore this appears to be technically feasible. Only one ISA is targeted officially. It’s not a great academic leap to think apps could be built off the phone instead to avoid the complex optimization problems.

I am ignoring Chromebooks a bit. I did not know that you could run Android apps on that platform and didn’t think to consider it because I didn’t see x86 listed on Wikipedia as an officially supported architecture.

The purpose is backward and forward compatibility respectively.

The minimum version is the easiest to explain: any older, and your app just won’t run. Don’t even try. I (app) don’t have the compatibility code to work with you if you are older than my minimum version because I didn’t choose to include it, and you (Android) don’t know the changes that were made in the future platform versions, so you can’t help me.

Target version is a little more complex. This is the version of the API that I am designed to run with. You can use this information to set compatibility parameters for forward compatibility. For example, if I try to use API that doesn’t exist in your version or that would have had different behavior, you would know what I’m expecting because I declared to you what it was designed for at the time. This allows the system to tolerate your outdatedness better.

However, that compatibility feature sometimes leads to security issues because the new API tends to be more restricted or improved in ways that enhance security and privacy, hence the argument why there should be a minimum target version to express that you cannot use the less secure API even for the sake of compatibility.