DEX (Dalvik Executable)
Also known as: dex file android, classes.dex, dalvik executable, android dex format
DEX (Dalvik Executable) is the bytecode format Android apps ship in. Compiled Java/Kotlin classes are packaged into classes.dex files inside the APK, then optimized by the ART runtime into native code at install or runtime.
- DEX is Android's bytecode format; build tools (d8) compile classes into classes.dex inside the APK.
- One DEX file caps at 65,536 method references, so big apps split into multidex (classes2.dex, ...).
- ART verifies and AOT-compiles DEX into .vdex/.oat/.art native artifacts via the dexopt job.
What the DEX format is
Android apps are written in Java or Kotlin and compiled to .class files, but those JVM class files aren't what ships to the device. A tool in the build pipeline (today d8, formerly dx) converts and merges them into Android's own DEX (Dalvik Executable) bytecode, designed to be compact and efficient on memory-constrained phones.
The result is one or more classes.dex files placed inside the APK (which is just a ZIP archive). A single DEX file can reference at most 65,536 methods, so larger apps use multidex (classes.dex, classes2.dex, and so on). You can confirm this by unzipping any APK and listing its contents.
How DEX is executed and why it affects storage
At runtime the ART runtime doesn't interpret raw DEX forever. It verifies the DEX (producing .vdex), then uses profile-guided AOT compilation to turn hot code paths into optimized native code (.oat/.art), running the background dexopt job during idle/charging. This is why an app's on-disk footprint and its share of System data grow after install.
For a cleaner like Cleanor, the DEX inside an APK is part of the irreducible app payload, while the compiled artifacts ART generates from it are system-owned cache. Understanding the split explains why deleting an app's cache shrinks some storage but the base app size (driven by its DEX and resources) stays fixed.