Why Do I Need to Wipe Dalvik Cache?
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
dexfile 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.
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-cachethereby 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
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.javais the bootup code for each apk runtime. It interacts with the native C code found in the
dalvikdirectory 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.
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?"
Stock AOSP ROMs are odexed, CM have modified the build system to use deodex.... just saying ;)
Last final comment, Some ROM Modders would either base their code of AOSP vanilla, CAF, or CM, so if you were to go from CM to CAF for instance, then explicitly wipe the data/cache, due to differences, likewise same for going from AOSP to CM. Common sense comes into play here. But you seem to be focussed purely on CM, going from one nightly to the next or from stable to next stable, then yes no negligble differences in there apart from ROM signing keys etc. Likewise, if you are on GB CM72, and go to ICS CM9, then yes it would be prudent to do the same!
I'm only focused on CM because I only visit CM threads on forums, so I only see what they say. For switching between *mayor branches* I can understand the need to wipe it (differences in the VM maybe?) or between OS version (2.3 to 4.0), but I never do it for anything else, and my phone works OK. So it looks like for the original case (updating to never rom version) it's really just to have something as an insurance if users come complaining.
Note: this mindless do something because everyone else does it, is very common among modaco's rom chefs (the guys who work with winzip)