Return to Answer

Based on my experience this problem usually occurs as a result of faulty (or incorrect) permissions in the dalvik cache.

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)

• After an upgrade of an Android version  ,the issue can surface if Android system is trying to creating 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.

• An "used" odex file is still present even though that particular application is deoxeded . Certain apps (e.g Link2sd, Lucky Patcher, Titanium backup etc) that intergrate 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 ocurs (from rooting or unrooting vice versa) it keeps trying to to peform optimisation of the applications(s).

3. Unistalling problematic application(s)

• Try getting rid of posible culprits esp those that require root by simply uninstalling such applications.
• Alteratively try deodexing the applications with a suitable tool, to allow Android Virtual machine to reoptimise the applications at next reboot.

• If none of these seem fixing the issue, then you might have the highest probablity of fixing the issue by reflashing your device with stock ROM.
• Get the appropiate stock ROM file and reflash to clear essentially everything and rewriting the partitions with "fresh data" Note back up important data first!

Based on my experience, this problem usually occurs as a result of faulty (or incorrect) permissions in the dalvik cache.

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)

• 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).

3. 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.

• 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!

2. Resetting dalvik cache

Several users have suggested to use this method by employing a file explorer to delete the folder:

.

2. 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:

For many users its the app titanium backup odex file that causes the issue but there can be other programs.

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 davlik 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.

• After an upgrade of an Android version ,the issue can surface if Android system is trying to creating 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.

• An "used" odex file is still present even though that particular application is deoxeded . Certain apps (e.g Link2sd, Lucky Patcher, Titanium backup etc) that intergrate 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 ocurs (from rooting or unrooting vice versa) itkeeps trying to to pefrom optimisation of the applications(s).

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.

• After an upgrade of an Android version ,the issue can surface if Android system is trying to creating 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.

• An "used" odex file is still present even though that particular application is deoxeded . Certain apps (e.g Link2sd, Lucky Patcher, Titanium backup etc) that intergrate 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 ocurs (from rooting or unrooting vice versa) it keeps trying to to peform optimisation of the applications(s).