J'ai eu un problème similaire il n'y a pas si longtemps : le coupable semble être une application ART qui ne peut pas compiler pour une raison quelconque. Comme vous avez appliqué ma solution avec succès et que vous l'avez confirmée, permettez-moi de résumer les faits à partir des commentaires dans une réponse :
1. déterminer quelle application est le coupable.
À chacune de ces pannes, le système Android place une "pierre tombale" sur la "tombe" du processus mourant - ce que l'on appelle sur les systèmes Unix/Linux le "code". Core Dump . Ces vidages de noyau sont placés dans /data/tombstones
avec un maximum de 10 fichiers conservés (après cela, le plus ancien sera écrasé à la prochaine occasion). Nous devons donc regarder ces pierres tombales pour voir ce qui est écrit dessus. Comme vous avez une récupération personnalisée qui offre adb accès, le moyen le plus simple est :
-
adb pull /data/tombstones tombstones
(copiera le répertoire entier sur votre ordinateur)
- utilisez un visualiseur/éditeur de votre choix (le meilleur que vous connaissez) pour ouvrir et examiner chacune des pierres tombales, en commençant par la plus récente et en remontant le temps.
- regarder dans la "trace de la pile" pour voir si une application (ou son chemin d'accès en
/data/data
) y est mentionné. Si c'est le cas, notez-le. Si c'est la même application dans la pierre tombale suivante et celle d'après, vous pouvez être sûr que c'est le cas que nous décrivons ici.
2. mettre l'"obstacle" hors du chemin d'ART
Après avoir identifié l'application, nous devons la supprimer. art ne soit pas coincé avec ça. Pour cela, nous avons encore besoin adb shell
avec son Racine et le nom du répertoire de nos pierres tombales :
rm -rf /data/data/<whateveritwas>
Notez que cela supprime également toutes les données de l'application - il peut donc être judicieux d'avoir une sauvegarde à l'avance (dans l'état actuel : soit adb pull
le répertoire, ou faire un nandroid sauvegarde que vous pourrez analyser plus tard).
Ceci fait, redémarrez. Maintenant, "l'optimisation des applications" devrait se terminer avec succès.
Alternatives à l'approche en ligne de commande
Certaines restaurations personnalisées sont livrées avec un gestionnaire de fichiers intégré, généralement appelé "Aroma". Les étapes ci-dessus peuvent également être exécutées avec ce gestionnaire :
- naviguer vers
/data/tombstones
- voir les pierres tombales
- naviguer vers
/data/data
et retirer le délinquant
0 votes
Cela signifie généralement qu'il a des problèmes avec une application. Le site
cyanogenmod
tag me laisse supposer que vous avez une récupération personnalisée sur l'appareil. Démarre là-dedans. Avec un peu de chance, vous avez soit des capacités ADB, soit la restauration inclut un gestionnaire de fichiers (par exemple Aroma) ; twrp a les deux). Naviguez vers le dossier tombstone (généralement/data/tombstones
) et vérifiez le bloc "trace" des derniers fichiers. Je soupçonne qu'il mentionne toujours la même application/le même nom de paquet. Si c'est le cas, supprimez le répertoire de données de cette application (/data/data/<package_name>
). Le prochain démarrage devrait réussir. // J'ai eu ce problème récemment0 votes
Notez que cela signifie que vous perdrez également les données de cette application ! // Veuillez nous faire savoir si cela a fonctionné.
0 votes
@Izzy Cela semble être une bonne suggestion. Malheureusement, je ne suis pas un expert en la matière et mon gestionnaire de fichiers aromatiques ne fonctionne pas pour le moment. Il dit non
cwm/aromafm/aromafm.zip
dans le chemin". Toute aide pour l'installer serait la bienvenue. Je dispose deadb
yfastboot
accès mais je ne suis pas non plus un expert en la matière.0 votes
adb shell
entoncescd /data/tombstones
.ls
énumère les contenus. L'affichage de ces fichiers sur l'appareil serait évidemment un peu difficile pour vous, donc le plus simple serait de les transférer sur votre ordinateur :adb pull /data/tombstones tombstones
prendrait le dossier entier et le placerait sur votre PC. Ensuite, enquêtez avec les outils qui vous sont familiers. Après avoir trouvé le coupable, deadb shell
(en tant que Racine)rm -rf /data/data/<culprits-package-name>
. Pour sortir deadb shell
type, bien,exit
:)0 votes
Dans de rares cas, il peut s'agir d'une corruption du cache Dalvik/ART, voire d'une puce de stockage eMMC défectueuse. Honnêtement, à ce stade, je sauvegarderais toutes les données importantes et ferais une installation propre (tout effacer). Une des choses que toute personne utilisant une ROM personnalisée devrait être prête à faire à tout moment est d'effacer toutes les données et de réinstaller, cela va avec le mode de vie de la ROM personnalisée, pour ainsi dire.
0 votes
Merci @Izzy. J'ai pu résoudre le problème en utilisant votre suggestion. J'ai essayé quelques étapes supplémentaires. J'ai flashé "Aroma file manager" parce que ce n'était pas installé dans ma récupération Phill Z. Une chose à noter est que Aroma File Manager a dû être flashé deux fois (en utilisant l'installation zip à partir de la mémoire externe) ; ainsi il m'a permis d'accéder à
/data/tombstones
ainsi que/data/data/<Package_name>
. J'ai non seulement supprimé les paquets problématiques, mais aussi certains dossiers inutilisés qui traînaient là. Viola ! Je voudrais en faire une réponse si @Izzy peut poster ce commentaire comme réponse. Merci !0 votes
\o / Heureux d'avoir fait mouche avec mon marteau :) J'ai tout résumé en une réponse comme demandé. Profitez du renouveau :) // @acejavelin s'il s'agissait d'un cache Dalvik/ART corrompu, les "applications d'optimisation" auraient dû le réparer : ne reconstruit-il pas le même cache ? Mais l'idée de la sauvegarde est un bon rappel :) Et votre conseil de "se préparer" ne s'applique pas seulement aux ROMs personnalisées : être sur une telle ROM a souvent une autre "porte dérobée" (grâce à Root) qu'un "utilisateur de stock commun" n'a pas