ART (Android Runtime)
Also known as: android runtime art, art vs dalvik, android art runtime
ART (Android Runtime) is the managed runtime that executes Android apps, having replaced Dalvik as the default in Android 5.0. It compiles app bytecode ahead of time and at runtime, producing optimized .oat/.art/.vdex files that speed up apps but also consume storage.
- Replaced Dalvik as the default Android runtime in Android 5.0 (Lollipop).
- Uses hybrid AOT, JIT, and profile-guided compilation of an app's DEX bytecode.
- Generates .oat, .art, and .vdex caches that consume storage but are regenerable.
What ART is and how it runs apps
ART is the runtime that loads and executes the DEX (Dalvik Executable) bytecode inside every Android app. It became the default in Android 5.0 (Lollipop), fully replacing the older Dalvik runtime. App source compiles to DEX, and ART turns that into native machine code the CPU runs.
Unlike Dalvik's pure just-in-time approach, ART uses a hybrid model: a mix of ahead-of-time (AOT) compilation, a just-in-time (JIT) compiler, and profile-guided compilation. Frequently used methods recorded in a profile get compiled to native code in the background (often while charging and idle), so hot paths run fast without bloating every install.
The caches ART generates
Compilation produces optimized artifacts stored under the app's oat/ directory (and in newer releases the Android Runtime APEX / dalvik-cache). The main file types are .oat (compiled native code), .art (a preloaded image of common classes/objects), and .vdex (verified DEX, letting ART skip re-verification). These are derived from the APK, so they are regenerable, not user data.
This optimized code is what users see as App optimization or the long ART/dalvik-cache rebuild after a system update or a major Android upgrade. The same artifacts are sometimes labeled Dalvik cache in storage breakdowns for historical reasons.
Why it matters for storage
Because .oat/.art/.vdex files duplicate compiled forms of app code, they can take meaningful space, and they show up in a storage breakdown as part of system or app overhead. They are regenerable: the system rebuilds them automatically, which is exactly the optimization pass after an OS update.
A cleaner like Cleanor does not delete ART artifacts on its own, since wiping them only forces a slow rebuild and is not safe junk. Instead it explains this category so users understand why storage usage can spike after an update, and focuses its clearing on genuine app cache rather than runtime-generated code.