Based on my experience, this problem usually occurs as a result of faulty (or incorrect) permissions in the dalvik cache.
How does optimisation work?
When the Android system is "optimising apps/system", it will be creating an optimised version of each application. This process makes each app start as
fast as possible with the new Android version.
When an .apk file is added to an Android system, it is converted to an odex (Optimised Dalvik Executable) file whose function mainly is to save space. Unlike the odexed file, a deodexed file
essentially has all parts assembled in one place into classes.dex files (just Dalvik Executable)
Android uses Android Runtime (ART) for running applications (in ealier
android verisons - Dalvik Virtual Machine to maintain backward
compatibility , ART uses the same input bytecode as Dalvik, supplied
through standard .dex files as part of APK files , while the .odex
files are replaced with Executable and Linkable Format (ELF)
executables).
Now, when an Android-based system is booting, the dalvik cache for the
Dalvik VM is built using these .odex files, allowing the OS to learn
in advance what applications will be loaded, and thus speeds up the
booting process.
Situations in which the problem arises
After an upgrade of an Android version, the issue can surface if Android system is trying to create a new dalvik cache for the apps but the still has the "old cache" for such an application, hence tries to constantly create a new cache on top of the old one.
A "used" odex file is still present even though that particular application is deoxeded . Certain apps (e.g Link2sd, Lucky Patcher, Titanium backup etc) that integrate dalvik cache in system partition can cause such issues.
In one case, it resulted when Titanium backup created a patch that created an .odex file in /system/apps.
this problem resulted.
- Rooting/Unrooting of the device can result in modification of data in the dalvik cache of a certain application, such that when the change of state occurs (from rooting or unrooting vice versa), it keeps trying to perform optimisation of the application(s).
Possible fixes
- Wiping data and cache
No. You can try wiping your cache partition:
Turn off your device
Press a combination of Vol + + Vol - + Power key buttons and hold them down.
Release only the Power button when the device vibrates
Release the other buttons when the Recovery Menu screen appears
Using the Vol +/Vol - buttons to navigate, select Wipe cache partition
Press the Power key , which will act the enter key on your keyboard.
Wait for the process to finish.
You can then reboot the device and see if your problems are fixed
- Resetting dalvik cache permissions
Another user has offered a concise explanation:
This problem is caused when there are .odex files in /data/app
folder than have permissions set so system can't write to them during
the optimization process.
In this case, setting correct permissions can resolve this matter:
- Set correct permissions i.e
rw- r-- r-- for odex files in /data/app ( or /system/app ) folder
Several users have suggested to use this method by employing a file explorer to delete the folder:
Use a file explorer with root access or adb shell and delete the
folder dalvik-cache found inside /data (or rm -r -f /data/dalvik-cache
from adb shell)
Uninstalling problematic application(s)
- Try getting rid of possible culprits, especially those that require root, by simply uninstalling such applications.
- Alternatively, try deodexing the applications with a suitable tool, to allow Android Virtual machine to reoptimise the applications at next reboot.
For many users its the app titanium backup odex file that causes the
issue but there can be other programs.
Reflashing stock ROM
- If none of these seem fixing the issue, then you might have the highest probability of fixing the issue by reflashing your device with stock ROM.
- Get the appropriate stock ROM file and reflash to clear essentially everything and rewriting the partitions with "fresh data"
Note back up important data first!
References
