How API levels work
Every Android platform release has an integer API level that identifies its framework revision. You reference it in build.gradle through minSdk, targetSdk and compileSdk, and in code through Build.VERSION.SDK_INT compared against a Build.VERSION_CODES constant. For example, an Android 14 check reads if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE).
Google retired public dessert names after Android 9 (Pie), but AOSP kept the alphabetical codenames internally — Quince Tart, Red Velvet Cake, Snow Cone, Tiramisu, Upside Down Cake, Vanilla Ice Cream, Baklava, Cinnamon Bun.
FAQ
What API level is Android 14?
API level 34, codename Upside Down Cake, constant UPSIDE_DOWN_CAKE.
What is the latest Android API level?
API 37 — Android 17, internal codename Cinnamon Bun — which reached stable in June 2026. API 36 is Android 16 (Baklava).
What minSdk should I choose?
It's a trade-off between reach and maintenance. Many teams sit around API 24–26 today; check current device distribution and see the minSdk vs targetSdk vs compileSdk guide.
Why the number matters more than the name
Dessert names are fun trivia, but the API level integer is what your build and your code actually care about. Gradle compares integers to decide which APIs are available, and Build.VERSION.SDK_INT is an integer you branch on at runtime. When a library says it "requires API 26+", it means the integer, not the marketing version — so the mapping in the table above is the thing you reach for when a dependency, a permission, or a platform behavior is gated behind a particular release. Knowing that Android 8.0 is API 26 turns a vague requirement into a concrete minSdk decision.
How new API levels reach devices
A new API level ships the moment a platform version reaches stable, but the devices in people's hands lag behind for years. That gap is the whole reason minSdk and runtime version checks exist: you compile against the newest level to use its APIs, while still supporting older ones by guarding new calls behind SDK_INT checks. This is why the "latest" API level and the API level you should actually target for reach are rarely the same number — the newest gives you capabilities, the distribution data tells you how many users you'd exclude.
Is the API level the same as the Android version?
No — they're parallel numbering. The Android version (like 14) is the marketing name; the API level (34) is what your build and code use. This table maps between them.
Why do some releases share a "version" but differ in API level?
Feature-drop and point releases can add a new API level without a headline version bump, which is exactly why relying on the integer avoids confusion.