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.
Answer
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.
No comments:
Post a Comment