[Galaxy S 4 i9505 Android Development] Bejda:
I'm not sure wipe dalvik-cache is useful when installing a new kernel nor even,except maybe and rarely under some specifics issues or situations,something that really needs to be triggered by users..at least not that often and not let's say "blindly"/without knowing exactly why as it is most of the time done by users or recommended on some threads (not that i really know much about this,just my impressions based on the little i could notice or thought i understood so if anyone knows more he's welcome :) )

Android itself handles the dalvik-cache rebuild when we install a new or different rom version.

Let's take a CM nightly,if we reflash same nightly version there's no dalvik-cache rebuild (at least no "Android upgrading>optimizing apps" process at boot). It only happens if you update to next nightly,flash one from another date or flash a different (build by "someone else" even if based on same nightly) CM based rom without any wipe.

So i would presume that's the only situation (new or different rom version detected then) where dalvik-cache rebuild is probably really needed (except as i said if we think it may solves a specific issue or whatever) and Android apparently handles this for us.

I would presume that this new/different Android build detection process that triggers a dalvik-cache rebuild relies on some /system/framework/ files,maybe most probably only some .jar files but that's just a wild guess based on something else i noticed (something that can't be considered as directly related but that leads me to think that yeah framework .jar files are the ones,when new or different version detected,that can trigger a dalvik-cache rebuild event...or something more or less approaching lol) :

My example is based on allowing Samsung store to run on CM/aosp custom builds.That needs,among some others files,to install twframework.jar file under our CM/aosp /system/framework/ folder.

If you push this twframework "external/new/different" .jar file (and only this one for now just for the test) to your /system/framework folder you get the "Android upgrading>optimize apps" process at next boot (but strangely only for users apps apparently [ I'm a little :confused: here lol ] , every time i tested this the amount of "optimizing apps" was more or less corresponding to the amount of /data/apps i had installed...it wasn't the whole

"optimizing apps" that seems to include /data/app , /system/(priv-)app and /system/framework apk&jar that we have when flashing a new build or wipe dalvik-cache).

Late Edit for future personal references: A better or simplier example would have been gapps.. If you flash a minimal gapps which contains about 10 apps or priv-apps of course you'll get the "Android upgrading:eek:ptimizing apps" but here also for all your user's apps,not only this 10 new apps. Probably because gapps also pushes some new /system/framework/***.jar files just like the twframework.jar example right above but about same story than reflashing same build version if you reflash gapps when already installed: no dalvik-cache rebuild/android optimizing process.

To get back a little to the "does install a new kernel needs a dalvik-cache rebuild" matter lol from my relatively noob's point of view i really can't see why it would be needed.

Only things that may interferes i guess could be some previous custom kernel left-over files or previous custom kernel version settings files (as sometimes stated on Alucard kernel thread for instance: "Ramdisk changes so please delete your /data/.alucard folder before flashing new version" or such specific instructions).

For this left over files or apks there's some dedicated "kernel cleaning" cwm zip or scripts threads,there's at least one that seems to be active and up to date on xda S4 section.

Here again I'm not sure cleaning scripts are really useful (sorry if hurts some to read this or if I'm totally wrong,here again that's just my guesses),i mean if some left over files belongs to previously installed kernel the newly installed one will most probably just ignore them unless both kernels share some common mechanisms or same dedicated tweaker apk.

But useful or not the fact that this mentioned above "kernel cleaning" solution thread is active and often updated shows at least that it's seriously done (having to monitor all existing S4 kernels evolution and all must be an harassing job..)

I should precise that i'm not the most used to custom kernel usage on S4. I come from i9000 where boot.img comes with recovery.img bundled so custom kernel usage was a more useful or at least fun part. On S4,as recovery choice is independent,i never felt a real need for now to play with custom kernels at least on CM/aosp custom builds but that just depends of my intellectual interest of the moment if i can say. Maybe I'll find fun into following custom kernels development again someday..

Back to /cache and /dalvik-cache now.. :o

I never really understood the need for wipe cache also but i would appreciate to know more..

What do we have here (should be about the same for everyone i guess):

/cache/lost+found/

(normally/if everything is fine actually should be an empty folder,i never really understood its purpose but Google is a nice buddy to have lol https://www.google.fr/search?hl=en-...fe_rd=cr&ei=pnrKU4_DJYPZ8gfP24C4Cg&gws_rd=ssl ) From what we see it's only populated if our or one of our filesystem gets corrupted,folder itself will be recreated at boot but why wipe it if empty and if populated it would be for "safety" reasons so...

/cache/backup/

Well maybe I've lost myself at some point and I'm missing the obvious now but right now i don't know or remember its purpose.

Normally empty(?) but maybe used under some specifics operations dunno..maybe it's also part of a safety process like lost+found is..no idea.

The big size of our device's cache partition (about 2gb) is because it's used for Samsung OTA updates download afaik,maybe that /backup folder exists for something related..dunno.

/cache/recovery/

This one stores some recovery logs. They never hurt anyone,on the contrary.

Can't we keep them please? :)

Now there's something that may differs depending on roms and concerns both /cache and dalvik-cache...dalvik-cache location:

The usual or commonly used location would be /data/dalvik-cache but,for the device i know which is S4,some CM/aosp custom builds also use /cache/dalvik-cache location but only dedicated to system apps and system/framework .jar files.

If no /cache/dalvik-cache all classes.dex files are under /data/dalvik-cache.

Anyway for our story (erm..which story was it exactly btw? lol) it doesn't really matter. From what i could see the wipe dalvik-cache command wipe both /data/dalvik-cache and /cache/dalvik-cache if it exists (Aroma file manager to do the before&after check).

So i wonder what's left on our device's cache partition that really needs to be wiped that much often..

About the same interrogation for dalvik-cache..

Sorry for the long post and sorry [MENTION=3051954]phil.o[/MENTION] that i mentioned you almost as an excuse to place some of my observations and interrogations lol ;)

This post may sound like a post from a "guy that think he knows stuffs but actually knows nothing" lol but i don't care i'm in a posting-mood :P

More seriously i'm not on xda on an ego-trip,if i or anyone can learn things from the following discussions it might trigger I'll be glad :)

Precisions,corrections,unfriendly invalidations...They're all welcome :)

Edit: Just remembered the initial discussion :laugh:...Well considering my previous observations i can't see the direct relation between /cache and dalvik-cache, can't see why they should be wiped together and i'd say that users having to, at least try to, know what they are doing fits more with Philz recovery philosophy than a "blind" "let's wipe cache and dalvik all together".