What a Conformance Baseline Guarantees, What It Cannot Describe, and Why Variance Is Information
Paper 4 was about the platform Google designs. This one is about the devices Google does not build, where the processor, the graphics architecture, the vendor layer and the update cadence differ for reasons that are commercial rather than technical. Every industry answer to that variance works the same way: by making the devices more alike. This paper argues the opposite is available, and that fragmentation is only a problem for a system that intended to ignore the machine.
Android's device population differs along axes no software vendor chose and none can influence: the system-on-chip and therefore the graphics architecture, the neural and signal processing units, the memory subsystem and the thermal envelope; the manufacturer's own framework layer; and an update path that runs from Google through a chip vendor through a manufacturer and sometimes through a carrier, where any link can stall. This is routinely described as a technical failure. It is not. It is the visible shape of a supply chain in which several independent businesses each have commercial reasons to differentiate, and it persists because differentiating is profitable rather than because anyone failed to standardize.
The platform's answers to that variance are serious engineering, and they share one strategy: reduce what a device is permitted to differ in. A conformance definition and its test suite establish a floor every certified device must meet. A vendor-interface separation lets the framework be updated without the chip vendor's layer being rewritten. A modular update path lets parts of the system be revised directly. All of it works, and all of it is aimed at making devices more alike, because the artifact being delivered was compiled in advance and can only tolerate so much difference. This paper's argument is that the floor guarantees the things an application can rely on and is silent about the things that determine how fast the work actually runs, that the two sets barely overlap, and that a system resolving instructions at execution does not need the variance reduced. It needs the machine to be inspectable, which it is regardless of who assembled it. Fragmentation stops being a cost to be minimized and becomes information to be used.
The word "fragmentation" carries an implication that somebody was careless. It is worth removing that implication before the argument starts, because the structure it describes is not an accident and will not be tidied up.
An Android device is the output of several independent companies making decisions in their own interest. A chip vendor designs a system-on-chip and competes on the graphics architecture, the signal and neural processing units, and the memory subsystem, because those are what it sells. A manufacturer selects that chip, designs a thermal envelope and a battery around a price point, and layers its own framework and interface on top, because a phone indistinguishable from a competitor's cannot command a margin. An operator may sit in the distribution path with its own requirements. Each of them is differentiating deliberately.
The update path inherits the same structure. A platform revision travels from the platform owner to the chip vendor, from the chip vendor to the manufacturer, and sometimes onward again before it reaches a device, and any participant can stall it without violating any agreement. Slow updates are usually discussed as negligence. They are more accurately the observable behavior of a multi-party supply chain in which the parties are not the same company and do not share a schedule.
Faced with a device population it does not control, the platform did something reasonable: it defined a minimum. A compatibility definition states what a device must do to be called Android, an automated suite tests it, and a device that fails does not ship with the platform's applications and services. Alongside that sits a separation between the manufacturer's and chip vendor's layer and the platform framework above it, so the framework can move without the layer beneath being rebuilt, and a path for updating parts of the system directly rather than waiting for a whole-device release.
Together these establish a floor. Below the floor, a device may not vary. Above it, a device may vary as much as its makers like, and they do.
The strategy is worth naming precisely, because it is the same strategy Paper 1 found underneath thirty years of Linux packaging, wearing different clothes. Every one of these mechanisms works by reducing how much the real machine is allowed to differ from the assumed one. That is the correct move if what you are delivering was compiled in advance, because a fixed artifact can only tolerate so much difference before it stops working. The floor is not a failure of ambition. It is the necessary consequence of shipping something decided before the device was known.
A conformance floor is a guarantee about behavior. It says that if an application asks the platform for something, the platform will respond in the specified way on every certified device. That is genuinely valuable and it is what makes writing one application for a heterogeneous population possible at all.
It is also silent about almost everything that determines whether the work runs well. The floor does not tell an application which graphics architecture it is running on or which generation of it. It does not describe the neural or signal processing units present, which differ substantially between chip vendors and between chip generations from the same vendor. It says nothing about memory bandwidth, about the cache hierarchy, about the thermal budget the device was designed around, or about what else on the device is currently competing for any of it. Those are precisely the properties that separate a workload finishing quickly from the same workload finishing slowly on a device that looks, from the API's point of view, identical.
So the two sets barely intersect. Conformance describes the minimum an application may assume. It does not describe the machine an application actually got. An application built strictly to the floor is portable and is also, by construction, unable to take advantage of any device better than the worst one it must support.
The promise made to developers about Android is consistency: the same experience regardless of device. This paper thinks that promise is the wrong one, and it is worth being direct that this company has made it too.
Consistency across a heterogeneous population is achieved by targeting what all the devices share, which is the floor. That produces an application that behaves the same everywhere, which is a real virtue for interface behavior and correctness. It also produces an application whose performance is determined by the least capable device it supports, because the capabilities that are not universal are the ones it agreed not to use. A user holding a device with a substantially better graphics architecture and more memory bandwidth gets the same work done at close to the same speed as a user holding the baseline, and pays for the difference at purchase.
Cross-platform toolkits, portability layers and abstraction frameworks all sell the same thing, and it is genuinely valuable: write once, ship broadly, reason about one target. The cost is stated nowhere on the box. Every layer that hides the differences between machines is also a layer that prevents the software above it from acting on those differences, and the sum of those layers is why a phone with a decade of hardware progress in it often feels no faster at the same task than the one it replaced.
Here is the inversion the rest of the paper has been building toward. A system that resolves instructions at execution does not need the fragmentation reduced. It needs the machine to be inspectable, and the machine is inspectable regardless of which vendor's chip is in it, which manufacturer assembled it, or which framework layer the manufacturer put on top.
Under that model the axes described in Section 01 change sign. The graphics architecture is not an incompatibility to be abstracted over; it is a fact about this device that determines what instructions to generate for it. The presence or absence of a signal processing unit is not a portability hazard; it is available capacity or it is not, discovered at execution rather than assumed at build. The thermal budget is not a support-matrix footnote; it is a live constraint the resolver can take into account. The more the devices differ, the more there is to gain from generating for the one in hand, which is the exact reverse of the relationship every other layer in this stack has with variance.
The practical shape on Android is the one Paper 4 established and this paper does not change: Essence sits beside the managed runtime as a second path rather than underneath or instead of it. Existing application code continues through the runtime, portable and conformant, exactly as it should. Work expressed as declared intent takes the second path and resolves against whatever this specific device turned out to be. The floor keeps doing its job for everything that benefits from it, and the work that is bottlenecked on hardware the floor cannot describe stops being written to the floor.
No Essence deliverable on Android. As stated in Paper 4, there is no Android build. The assessment that Android's POSIX-compatible userspace makes porting short-duration work is MindAptiv's own estimate of effort, and an estimate is not a port.
Not an argument against the conformance program. A floor that guarantees behavior across a device population nobody controls is the reason a single application can be written for that population at all. Section 03 argues that it does not describe the hardware, which is a statement about its scope rather than a criticism of its design.
No measurement on any Android device. No test has been run comparing work resolved at execution against work written to the conformance floor on any phone, and the acceleration and energy figures cited elsewhere in this series were obtained on other substrates under stated conditions. Section 05 makes a structural argument, not an empirical one.
No claim about any specific chip vendor or manufacturer. The paper describes the shape of a supply chain from public information. It attributes no conduct to any named party and reports no engagement with any of them.
Resolution does not eliminate the need for the floor. Application behavior, correctness and interface consistency benefit from a guarantee, and the second path described in Section 05 sits beside that guarantee rather than replacing it. An argument that the floor should be discarded would be a different and worse paper.
The first movement is finished. Five substrates, and the fixed commitment appeared in five relationships: a convention on Linux, a quota on Apple, a debt on Windows, a boundary drawn at the language layer on the platform Google designs, and here, a floor built to make devices alike enough for a prebuilt artifact to survive them.
Section 03 named the properties the floor cannot describe, and every one of them is a property of a component rather than of an operating system. That is the seam the second movement opens. Paper 6 goes to the accelerator, where the commitment is at its most literal and most expensive: a kernel compiled for one vendor's instruction set is worth nothing on another's, which is why the lock-in in that part of the industry sits at the toolchain rather than at the hardware. Paper 7 follows it down to the processor architectures themselves.
Android's variance is a supply chain of independent companies differentiating on purpose, and it is not going to be tidied away. The platform's answer, like every other answer in this series, is to shrink what a device is permitted to differ in, because an artifact compiled in advance can only tolerate so much difference. That floor guarantees behavior and is silent about the graphics architecture, the processing units, the memory bandwidth and the thermal budget that decide how fast the work runs. A system that generates instructions after inspecting the machine does not need any of that variance reduced. It reads it. On the substrate everyone else calls fragmented, that is the difference between a device's capabilities being a support-matrix problem and being the point.
The Common Substrate → Request Platform Access