Trying to answer to a question about Dalvik Cache, many things are not yet clear about it. We will try to explain each the Dalvik Cache and How Safe It Is. So the main question is:
How Safe It Is?
- Dalvik Optimization
- Wiping Dalvik Cache
First I would like to tell you that Dalvik Cache it is a different thing from Dalvik. Dalvik is Virtual Machine that uses a register-based architecture that requires fewer instructions. Applications for Dalvik are written in Java using the Android Application Interface (API). Then the application are compiled using Java bytecode and then when they have to run on an Android smartphone are converted again to Dalvik bytecode.
Conversion is done by a tool called dx, that converts Java .class files into the .dex format. Then when applications has to run, the .dex file is optimized for you Android device and it is converted into .odex file. The optimization is done only the first time when code is used. For example constant pool references are replaced with pointers to internal data structures, operations that always succeed or always work a certain way are replaced with simpler forms. See what Dalvik optimizer does:
The Dalvik optimizer does the following:
- For virtual method calls, replace the method index with a vtable index.
- For instance field get/put, replace the field index with a byte offset. Also, merge the boolean / byte / char / short variants into a single 32-bit form (less code in the interpreter means more room in the CPU I-cache).
- Replace a handful of high-volume calls, like String.length(), with “inline” replacements. This skips the usual method call overhead, directly switching from the interpreter to a native implementation.
- Prune empty methods. The simplest example is
Object.<init>, which does nothing, but must be called whenever any object is allocated. The instruction is replaced with a new version that acts as a no-op unless a debugger is attached.
- Append pre-computed data. For example, the VM wants to have a hash table for lookups on class name. Instead of computing this when the DEX file is loaded, we can compute it now, saving heap space and computation time in every VM where the DEX is loaded.
All modifications usually involve replacing the opcode with one not defined by the Dalvik specification. This allows to optimize unoptimized instructions. Optimization is tied closely to the VM version.
In most cases these optimizations are safe and a need for your Android device, usually resulting more quickly to execute the app and saving disk space. Yes there can be trouble, like vtable and byte offsets can be outdated if the VM is updated. Also a superclass in a different DEX if the other DEX was updated. Usually these problems are addressed with dependency lists.
Wiping Dalvik Cache
The reason the to Wipe Dalvik Cache is used is because all apk (applications) including system apks have a dex file attached to them. When the new ROM is bood for the first time the Dalvik will go through each of apk and extract the dex file from it and will optimize it and will save it as .odex in the /data/dalvik-cache. This will speed up the execution of the app itself.
Unfortunately when installing a custom moded ROM, we know that most modders have apks deodex’d, meaning that the dex file is replaced and repackaged to make it easier to theme and modify the apk.
When you will flash a custom ROM and did not wipe the cache, the newer custom ROM apks will have an old version of dex file attached to them. Dalvik will scan and find the dex file and will consider not to create a new one and replace it, it will skip thiese apps with dex files.
As a result when you will run the app, you will get a guaranteed a force close or ANR (Application Not Responding) error message.
To Wipe Cache safely you will have to use ClockWorkMod Recovery, with it you will be able to Wipe Cache but not Wipe Data. But for getting the best results you will have to lose the application data, using the both Wipe Data and Wipe Cache will ensure the integrity of the apk and no program errors within the app itself.
The only thing it is that the first boot time will be slower, because will cache the dex files, but once this is done the next time the boot will be much quicker.