Introduction
For the first five years of Android’s existence, every app you opened was compiled on the fly by a virtual machine called Dalvik. It was a Just-in-Time (JIT) compiler — it translated bytecode to native machine code every time an app launched, every time a method was called, every time you scrolled a list. It worked, but it was slow, and it burned battery.
ART (Android Runtime) replaced Dalvik, and it changed how Android apps execute at a fundamental level. The transition took three years, three major Android versions, and a complete rethinking of how mobile apps should be compiled. This is the story of ART — from experimental opt-in to the foundation of every Android device.
The Dalvik Era (2008–2014)
Dalvik was Android’s original runtime, designed by Dan Bornstein and named after a fishing village in Iceland. It was a register-based virtual machine that executed DEX bytecode — a compact format optimized for mobile devices with limited memory and storage.
Dalvik used JIT compilation: when an app launched, Dalvik interpreted the DEX bytecode and compiled frequently-used methods to native code at runtime. This had advantages:
- Fast installs: Apps didn’t need to be compiled at install time. Just copy the APK and go.
- Smaller app size: DEX bytecode was more compact than native code.
- Flexibility: The JIT could optimize based on actual runtime behavior.
But it had significant disadvantages:
- Slow launches: Every app launch required JIT compilation, which consumed CPU cycles.
- Runtime overhead: The JIT compiler ran continuously during app use, consuming CPU and battery.
- GC pauses: Dalvik’s garbage collector paused all threads during collection, causing UI stutter.
By 2013, Dalvik was hitting its performance ceiling. Google needed a new runtime.
ART: The AOT Approach
ART (Android Runtime) was developed as a replacement for Dalvik. Its key innovation was Ahead-of-Time (AOT) compilation: instead of compiling bytecode at runtime, ART compiled the entire app to native machine code at install time.
The trade-offs were clear:
Advantages:
- Faster execution: Native code runs faster than JIT-compiled code. CPU-bound operations saw 10–30% improvements.
- Faster app launches: No JIT compilation at launch time. Apps started faster.
- Better battery life: No continuous JIT compilation during app use.
- Improved garbage collection: ART’s concurrent GC paused individual threads instead of the entire VM, reducing UI stutter.
Disadvantages:
- Longer install times: AOT compilation at install time made app installs and OS updates noticeably slower.
- Larger app size: Compiled native code was 10–20% larger than DEX bytecode.
- Compatibility: Some older apps relied on Dalvik-specific behavior and crashed on ART.
The Transition (2013–2015)
ART was introduced as an experimental option in Android 4.4 KitKat (2013). It was hidden behind Developer Options, and Google warned that it was “not yet ready for daily use.” Enthusiasts enabled it anyway and reported faster app launches and smoother scrolling — along with occasional crashes and compatibility issues.
Android 5.0 Lollipop (2014) made ART the default and only runtime. Dalvik was removed entirely. Every app on every Lollipop device ran on ART with full AOT compilation.
The transition was rough. App installs and OS updates took significantly longer. Some apps crashed. The “Android is upgrading” screen — which displayed during AOT compilation after an OS update — became a meme. Users complained about 20-minute update times.
But the performance benefits were real. Apps launched faster. Scrolling was smoother. Battery life improved. The trade-off — slower installs for faster everything else — was worth it.
The Hybrid Era: JIT/AOT (2016–Present)
Android 7.0 Nougat (2016) introduced a hybrid JIT/AOT compiler that addressed ART’s biggest weakness: slow install times.
The hybrid approach worked in stages:
- Install: Apps were installed quickly with no AOT compilation. The initial launch used interpretation (no compilation at all).
- Profile-guided JIT: As the app ran, the JIT compiler profiled which methods were used most frequently and compiled them to native code.
- Background AOT: When the device was idle and charging, the system compiled the profiled methods to native code using AOT. Only the code that was actually used was compiled — not the entire app.
This hybrid approach combined the best of both worlds: fast installs (like Dalvik), fast execution (like ART), and efficient storage (only frequently-used code was compiled).
The hybrid compiler has been refined through every Android release since Nougat. Modern ART is faster, more memory-efficient, and more compatible than either Dalvik or the original AOT-only ART.
ART Today
ART in Android 15 is unrecognizable from the experimental runtime in KitKat:
- Concurrent compacting GC: Garbage collection that runs concurrently with app threads and compacts the heap to reduce fragmentation.
- Profile-guided optimization: Apps are optimized based on how they’re actually used, not how they’re written.
- DEX layout optimization: DEX files are reorganized on-device to improve load times.
- App startup optimization: ART pre-compiles startup code paths to reduce cold-start latency.
- Memory safety: ART includes bounds checking, use-after-free detection, and other memory safety features.
ART is now one of the most sophisticated mobile runtimes in the world. It compiles billions of apps across billions of devices, and it does it so transparently that most users have no idea it exists.
The Legacy
ART’s transition from experimental to mandatory was one of the most significant engineering changes in Android’s history. It improved performance for every app on every device without requiring developers to change a single line of code.
The hybrid JIT/AOT compiler — introduced in Nougat and refined ever since — is a model of pragmatic engineering: acknowledge the trade-offs, measure the real-world impact, and iterate toward a solution that balances competing priorities.
Dalvik served Android well for five years. ART has served it better for ten. Whatever comes next — and there will be a next — will build on ART’s foundation.
References
- ART runtime technical documentation (source.android.com)
- “Introducing ART” (Android Developers Blog, 2013)
- “Android 5.0 Lollipop: ART” (Android Developers Blog, 2014)
- “Android 7.0 Nougat: JIT/AOT Hybrid Compiler” (Android Developers Blog, 2016)
- Dalvik virtual machine technical documentation (source.android.com, archived)