What Android's On-Device Compiler Proves About Runtime Generation, and the Layer It Stops At
Every other paper in this series argues against an industry that compiles in advance. This one has a harder job, because Google does not. Android ships bytecode and compiles machine code on the phone, guided by profiles of how the application is actually used, on billions of devices, every day. That is generation rather than selection, at a scale nothing else in this series can match. The question this paper asks is what it is generating for.
Paper 1 argued that a compiled binary is a prediction about a machine the builder never saw, and that the industry answers this by carrying more of the assumed machine along rather than by deciding later. Paper 2 found a substrate where deciding later is permitted but rationed. Google is the substrate where the argument meets something else entirely: a platform that already decided later, at enormous scale, years ago. Android applications ship as bytecode rather than as machine code, and the Android Runtime compiles that bytecode into native instructions on the device itself, using profiles of how the application is actually being used to decide what is worth compiling. Chrome's engine does the equivalent for JavaScript on every one of those devices and on ChromeOS. This is not a partial or theoretical version of runtime instruction generation. It is the largest deployment of it in the history of computing, and it works.
This paper takes that seriously rather than arguing around it, and then asks the question the achievement invites: what is the runtime generating instructions for. The answer is a program written in a language whose entire design purpose is that the program does not know what machine it is on. The abstraction that makes Android's approach portable across an enormous device population is the same abstraction that prevents the generated code from addressing anything the abstraction does not expose, and the accelerator, the memory topology and the rest of the components are on the far side of that line. The graphics and compute path, meanwhile, was never managed this way at all and reproduces the fixed-commitment problem in its own dialect. The paper argues that Google demonstrates the mechanism and stops one layer above where it pays, positions Essence as a second path beside the managed runtime rather than a replacement for it, and states plainly that no Essence build exists for any Google platform today.
A series arguing that instructions should be decided when the machine is finally present has an obligation to say so when somebody is already doing it. Google is already doing it.
An Android application is not distributed as machine code. It is distributed as bytecode defined against an abstract machine, and the device turns that into native instructions itself. The runtime does not do this blindly or all at once: it observes which methods actually run hot in real use on that specific device, records profiles, and compiles the parts worth compiling, typically while the device is idle and charging. A given application ends up with different compiled code on different phones because different people used it differently. Chrome's engine does the structurally similar thing for JavaScript, on those same phones and across ChromeOS, tiering code up from interpretation to optimized native output based on observed behavior.
Set aside for a moment whether this is the right layer. As an existence proof it is overwhelming. Runtime instruction generation is not exotic, not fragile, and not a research posture. It is the default execution model of the most widely deployed operating system on earth, it has been for over a decade, and the industry's continued insistence that software must be compiled in advance is contradicted daily by the phone in the reader's pocket.
The mechanism deserves description in its own terms, because the detail is what makes the later argument fair rather than dismissive.
The shipped artifact contains bytecode, not instructions for any particular processor. The device holds the compiler. That single decision is the reason a single upload can serve processors that did not exist when the application was written, and it is exactly the decision Paper 1 argued the rest of the industry should have made.
Profile-guided compilation means the runtime is not guessing which paths matter. It watches, records, and compiles accordingly. This is a genuinely stronger position than an ahead-of-time compiler occupies, because the build server can only model expected use while the device can measure actual use, and the two differ more than most software teams would like to admit.
Because compilation is driven by profiles that keep accumulating, the compiled form of an application on a given device is not fixed at install. It changes as usage changes. A commitment that can be revised is categorically different from one that cannot, and this is the property the rest of the industry gave up when it decided the build server was the last place a decision gets made.
Three properties, all of them real, all of them shipping. Any honest account of Android has to start here, and an argument that begins by pretending otherwise deserves the skepticism it would get.
Paper 1 drew a line between generating instructions after inspecting the machine and selecting among instructions built in advance, and called the second one a ceiling, because the best available outcome is bounded by whichever variants somebody thought to build. Google's stack contains both, at different layers, and separating them is what makes the paper's later claim precise.
The runtime, as Section 02 described, genuinely generates. The delivery system does not. Modern Android distribution takes a single upload and serves each device a subset assembled from prebuilt components chosen against a handful of coarse device attributes: the processor architecture family, the screen density bucket, the language. That is selection, and it is a good implementation of selection, but the ceiling Paper 1 described applies exactly as written. A device gets the best of what was prepared. It does not get something made for it.
The distinction matters because the two are frequently discussed as one thing, under headings like "the device gets what it needs." It gets a smaller download than it used to, assembled from parts, and separately it gets code compiled on the device from a portable representation. Only the second is the mechanism this series is about, and conflating them makes Android's real achievement harder to see rather than easier.
Here is the sentence the paper exists for. The runtime generates excellent code for a program that was written not to care what machine it is on.
That is not a criticism of the runtime, which does its job well. It is an observation about what its input was permitted to express. The bytecode's design goal, inherited from a lineage of managed runtimes going back decades, is that the program is insulated from the hardware. That insulation is what makes one upload serve an unimaginably diverse device population, and it is the whole reason the approach scaled. It is also a boundary: a compiler cannot generate instructions addressing a capability that the representation it is compiling has no way to mention.
So the runtime can tune to the processor it finds, and does. What it cannot do is act on the presence of an accelerator the program was never able to describe wanting, or a memory topology the language has no vocabulary for, or the fact that something else on the device is currently contending for the same component. Those live below the abstraction, and the abstraction is load-bearing for portability. This is not a defect to be patched; it is the trade the design made deliberately, and the trade has been worth it. It just means the generation happens at the language layer and the components are one layer further down.
The graphics and compute path makes the boundary concrete. Work destined for the GPU does not travel as bytecode through the managed runtime. It travels as shader and pipeline descriptions, compiled by a vendor driver, in a dialect that differs across GPU vendors and driver versions, with results cached because the compilation is expensive enough to be visible to the user as stutter, and with those caches invalidated by driver updates. That is Paper 1's fixed-commitment problem in a different costume: a compilation performed against a specific driver at a specific moment, cached because repeating it is painful, and invalidated when the thing it was compiled against changes. Android's most sophisticated answer to heterogeneity was never applied to the components where the heterogeneity is worst.
The conclusion a reader might expect here is that Essence should replace the managed runtime. It should not, and this paper is not arguing for it.
The managed runtime is doing something Essence is not trying to do: running an enormous existing body of application code, written in ordinary languages by ordinary teams, portably and safely across a device population nobody controls. That is a genuine achievement with a genuine constituency, and displacing it would be both unnecessary and hostile to everyone depending on it. Essence's position on Android is beside the runtime, not underneath it and not instead of it. An application continues to run its code through ART exactly as it does today. Work that is expressed as declared intent takes the Essence path instead, resolving against the components present and generating instructions for them, and the two coexist in the same application.
That framing has a practical consequence worth stating: adoption does not require rewriting an application, and the boundary between the two paths is drawn by the developer at the point where the machine starts to matter. Everything that is fine being insulated from the hardware stays insulated. Work that is bottlenecked on a component the abstraction cannot describe stops going through the abstraction.
Android's userspace is POSIX-compatible, and Essence already ships as a native binary on Linux, so MindAptiv's assessment is that porting is short-duration work rather than a new implementation. That assessment is an engineering estimate and not a completed piece of work, and the substrate strip at the top of this paper says what is true today: there is no Essence build for Android, ChromeOS or Wear OS. The estimate is offered as an estimate. When there is a binary, this series will say so the way Paper 1 said it, with the artifact named.
No Essence deliverable on any Google platform. There is no Android, ChromeOS or Wear OS build. The POSIX-compatibility argument in Section 05 is MindAptiv's own estimate of effort, and an estimate is not a port. Android's C library and its security model differ from a conventional Linux distribution in ways that any real port has to answer to.
Not a criticism of the Android Runtime. Sections 01 and 02 are meant as credit and should be read that way. The runtime accomplishes something this series argues for, at a scale this series cannot claim, and the boundary described in Section 04 is a consequence of a deliberate and defensible design decision rather than an oversight.
No benchmark comparison. No test has been run comparing Essence-generated instructions against runtime-generated ones on any Android device, and none is represented here. The performance and energy figures cited elsewhere in this series come from validated work on other substrates under stated conditions, and they are not transferable to this one by assertion.
Platform details are public and moving. Android's runtime behavior, delivery format and graphics stack are documented publicly and revised frequently. This paper describes the architecture at a level intended to outlast individual releases, but any specific mechanism should be checked against current documentation.
The three Google platforms are not interchangeable. ChromeOS's execution model, with a browser engine and container-based compatibility layers, is not Android's, and Wear OS runs Android's under materially tighter power constraints. This paper treats them together for one argument about the managed runtime, which is a simplification, and any claim about a specific platform would need to name it.
Three substrates in, the fixed commitment has appeared in three forms. On Linux it is a convention, kept because it is cheaper to keep than to question. On Apple it is a rule, enforced by a quota. Here it is neither: Google removed the commitment at the language layer and left it in place everywhere below, which is the most interesting of the three because it was a choice made by people who clearly understood the problem.
Paper 5 stays with Android and changes the subject from the runtime to the hardware it runs on. Everything in this paper concerns the platform Google designs; the next concerns the devices Google does not build, where the manufacturer, the system-on-chip, the vendor layer and the update cadence vary for reasons that are commercial rather than technical, and where no managed runtime abstracts the variance away because the variance is not in the runtime's vocabulary to begin with.
The most widely deployed operating system on earth abandoned compile-in-advance more than a decade ago, generates native instructions on the phone from a portable representation, and uses observed behavior rather than a build server's assumptions to decide what to generate. That is this series' argument, already won, at a scale nothing else here approaches. What it generates against is bytecode whose defining property is that it cannot describe the machine, and the components where heterogeneity is worst were never brought into the managed path at all. Essence's position on Android is beside that runtime rather than in place of it. No build exists yet, and this paper says so.
The Common Substrate → Request Platform Access