AOSP vs GMS vs OEM: why Android is four products

When someone says "Android 17 shipped today", what shipped is the AOSP source tree. When your phone gets Android 17, the OEM built that tree together with vendor code and certified it. When a developer says "Android", they often mean the Google Play services APIs their app calls. These four things are maintained by different organisations, on different schedules, with different rules.

TL;DR#

• AOSP is the open-source platform. It is the kernel interface, framework, runtime, system apps and native stack, available for anyone to build.
• GMS (Google Mobile Services) is proprietary: Play Store, Play services, and the Google apps. It is licensed separately and not part of AOSP.
• The vendor stack is the SoC vendor's and OEM's code: drivers, firmware, HALs and the manufacturer's own apps and customisations.
• A shipping phone is all three assembled, certified against the CDD and passing the CTS.
• The split explains why updates vary, why "Android" versions can differ in features, and why the platform's modularisation projects (Treble, Mainline, GKI) matter.

Mental model#

Think of a car.

The chassis and engine design are AOSP: an open engineering blueprint anyone can build from.

The infotainment system and navigation subscription are GMS: a branded product from one company, licensed to the manufacturer.

The suspension tuning, paint and interior are the vendor and OEM layer: everything that makes this specific car this specific car.

The car you drive is the shipping device: all of it, assembled and homologated.

Where the analogy breaks#

Cars are assembled by one manufacturer with one brand. Android devices are assembled by a chain: Google writes the platform, a chip company writes the low-level support, a phone company assembles and customises, and a carrier can add restrictions. Four parties, four schedules, one product. That chain is why the update story needed to be re-engineered rather than merely asked for.

The big picture#

Deep dive#

What AOSP actually contains#

The Android Open Source Project is a full source tree at android.googlesource.com, mirrored by source.android.com documentation. It includes the framework, the runtime, the native libraries, the system services, the AOSP system apps, the build system and the kernel interfaces.

It does not include Google's apps or Play services, and it does not include drivers for any particular phone. Building AOSP from source produces a working system image for a reference device or an emulator, not a phone you can buy.

What GMS adds, and why it matters to developers#

GMS bundles the Play Store, Play services, and apps such as Gmail, Maps and Chrome. Play services is the interesting part: it is an app that other apps bind to, exposing APIs such as Fused Location, Firebase, Play Integrity and much of the ML tooling.

Because Play services updates through the Play Store, Google can ship new developer APIs to old Android versions. That is a large part of why some "Android features" appear on a device that never received an OS update.

The flip side: an app that depends on a Play services API will not work on a device without GMS, which is a real constraint in some markets.

The vendor stack#

The SoC vendor supplies the kernel support, the drivers, the firmware, and the HAL implementations that the platform talks to. The OEMs supply their own apps, their own launcher, their own settings additions, and often their own modifications to the platform.

This is the most device-specific code on the phone and the hardest to update. It is precisely what Project Treble was designed to isolate.

Certification: the CDD and the CTS#

To ship Google's proprietary apps, a manufacturer must meet the Compatibility Definition Document — the rules about what a device must implement — and pass the Compatibility Test Suite, an enormous automated test suite. There is also a Vendor Test Suite for the vendor-specific side, and GTS for the Google services.

That certification is why "Android" means something consistent across thousands of devices, even though the code differs.

How it evolved#

The three-layer split has existed since 2008; what changed is how much of the platform escaped the OEM update path.

Under the hood#

• ‹›↗the AOSP product configurations that define a build
• ‹›↗where a vendor or OEM places its device-specific code
• ‹›↗the vendor tree in an AOSP checkouts with a vendor layer

Curiosity corner#

• AOSP has had a reference device for most of its life, which is how the platform team could build and test without waiting for a phone company.
• Play services is an app, which is why it has a version number, a permission list and a battery cost.

Try it#

$ 
adb shell pm list packages | grep -c "com.google"
adb shell pm list packages | grep -c "com.android"

The first count tells you how much GMS software is installed; the second shows the AOSP-derived system packages. The ratio is a rough picture of the two layers on that device.

Check yourself#

Sources#