双清,解散如下
Why Do I Need to Wipe DalvikCache?
When I'm updating a custom ROM, there'salways an instruction to wipe the Dalvik cache. I don't see a reason why thisis necessarily.
Watching the logcat while the system isbooting I can clearly see that if an app changed, its dex file is invalidatedand then regenerated. Yet still when I mention this anywhere I'm met withsilence. As if not even some ROM developers are aware of this and they're onlydoing this because everyone else does.
So the questions:
Was there an Android version where Dalvikfiles were not invalidated during boot?
Is there any advantage in doing thisyourself, instead of letting the system do the work it's supposed to do?
An ideal answer would include references tothe 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 wherethe 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 CreamSandwich. You need to look into the source tree and rebase it back to CupCakeor Donut (1.5 and 1.6 respectively)
The detailed reason :)
The reason the Wipe Cache must be used isbecause all apks, including system apks, have a dex file attached to it, whenthe ROM is booted up for the first time, Android's Dalvik goes through each andevery one of those apks, and extract the dex file from it and place it in thecache /data/dalvik-cache thereby speeding up the execution of the app itself.
Most ROMs have apks that are odex 'ed, thecache is bundled into the apk itself as an external file.
A lot of custom ROM modders would havethose apks deodex 'd, meaning the dex file is replaced and repackaged to makeit easier to theme/modify an apk.
When you flash a custom ROM, and did notwipe the cache, the newer custom ROM's apk's will have a different dex fileattached to it, and when the Dalvik goes through them, it sees the existingcached dex file found in the directory, and skips it, then when you run theapp, you're guaranteed a force close or ANR (Application Not Responding).
You are not losing data per se, if usingClockWorkMod Recovery, and Wipe Data is selected, then yes, all the settingsrelating 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 ithas the settings retained. This was quite a common scenario with CyanogenModnightlies where a unstable/testing ROM build is flashed, and the settingsretained with cache wipe. The mileage will vary depending on what appsdownloaded from the market (settings would have changed by version bump quitelikely).
For best results it would be wise toperform both Wipe Data and Wipe Cache to ensure integrity and no program errorswithin the app itself.
Yes that would mean the boot time would beslower 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 helpsspeed it up and ensure no residue from the previous version in place whichcould get munged in (Now at this stage, am realizing your question so in allfairness, have not actually seen Android not performing the invalidating of thecache 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 codefound in the dalvik directory tree which contains specific chipset instructionsto interpret the bytecode within the apk to native CPU instruction set. ARMv6is pretty much a hacked version of ARMv5 (which was the original chipset in theolder Android versions prior to Eclair), so you will not see ARMv6 in the AOSPsource from google. CyanogenMod will have that ARMv6 in their source.
For the sake of this discussion let'sassume that we're talking about an official CM7 release. Let me start by sayingthat I've never, ever wiped my dalvik cache and never experienced problems thatwould be solved by doing so. Because it's not odexed, there is no way there canbe multiple (o)dex files present, and thus on boot the old file is replaced bya newly generated one. Oh and if it's a really big deal why don't thedevelopers add this into the updater script? I will check out the source,thanks. – Richard Borcsik Jul 15 '12 at15:11
You can actually explicitly put that intothe updater-script, but that can piss others off when flashing because "Ohcrap, I lost my settings/data" and CM probably did not want to get burnedby the flame questions/answers as in "Why did you wipe my cache whenflashing a new release of CM?" - maybe its down to responsibility of CM sogave that option to the end user? And putting it back on them so that if theyflashed without wipe, and whine on the forums a lá "Hey my app iscrashing", CM can turn around and say "Did you wipe?" – t0mm13b Jul 15 '12 at 15:15
I didn't mean data/data butdata\dalvik-cache. Possibly just the system ones. – Richard Borcsik Jul 15 '12 at 15:18
1
Stock AOSP ROMs are odexed, CM havemodified the build system to use deodex.... just saying ;) – t0mm13b Jul 15 '12 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 '12 at 14:09
show 4 more comments