Pour répondre à vos questions :

• Je ne connais aucune version d’Android où le Dalvik n’était pas invalidé au démarrage. Peut-être que la version initiale 1.0 avait cela, je ne sais vraiment pas, sont passés par Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Vous devez regarder dans l’arbre des sources et le rebaser en CupCake ou Donut (1.5 et 1.6 respectivement)

• La raison détaillée 🙂

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

La plupart des ROMs ont des apks qui sont odex ‘ed, le cache est regroupé dans l’apk lui-même comme un fichier externe.

Beaucoup de moddeurs de ROM personnalisées auraient ces apks deodex ‘d, ce qui signifie que le fichier dex est remplacé et reconditionné pour faciliter le thème/modification d’un apk.

Lorsque vous flashez une ROM personnalisée, et que vous n’avez pas effacé le cache, les apk des ROM personnalisées plus récentes auront un fichier dex différent attaché à elles, et lorsque le Dalvik les parcourt, il voit le fichier dex existant en cache trouvé dans le répertoire, et le saute, puis lorsque vous exécutez l’app, vous êtes garanti 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 Wipe Data est sélectionné, alors oui, tous les paramètres relatifs aux apps sont effacés proprement – regardez dans /data/app.

Donc vous pouvez effacer le cache mais pas les données, ce qui est fait effectivement, est glissé dans les apks plus récents en place, dans lesquels il a les paramètres conservés. C’était un scénario assez commun avec les nightlies CyanogenMod où une ROM instable/testing build est flashée, et les paramètres conservés avec le cache wipe. Le kilométrage variera en fonction des apps téléchargées sur le marché (les paramètres auraient changé par bump version tout à fait probable).

Pour de meilleurs résultats, il serait sage d’effectuer à la fois Wipe Data et Wipe Cache pour s’assurer de l’intégrité et de l’absence d’erreurs de programme dans l’app elle-même.

Oui cela signifierait que le temps de démarrage serait plus lent mais son moment initial de mise en route. Après cela, le démarrage serait plus rapide. Vraiment en un mot, effacer explicitement le cache lui-même via CWM aide en fait à l’accélérer et à s’assurer qu’il n’y a pas de résidus de la version précédente en place qui pourraient être munged in (Maintenant à ce stade, réalise votre question donc en toute équité, n’ont pas réellement vu Android ne pas effectuer l’invalidation du cache lui-même au démarrage lors du flashage d’une nouvelle ROM…).

Utiliser le source Luke sérieusement ! 😀

frameworks/base/core/java/com/android/internal/os/ZygoteInit.java est le code de démarrage pour chaque runtime apk. Il interagit avec le code C natif trouvé dans l’arbre de répertoire dalvik qui contient des instructions spécifiques au chipset pour interpréter le bytecode dans l’apk vers le jeu d’instructions natif du CPU. ARMv6 est à peu près une version piratée de ARMv5 (qui était le chipset original dans les anciennes versions d’Android avant Eclair), donc vous ne verrez pas ARMv6 dans la source AOSP de google. CyanogenMod aura cet ARMv6 dans leur source.