Naming and the mascot

Two naming systems run through Android's history, and they work in opposite directions. The public one — desserts in alphabetical order — was abandoned in 2019. The private one — codenames, also in alphabetical order — never stopped. Understanding both is the easiest way to read a version table without confusion.

TL;DR#

• Versions were named after desserts in alphabetical order: Cupcake, Donut, Eclair, and so on through Pie.
• The scheme began informally and was kept because the alphabet gave each release a natural sequence and the names were memorable.
• Google stopped using dessert names publicly with Android 10 in 2019 and moved to numbers.
• Internal codenames continued in alphabetical order: Quince Tart, Red Velvet Cake, Snow Cone, Tiramisu, Upside Down Cake, Vanilla Ice Cream, Baklava, Cinnamon Bun.
• The mascot, often called Bugdroid, was designed by Irina Blok and her team and was deliberately simple enough to be redrawn in any style.

Mental model#

Think of two calendars hanging in the same office.

The public calendar has big printed dates and is given to clients. It was redesigned once, because the old design was charming but not scalable.

The internal calendar has the same dates with the team's own labels. It was never redesigned, because nobody outside the team needs to read it.

Android's dessert names are the public calendar until 2019, and the codenames are the internal one. Both are alphabetical. Only one is meant for you.

Where the analogy breaks#

A calendar's labels are arbitrary. Android's codenames are not entirely arbitrary: they are the release's identity inside the source tree, they appear in build configuration, and they are how engineers refer to a release that has not been announced. The codename is closer to a project name than to a private nickname, which is why it survives in the source long after the marketing name is decided.

The big picture#

The card is the whole story in one place. Watch what happens at API 29: the dessert field empties and the codename field keeps going. That is the 2019 decision, rendered as data.

Deep dive#

The dessert alphabet#

Android 1.0 and 1.1 had no official dessert names. Internal labels existed — "Astro Boy" and "Bender" are recorded, and 1.1 was internally "Petit Four" — but they were never used as public names.¹

The public scheme began with Android 1.5 Cupcake in 2009. Ryan Gibson is credited with the confectionery naming scheme for public releases.¹ From there the sequence ran:

The scheme was memorable, and the alphabet gave each release a natural order. It also created a small problem: as the alphabet advanced, the names became harder to fit on merchandise and harder to translate. Ice Cream Sandwich is a wonderful name and a terrible logo.

Why the names stopped#

In August 2019, Google announced it was ending the confectionery scheme and adopting numerical ordering. Android 10, released in September 2019, was the first under the new format.¹

Three pressures converged:

• The alphabet was running out of good names. Every remaining letter is a harder constraint than the last.
• Global products need unambiguous names. A dessert name is a translation problem and a pronunciation problem in markets where the reference is unfamiliar.
• Numbers are clearer for compatibility. If the marketing name and the API level are both numbers, users and developers have one fewer mapping to remember.

The change did not remove the tradition; it moved it inside. The version table on this site keeps the dessert field for the releases that had one, empty after API 28, and the codename field for every release.

The codenames that never stopped#

Internal codenames continued in alphabetical order after the public switch. The record includes:

• Quince Tart (Android 10)
• Red Velvet Cake (Android 11)
• Snow Cone (Android 12)
• Tiramisu (Android 13)
• Upside Down Cake (Android 14)
• Vanilla Ice Cream (Android 15)
• Baklava (Android 16)
• Cinnamon Bun (Android 17)

These appear in versions.json on this site as codename, and they are what the source tree calls the release. When you read AOSP build configuration or a release branch name, the codename is what you will see.²

The naming problem for developers#

The two naming systems are not just trivia; they create a real documentation problem. A bug report that says "broken on Oreo" is ambiguous: it could mean API 26, the 8.0 release, or the 8.1 release that kept the name. A report that says "broken on API 26" is unambiguous.

That is why the API level is the identity this site uses in tables and quizzes. The version name is useful for humans remembering a release; the API level is useful for anyone trying to reproduce a bug or check a behaviour change. When you write a bug report, use both, and use the API level first.

The codenames add a third layer. A branch named for a dessert is a branch most people cannot map to a version without a table. That is a cost the platform accepts because the codename is an internal identity and the mapping is part of the release process.

The mascot#

The Android robot — often called Bugdroid — was designed by Irina Blok and her team at Google.³ Its defining property is deliberate simplicity: it can be redrawn in any style, at any size, by anyone.

That openness was a design decision with consequences. Because the mascot is easy to redraw, it appears in hundreds of variations: release-specific costumes, community projects, conference artwork, and the easter eggs. A more detailed mascot would have been harder to license, harder to animate and harder to parody, and the platform's culture depends on all three.

The robot also carries a small piece of the platform's self-image. It is not a phone, not a brand mark, and not a character with a personality. It is a shape that can be anything, which is a fair description of the platform it represents.

Why the mascot is a design constraint#

A mascot is a design decision with engineering consequences. A complex character needs bespoke artwork for every context: every screen size, every animation, every release variation, every piece of partner marketing. A simple shape can be redrawn by anyone, which is why the Android robot appears in places the team never designed for.

That simplicity also makes the mascot a useful test of a partner relationship. If a device maker can render the robot in its own style and the result is still recognisably Android, the brand is doing its job. A more detailed character would make every partner rendering a negotiation.

Reading a version table#

Three rules keep the two naming systems straight:

1. The API level is the stable identity. It never changes and never repeats.
2. The marketing version is the public label. It stopped carrying dessert names after 9.
3. The codename is the internal identity. It continues alphabetically and appears in source and build configuration.

A row that reads API 36 | 16 | BAKLAVA is saying: API level 36, marketing version 16, internal codename BAKLAVA. There is no fourth field, because the public dessert name ended at Android 9. The codename happens to be a dessert, which is a coincidence of the internal alphabet, not a marketing decision.

How it evolved#

The UI rows show the design eras that ran alongside the naming eras: Holo, Material, Material You, Material 3 Expressive. The naming scheme changed once; the design language changed several times.

Under the hood#

• ‹›version_defaults.mk↗where the platform version and codename are assembled for a build
• ‹›Build.java↗VERSION.RELEASE, VERSION.SDK_INT and VERSION.CODENAME as the running system reports them
• ‹›release_config_map.textproto↗release configurations that select behaviour for a given release

Curiosity corner#

• Android 1.0 had no dessert name. Cupcake, at API 3, is the first public one.
• The internal alphabet is ahead of the public one. Codenames continued after the public scheme ended, so the two lists diverged permanently.
• The mascot is intentionally unfinished. Its simplicity is what lets it be redrawn, and the redrawing is the point.

Try it#

$ adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.codename
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.incremental

Illustrative output — values differ per device.

Build it#

B01 — Hello lifecycle reports the device's version and API level at runtime, which is the practical version of the table on this page.

Check yourself#

Sources#