Tuve un problema similar no hace mucho tiempo: el culpable parece ser alguna aplicación ART no puede compilar por alguna razón. Como usted aplicó con éxito mi solución y confirmó, permítame resumir los hechos de los comentarios en una respuesta:
1. averiguar qué aplicación es la culpable.
En cada una de esas caídas, el sistema Android coloca una "lápida" en la "tumba" del proceso moribundo - algo conocido en los sistemas Unix/Linux como Vertedero de núcleos . Esos vertidos del núcleo se colocan en /data/tombstones , con un máximo de 10 archivos guardados (después, el más antiguo se sobrescribirá en la siguiente ocasión). Así que tenemos que mirar a esas lápidas para ver lo que está escrito en ellas. Como tienes un recovery personalizado que ofrece adb acceso, la forma más fácil es:
adb pull /data/tombstones tombstones (copiará todo el directorio en su ordenador)- Utiliza un visor/editor de tu elección (mejor uno con el que estés familiarizado) para abrir e investigar cada una de las lápidas, empezando por la más reciente y retrocediendo.
- mirar el "stack trace" para ver si una aplicación (o su ruta en
/data/data ) se menciona allí. Si es así, anótelo. Si es la misma aplicación en la siguiente lápida y en la que le sigue, puedes estar bastante seguro de que es el caso que estamos describiendo.
2. quitar el "obstáculo" del camino del ARTE
Una vez identificada la aplicación, tenemos que eliminarla para arte no se queda con él. Para ello, de nuevo necesitamos adb shell con su root y el nombre del directorio de nuestras lápidas:
rm -rf /data/data/<whateveritwas>
Tenga en cuenta que esto elimina todos los datos de la aplicación también - por lo que tener una copia de seguridad de antemano podría ser una buena idea (en el estado actual: ya sea adb pull el directorio, o hacer un nandroid copia de seguridad que puede analizar más tarde).
Hecho esto, reinicia. Ahora la "optimización de aplicaciones" debería terminar con éxito.
Alternativas a la línea de comandos
Algunas recuperaciones personalizadas vienen con un gestor de archivos integrado, normalmente llamado "Aroma". Los pasos anteriores también se pueden realizar con él:
- navegar hasta
/data/tombstones
- ver las lápidas
- navegar hasta
/data/data y eliminar al infractor
0 votos
Eso suele significar que tiene problemas con una aplicación. El
cyanogenmodLa etiqueta me permite asumir que tienes un recovery personalizado en el dispositivo. Arranca en él. Espero que tengas capacidades ADB allí, o que el recovery incluya un gestor de archivos (por ejemplo, Aroma; twrp tiene ambos). Navegue hasta la carpeta de la lápida (normalmente/data/tombstones) y comprueba el bloque "trace" de los últimos archivos. Sospecho que siempre menciona la misma aplicación/nombre de paquete. Si es así, borra el directorio de datos de esa app (/data/data/<package_name>). El próximo arranque debería tener éxito. // Yo mismo tuve eso recientemente0 votos
Ten en cuenta que eso significa que también perderás los datos de esa aplicación. // Por favor, háganos saber si eso funcionó.
0 votos
@Izzy Parece una buena sugerencia. Por desgracia, no soy tan experto y mi gestor de archivos de aroma no funciona ahora mismo. Dice que no
cwm/aromafm/aromafm.zipen el camino". Cualquier ayuda para instalarlo sería genial. Tengoadbyfastbootacceso pero tampoco soy tan experto en eso.0 votos
adb shellentoncescd /data/tombstones.lsenumera los contenidos. Ver esos archivos en el dispositivo sería obviamente un poco complicado para ti, así que lo más fácil sería llevarlos a tu ordenador:adb pull /data/tombstones tombstonessacaría toda la carpeta y la colocaría en su PC. Luego investiga con las herramientas que conoces. Una vez encontrado el culpable, deadb shell(como Root)rm -rf /data/data/<culprits-package-name>. Para salir deadb shelltipo, bueno,exit:)0 votos
En raras ocasiones, esto podría ser la corrupción de la caché Dalvik/ART, posiblemente incluso un chip de almacenamiento eMMC defectuoso. Honestamente, en este punto yo haría una copia de seguridad de los datos que son importantes y una instalación limpia (borrar todo). Una de las cosas que cualquier persona en una ROM personalizada debe estar preparado para hacer en cualquier momento es borrar todos los datos y volver a instalar, tipo de va con todo el "rom personalizado" forma de vida, por así decirlo.
0 votos
Gracias @Izzy. Pude resolver el problema usando tu sugerencia. Probé algunos pasos adicionales. He flasheado "Aroma file manager" porque no estaba instalado en mi Phill Z recovery. Una cosa a tener en cuenta fue que Aroma File Manager tuvo que ser flasheado dos veces (utilizando zip instalar desde la memoria externa), por lo que me permitió el acceso a
/data/tombstonesasí como/data/data/<Package_name>. No sólo eliminé los paquetes problemáticos, sino que también eliminé algunas carpetas desordenadas que estaban ahí sin usar. ¡Viola! Me gustaría hacer esto como respuesta Si @Izzy puede publicar este comentario como respuesta. ¡Gracias!0 votos
\o / Me alegro de haber dado en el clavo con mi martillo :) Resumí todo en una respuesta como se pedía. Disfruta de la reactivación :) // @acejavelin si fuera una caché Dalvik/ART corrupta, la "optimización de aplicaciones" debería haber arreglado eso: ¿eso no reconstruye la misma caché? Pero definitivamente la idea de la copia de seguridad es un buen recordatorio :) Y tu sugerencia de "estar preparado" no sólo se aplica a las ROMs personalizadas: estar en una de ellas a menudo tiene otra "puerta trasera" (gracias a Root) que un "usuario común de stock" no tiene