Every Android user wants their apps to launch instantly and run smoothly. A critical technology working behind the scenes to make this happen is the Android Runtime (ART) and its associated cache. The ART cache, often referred to by its legacy name, the Dalvik cache, is a dedicated area of your device’s storage where Android stores pre-compiled application code. This process of pre-compilation is what allows your apps to start much faster than they otherwise would. Understanding what this cache is, how it works, and whether you should ever clear it is essential for any power user looking to get the most out of their device.
The Problem: The Slow Start of Just-in-Time (JIT) Compilation
To understand the importance of ART, we must look at its predecessor, the Dalvik runtime, which was used in older versions of Android (4.4 KitKat and earlier). Android apps are written in Java or Kotlin, which is compiled into an intermediate bytecode format called DEX (Dalvik Executable). Dalvik was a Just-in-Time (JIT) compiler. This meant that every time you launched an app, Dalvik had to translate the DEX bytecode into the native machine code that your device’s CPU could understand, right then and there. This on-the-fly translation process consumed significant CPU cycles and time, resulting in noticeably slower app launch times.
The system needed a way to do this heavy lifting ahead of time, so that when a user tapped on an app icon, the phone could execute native code directly, rather than starting a compilation process from scratch every single time.
Introducing ART and the ART Cache: Ahead-of-Time (AOT) Compilation
Starting with Android 5.0 Lollipop, Google replaced Dalvik with the new Android Runtime (ART). The primary innovation of ART was its introduction of Ahead-of-Time (AOT) compilation. Instead of waiting until you launch an app, ART compiles the app’s DEX bytecode into native machine code at install time. This pre-compiled native code is then stored in a special directory on your device’s data partition. This storage area is the ART cache.
When you launch the app, the system can now load and execute this optimized, native code directly. This completely bypasses the need for runtime JIT compilation for the initial launch, leading to dramatically faster app startup times and smoother overall performance.
How the ART Cache Works Internally
The creation and management of the ART cache is a sophisticated process handled by the Android OS.
1. The `dex2oat` Compilation Process
The key actor in this process is a system tool called `dex2oat`. The “oat” stands for “Optimized Android file Type.” This tool is responsible for taking an app’s `classes.dex` file and compiling it into a format that contains the native code.
This compilation happens at several key moments:
- At App Install Time: When you install a new app from the Play Store, the package manager runs `dex2oat` to generate the initial compiled code.
- After an OS Update: When you update your Android OS, the “Android is upgrading… Optimizing apps” screen you see on the first boot is the system re-running `dex2oat` on all your apps to ensure they are compatible with the new version of the runtime.
- During Device Idle Time: Modern versions of ART use a hybrid approach. They may use a faster JIT compilation for the first few runs of an app, while collecting data on which parts of the code are most frequently used. Then, when your device is idle and charging, a background process will run `dex2oat` to AOT-compile these “hot” code paths for maximum performance. This is known as Profile-Guided Optimization (PGO). You can sometimes see this process, `dex2oat`, running in your battery stats. It is a normal part of the dex2oat process.
2. The Cached Files: OAT, ODEX, and VDEX
The output of the `dex2oat` process is stored in a cache directory, typically located at `/data/dalvik-cache/`. Inside, you’ll find several types of files for each app:
.oat: Contains the native Ahead-of-Time compiled code..odex: An “Optimized DEX” file. In modern Android, this is often part of the OAT file..vdex: A “Verified DEX” file that contains the uncompressed DEX code with additional metadata to speed up verification, reducing launch times even further.
These files can be quite large, and the total size of the ART cache across all your apps can easily run into several gigabytes. This is a deliberate trade-off: using storage space to save CPU time and improve performance.
ART vs. Dalvik: A Direct Comparison
| Aspect | Dalvik (Legacy) | ART (Modern) |
|---|---|---|
| Compilation Method | Just-in-Time (JIT) – Compiles at runtime. | Ahead-of-Time (AOT) + JIT with Profile-Guided Optimization. |
| App Launch Time | Slower, due to runtime compilation overhead. | Significantly faster, as native code is executed directly. |
| Performance | Less performant due to JIT overhead. | More performant and smoother, especially with PGO. |
| Storage Usage | Lower. No large AOT cache is stored. | Higher. The ART cache can take up several gigabytes. |
| App Install Time | Faster, as no AOT compilation is done. | Slower, as `dex2oat` must run to compile the app. |
Should You Clear the ART/Dalvik Cache?
This is a common question, especially in the Android enthusiast community. “Wiping the Dalvik/ART cache” is a standard option in custom recoveries like TWRP. Here’s when it makes sense and when it doesn’t.
When Clearing the Cache Can Be Useful:
- After a “Dirty Flash”: If you flash a new custom ROM over an old one without wiping your data (a “dirty flash”), the old cache files might be incompatible with the new system, leading to bootloops or constant app crashes. Wiping the cache forces the new system to rebuild it from scratch, resolving these conflicts.
- Persistent App Crashes: In very rare cases, the cached OAT file for an app can become corrupted, causing it to crash on launch. Wiping the cache and letting the system rebuild it can solve this problem.
- Freeing Up Space (Temporarily): Wiping the cache will free up a significant amount of storage space. However, this is only temporary. The system will immediately begin to rebuild the cache in the background as you use your apps, and the space will be consumed again. It is not a long-term solution for low storage.
Why You Shouldn’t Clear It Routinely:
There is absolutely no benefit to clearing the ART cache on a regular basis as a “maintenance” task. Doing so is counterproductive:
- It will slow down your phone. After wiping the cache, every single app will need to be recompiled. The first boot will be extremely long, and every app you open for the first time will launch much more slowly.
- It will drain your battery. The `dex2oat` process is CPU-intensive. Forcing the system to recompile all your apps will consume a significant amount of battery.
Conclusion: Only clear the ART cache if you are troubleshooting a specific problem like a bootloop after flashing a ROM or persistent system-wide instability. Never do it as part of a routine cleaning process. This system is related to the core OS and can interact with many parts, including how the vendor partition interfaces with the system.
For more details on ART’s internals, the Android Open Source Project (AOSP) documentation is the definitive source.
Frequently Asked Questions
What is the difference between “Clear Cache” in app settings and wiping the ART cache?
They are completely different. The “Clear cache” button in an app’s info page (Settings > Apps) deletes that specific app’s temporary data cache (e.g., downloaded images, temporary files). This is useful for freeing up space or fixing issues within that one app. Wiping the ART/Dalvik cache is a system-wide action that deletes the pre-compiled code for *all* apps, forcing them all to be re-optimized.
Why is my phone so slow after a major Android update?
This is the ART cache being rebuilt. The update installs a new version of the Android Runtime. All of your existing apps’ compiled code is now obsolete and must be recompiled by `dex2oat` to work with the new runtime. This process takes time and consumes resources, so your phone may feel sluggish and have lower battery life for a few hours (or even a day) after a major update until the re-optimization process is complete.
Does the ART cache get backed up?
No. The ART cache contains device-specific compiled code. It would be useless to back it up and restore it to another device (which might have a different CPU architecture) or even the same device after a factory reset. It is always generated from scratch based on the APKs installed on the system.