The update problem

Every Android release from 2008 to 2017 carried the same complaint: the platform is fine, but you cannot have it. The reason was not engineering laziness. It was that a one-line framework fix had to travel through four organisations, and any one of them could stop it.

TL;DR#

• An Android device is built from two independently developed bodies of code: the system image (framework, runtime, system apps) and the vendor image (drivers, firmware, HALs).
• Before Treble, the boundary between them was a C ABI with no version negotiation, so a system image change generally required a vendor rebuild.
• The result was a long dependency chain: Google → SoC vendor → OEM → carrier → device. Each link added months.
• The fix was not to make updates faster. It was to make the seam cheap, so most system-image changes did not require any vendor work at all.
• Treble did not solve the last mile. OEMs could still decline. It removed the technical excuse.

Mental model#

Imagine a car where the engine and the dashboard are designed together.

If you want a new dashboard, you cannot simply order one: the wiring harness is bespoke, the mounting points are bespoke, and the software that drives the gauges is compiled against a protocol that only this engine speaks. So a dashboard update is an engine-out job, and nobody does it.

Now imagine the manufacturer defines a standard connector: any dashboard that speaks the connector's protocol fits any engine that exposes it. A new dashboard becomes a swap.

That is Treble. The connector is the vendor interface. The dashboard is the system image, the engine is the vendor image.

Where the analogy breaks#

A car has one vendor interface. A phone has dozens: camera, audio, sensors, graphics, keymaster, vibrator, and so on. And the analogy suggests a clean separation that does not exist in practice: the kernel sits below the vendor interface, and the framework's behaviour often depends on which HAL versions the device provides. The seam is real but it is not a single line.

The big picture#

Deep dive#

The chain, in detail#

A pre-Treble Android update followed this path:

1. Google releases AOSP. The framework, runtime and system apps change. Some changes touch the HAL interfaces.
2. The SoC vendor updates its BSP. The board support package contains the kernel, drivers, firmware and HAL implementations. If the framework changed a HAL interface, the BSP must change to match.
3. The OEM integrates. The OEM applies its skin, its carrier customisations and its device configuration on top of the new BSP and the new system image.
4. Carriers certify. In markets where carriers sell and support devices, the carrier tests and approves the build.
5. The update ships. Often months later, sometimes never.

Each step has its own schedule, its own priorities and its own economics. A SoC vendor supports a chip for a fixed period, and that period does not renew itself when a new Android release appears. An OEM's support window is set by its product cycle, not by the platform's. A carrier's testing cycle is measured in weeks.

Why the technical barrier was the real one#

You could argue that OEMs simply did not want to update. That reading is too simple, and Treble provides a way to test it: once the technical barrier was removed, the remaining delay could only come from the commercial one.

The clearest natural experiment is the Generic System Image. A GSI is a stock AOSP system image that can boot on any Treble-compliant device. If a phone boots a GSI, its vendor interface is genuinely separate from the framework — the framework was replaced wholesale and the vendor image did not change. That is a testable claim, and it is the thing Treble promised.

The GSI test also demonstrates the limit. Booting a GSI proves the interface is clean. It does not prove the OEM will ship a new system image, and it does not make the vendor's own bugs go away.

What the interface actually had to contain#

Making the seam cheap required several pieces, and each one exists because of a specific failure:

A stable ABI. Vendor code calls into platform libraries. If those libraries' symbols or struct layouts change, the vendor binary breaks. The VNDK (Vendor NDK) is the restricted set of native libraries that vendor code is allowed to depend on¹, precisely so that the platform can change everything else without breaking vendors.

A declaration of what exists. The VINTF manifest lists what the device provides; the compatibility matrix lists what the framework requires. At boot, the two are reconciled. A mismatch is a boot failure, not a mysterious runtime crash three weeks later.²

A test that proves it. The Vendor Test Suite checks the vendor implementation against the interface. Without VTS, "Treble-compliant" would be a claim; with it, it is a measurement.³

A way to build against the interface. HAL interfaces are versioned packages, so a vendor can build against @2.4 and a framework can require 2.4 or later without either side knowing the other's code.

The kernel is a separate version of the same problem#

The kernel sits below the vendor interface, and it had the same structural problem. Every device shipped a kernel built by the SoC vendor, often with out-of-tree patches. Updating the kernel meant updating the vendor's BSP, which meant the same chain.

GKI applies the same idea one layer down: one kernel binary, built from the Android Common Kernel, with a stable Kernel Module Interface so vendor modules can be built against it. That story gets its own page.

What Treble did not fix#

Three things remained, and they are worth being explicit about because the marketing around Treble oversold it.

• The vendor image still belongs to the OEM. Treble made it possible to update the system image without touching the vendor image. It did not make the OEM ship.
• The kernel was still the OEM's problem until GKI.
• Some framework behaviour still depends on vendor code. A HAL interface can be satisfied and still behave badly. The framework has to cope.

The honest summary is that Treble removed a technical blocker and left the commercial one. The years after 2017 show both effects: updates got faster and more predictable, and devices still fell out of support on the OEM's schedule.

How it evolved#

Three milestones mark the arc: Treble at Android 8.0 (API 26·Android 8.0), Mainline at Android 10 (API 29·Android 10), GKI at Android 11 (API 30·Android 11). Each one moved a different boundary from "requires a full rebuild" to "can be replaced".

Under the hood#

• ‹›↗the HAL interfaces that form the vendor contract
• ‹›↗manifest and compatibility-matrix checking, the runtime half of the promise
• ‹›↗the Vendor Test Suite that measures whether an implementation honours the contract
• ‹›↗the build rules that produce system.img and vendor.img as separate artefacts

Curiosity corner#

• The GSI is a debugging tool that became a compatibility proof. It was built to test Treble; it is now the standard way to demonstrate that a device's vendor interface is genuinely separate.
• A device can pass CTS and fail VTS. They test different halves of the contract: public API behaviour versus vendor interface compliance.
• "Project Treble" was named after a Treble clef, continuing the music-themed codenames of the era. The name has no technical meaning.

Try it#

$ 
adb shell getprop ro.treble.enabled
adb shell getprop ro.vndk.version
adb shell ls /vendor/etc/vintf/

ro.treble.enabled should be true on any device launched with Android 8.0 or later. The VINTF directory holds the manifest and, on some devices, a fragment directory for each HAL.

Check yourself#

Sources#