When I'm updating a custom ROM, there's always an instruction to wipe the Dalvik cache. I don't see a reason why this is necessarily.

Watching the logcat while the system is booting I can clearly see that if an app changed, its dex file is invalidated and then regenerated. Yet still when I mention this anywhere I'm met with silence. As if not even some ROM developers are aware of this and they're only doing this because everyone else does.

So the questions:

  • Was there an Android version where Dalvik files were not invalidated during boot?
  • Is there any advantage in doing this yourself, instead of letting the system do the work it's supposed to do?

An ideal answer would include references to the relevant code, so I would have a reference the next time this comes up.

1 Answer 1


To answer your questions:

  • Am not aware of any Android version where the Dalvik was not invalidated on boot. Maybe the initial version 1.0 had that, I really do not know, have gone through Eclair, Froyo, Gingerbread, Ice Cream Sandwich. You need to look into the source tree and rebase it back to CupCake or Donut (1.5 and 1.6 respectively)

  • The detailed reason :)

The reason the Wipe Cache must be used is because all apks, including system apks, have a dex file attached to it, when the ROM is booted up for the first time, Android's Dalvik goes through each and every one of those apks, and extract the dex file from it and place it in the cache /data/dalvik-cache thereby speeding up the execution of the app itself.

Most ROMs have apks that are odex 'ed, the cache is bundled into the apk itself as an external file.

A lot of custom ROM modders would have those apks deodex 'd, meaning the dex file is replaced and repackaged to make it easier to theme/modify an apk.

When you flash a custom ROM, and did not wipe the cache, the newer custom ROM's apk's will have a different dex file attached to it, and when the Dalvik goes through them, it sees the existing cached dex file found in the directory, and skips it, then when you run the app, you're guaranteed a force close or ANR (Application Not Responding).

You are not losing data per se, if using ClockWorkMod Recovery, and Wipe Data is selected, then yes, all the settings relating to the apps are wiped cleanly - look in /data/app.

So you can Wipe Cache but not Wipe Data, what is done effectively, is slotted in the newer apks in place, in which it has the settings retained. This was quite a common scenario with CyanogenMod nightlies where a unstable/testing ROM build is flashed, and the settings retained with cache wipe. The mileage will vary depending on what apps downloaded from the market (settings would have changed by version bump quite likely).

For best results it would be wise to perform both Wipe Data and Wipe Cache to ensure integrity and no program errors within the app itself.

Yes that would mean the boot time would be slower but its initial once off moment. After that it would be booting quicker. Really in a nutshell, explicitly wiping the cache itself via CWM actually helps speed it up and ensure no residue from the previous version in place which could get munged in (Now at this stage, am realizing your question so in all fairness, have not actually seen Android not performing the invalidating of the cache itself upon boot when flashing a new ROM..)

Use the source Luke seriously! :D

frameworks/base/core/java/com/android/internal/os/ZygoteInit.java is the bootup code for each apk runtime. It interacts with the native C code found in the dalvik directory tree which contains specific chipset instructions to interpret the bytecode within the apk to native CPU instruction set. ARMv6 is pretty much a hacked version of ARMv5 (which was the original chipset in the older Android versions prior to Eclair), so you will not see ARMv6 in the AOSP source from google. CyanogenMod will have that ARMv6 in their source.

  • For the sake of this discussion let's assume that we're talking about an official CM7 release. Let me start by saying that I've never, ever wiped my dalvik cache and never experienced problems that would be solved by doing so. Because it's not odexed, there is no way there can be multiple (o)dex files present, and thus on boot the old file is replaced by a newly generated one. Oh and if it's a really big deal why don't the developers add this into the updater script? I will check out the source, thanks.
    – user13391
    Jul 15, 2012 at 15:11
  • 1
    You can actually explicitly put that into the updater-script, but that can piss others off when flashing because "Oh crap, I lost my settings/data" and CM probably did not want to get burned by the flame questions/answers as in "Why did you wipe my cache when flashing a new release of CM?" - maybe its down to responsibility of CM so gave that option to the end user? And putting it back on them so that if they flashed without wipe, and whine on the forums a lá "Hey my app is crashing", CM can turn around and say "Did you wipe?"
    – t0mm13b
    Jul 15, 2012 at 15:15
  • I didn't mean data/data but data\dalvik-cache. Possibly just the system ones.
    – user13391
    Jul 15, 2012 at 15:18
  • 1
    Stock AOSP ROMs are odexed, CM have modified the build system to use deodex.... just saying ;)
    – t0mm13b
    Jul 15, 2012 at 15:19
  • 2
    Thanks for the detailed answer t0mm13b. Just so I'm clear... It seems the simple answer to the question posted is "You don't. It's wiped by default at boot time." Correct?
    – GollyJer
    Aug 24, 2012 at 14:09

You must log in to answer this question.