Pourquoi dois-je nettoyer le cache Dalvik?

Lorsque je mets à jour une ROM personnalisée, il y a toujours une instruction pour effacer le cache Dalvik . Je ne vois pas pourquoi cela est nécessairement nécessaire.

En regardant le logcat pendant le démarrage du système, je peux clairement voir que si une application est modifiée, son dexfichier est invalidé puis régénéré. Pourtant, quand je mentionne cela n'importe où, je suis confronté au silence. Comme si même certains développeurs de ROM ne le savaient pas et ne le faisaient que parce que tout le monde le savait.

Alors les questions:

• Existe-t-il une version Android où les fichiers Dalvik n’ont pas été invalidés au démarrage?
• Y at-il un avantage à le faire soi-même, au lieu de laisser le système faire le travail qu’il est supposé faire?

Une réponse idéale inclurait des références au code pertinent, alors j'aurais une référence la prochaine fois que cela se produirait.

Pour répondre à tes questions:

• Je ne suis au courant d'aucune version Android où Dalvik n'a pas été invalidé au démarrage. Peut-être que dans la version initiale 1.0, je ne sais vraiment pas, avaient passé par Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Vous devez examiner l’arbre source et le redéfinir en CupCake ou Donut (1.5 et 1.6 respectivement).

• La raison détaillée :)

La raison pour laquelle le cache Wipe doit être utilisé est parce que tous les apks, y compris les apks système, ont un fichier dex attaché. Lorsque la ROM est démarrée pour la première fois, le Dalvik d'Android passe en revue chacun de ces apks et les extrait. le fichier dex à partir de celui-ci et placez-le dans le cache /data/dalvik-cache, accélérant ainsi l'exécution de l'application elle-même.

La plupart des ROM ont des apks odex 'ed, le cache est intégré à l'apk lui-même en tant que fichier externe.

Un grand nombre de modders ROM personnalisés auraient ces apks deodex 'd, ce qui signifie que le fichier dex est remplacé et reconditionné pour faciliter le thème / modifier un apk.

Lorsque vous flashez une ROM personnalisée sans effacer le cache, les apk de la ROM personnalisée plus récente sont associés à un fichier dex différent , et lorsque Dalvik les examine, il voit le fichier dex mis en cache existant situé dans le répertoire, et saute, puis lorsque vous exécutez l'application, vous êtes assuré d'une fermeture forcée ou ANR (Application Not Responding).

Vous ne perdez pas de données en soi, si vous utilisez ClockWorkMod Recovery et que l'option Effacer les données est sélectionnée, alors, oui, tous les paramètres relatifs aux applications sont effacés proprement - regardez /data/app.

Ainsi, vous pouvez effacer le cache mais pas effacer les données , ce qui est fait efficacement, est inséré dans le nouvel apks en place, dans lequel les paramètres sont conservés. Ce scénario était assez courant avec les nightlies de CyanogenMod dans lequel une version instable / en cours de test de la ROM était clignotée et les paramètres conservés avec la suppression du cache. Le kilométrage variera en fonction des applications téléchargées sur le marché (les paramètres auraient très probablement changé avec la version bosse).

Pour de meilleurs résultats, il serait sage d'effectuer à la fois l' effacement des données et l' effacement du cache afin de garantir l'intégrité et d'éviter les erreurs de programme au sein de l'application elle-même.

Oui, cela signifierait que le temps de démarrage serait plus lent, mais son moment initial unique. Après cela, le démarrage serait plus rapide. En un mot, effacer explicitement le cache lui-même via le MCG contribue à l’accélérer et à ne laisser aucun résidu de la version précédente en place susceptible de se trouver dans la mémoire (à ce stade, je réalise votre question de façon honnête, vu qu'Android n'effectue pas l'invalidation du cache lui-même au démarrage lors du flashage d'une nouvelle ROM ..)

Utilisez la source Luke au sérieux! :RÉ

frameworks/base/core/java/com/android/internal/os/ZygoteInit.javaest le code de démarrage pour chaque exécution apk. Il interagit avec le code C natif trouvé dans l’ dalvikarborescence de répertoires, qui contient des instructions de jeu de puces spécifiques permettant d’interpréter le bytecode contenu dans le jeu d’instructions apk to native CPU. ARMv6 est à peu près une version piratée d’ARMv5 (qui était le chipset original dans les versions antérieures d’Android avant Eclair), vous ne verrez donc pas ARMv6 dans le code source AOSP de Google. CyanogenMod aura cet ARMv6 dans sa source.