¿Por qué necesito borrar la caché Dalvik?
Para responder a tus preguntas:
-
No conozco ninguna versión de Android en la que el Dalvik no se haya invalidado en el arranque. Quizás la versión inicial 1.0 tenía eso, realmente no lo sé, han pasado por Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Hay que buscar en el árbol de fuentes y volver a basarse en CupCake o Donut (1.5 y 1.6 respectivamente)
-
La razón detallada 🙂
La razón por la que hay que usar el Wipe Cache es porque todas las apks, incluidas las de sistema, tienen un archivo dex adjunto, cuando se arranca la ROM por primera vez, el Dalvik de Android recorre todas y cada una de esas apks, y extrae el archivo dex de la misma y lo coloca en la caché /data/dalvik-cache
acelerando así la ejecución de la propia app.
La mayoría de las ROMs tienen apks que son odex ‘ed, la caché se incluye en el propio apk como un archivo externo.
Una gran cantidad de modders de ROMs personalizadas tendrían esos apks deodex ‘d, lo que significa que el archivo dex es reemplazado y reempaquetado para que sea más fácil de tema / modificar un apk.
Cuando se flashea una ROM personalizada, y no se limpia la caché, los apk’s de las ROMs personalizadas más recientes tendrán un archivo dex diferente adjunto, y cuando el Dalvik los revisa, ve el archivo dex existente en la caché que se encuentra en el directorio, y lo salta, entonces cuando se ejecuta la aplicación, se garantiza un cierre forzado o ANR (Application Not Responding).
Usted no está perdiendo los datos en sí, si se utiliza ClockWorkMod Recovery, y Wipe Data está seleccionado, entonces sí, todos los ajustes relacionados con las aplicaciones se limpian – mira en /data/app
.
Así que usted puede Wipe Cache pero no Wipe Data, lo que se hace efectivamente, es ranurado en los apks más nuevos en su lugar, en el que tiene la configuración retenida. Este fue un escenario bastante común con nightlies CyanogenMod donde un inestable / prueba de la ROM construir es flasheado, y los ajustes retenidos con la limpieza de la caché. El kilometraje variará dependiendo de lo que las aplicaciones descargadas desde el mercado (ajustes habrían cambiado por la versión bump bastante probable).
Para obtener los mejores resultados sería conveniente realizar tanto el Wipe Data como el Wipe Cache para asegurar la integridad y que no haya errores de programa dentro de la propia aplicación.
Sí, eso significaría que el tiempo de arranque sería más lento, pero su momento inicial. Después de eso sería arrancar más rápido. Realmente en una cáscara de nuez, limpiando explícitamente la memoria caché en sí a través de CWM en realidad ayuda a acelerar y garantizar ningún residuo de la versión anterior en el lugar que podría conseguir munged pulg (Ahora en esta etapa, estoy dando cuenta de su pregunta por lo que en toda la justicia, no han visto realmente Android no realizar la invalidación de la memoria caché en sí en el arranque al flashear una nueva ROM ..)
Usa el código fuente Luke en serio! 😀
frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
es el código de arranque para cada apk runtime. Interactúa con el código C nativo que se encuentra en el árbol de directorios dalvik
que contiene instrucciones específicas del chipset para interpretar el bytecode dentro del apk al conjunto de instrucciones nativas de la CPU. ARMv6 es más o menos una versión hackeada de ARMv5 (que era el chipset original en las versiones más antiguas de Android antes de Eclair), por lo que no verá ARMv6 en la fuente AOSP de google. CyanogenMod tendrá que ARMv6 en su fuente.