Question:
"com.android.phone has stopped" after dirty flashing CM13
friederbluemle
2015-11-25 23:11:25 UTC
view on stackexchange narkive permalink

Après avoir flashé sale mon OnePlus One (bacon) de CM12.1 à CM13, je reçois constamment des fenêtres de dialogue de fermeture forcée 

  Malheureusement, le processus com.android.phone s'est arrêté

Logcat est rempli de stacktraces comme celui-ci: 

  Arrêt de VMFATAL EXCEPTION: mainProcess: com.android.phone, PID: 13148java.lang.RuntimeException: Impossible d'obtenir provider com.android.providers.telephony.TelephonyProvider: java.lang.IllegalStateException: impossible de lire la ligne 0, col -1 à partir de CursorWindow. Assurez-vous que le curseur est correctement initialisé avant d'accéder à ses données. à android.app.ActivityThread.installProvider (ActivityThread.java:5205) à android.app.ActivityThread.installContentProviders (ActivityThread.java:4797) à android.app.ActivityThread.handleBindApplication (ActivityThread.java:4737) à android.app. ActivityThread.-wrap1 (ActivityThread.java) à android.app.ActivityThread $ H.handleMessage (ActivityThread.java:1424) à android.os.Handler.dispatchMessage (Handler.java:102) à android.os.Looper.loop ( Looper.java:148) sur android.app.ActivityThread.main (ActivityThread.java:5466) sur java.lang.reflect.Method.invoke (méthode native) sur com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run ( ZygoteInit.java:726) à com.android.internal.os.ZygoteInit.main (ZygoteInit.java:616) Causé par: java.lang.IllegalStateException: impossible de lire la ligne 0, col -1 à partir de CursorWindow. Assurez-vous que le curseur est correctement initialisé avant d'accéder à ses données. à android.database.CursorWindow.nativeGetString (méthode native) à android.database.CursorWindow.getString (CursorWindow.java:438) à android.database.AbstractWindowedCursor.getString (AbstractWindowedCursor.java:51) à com.android.providers .TelephonyProvider $ DatabaseHelper.getStringValueFromCursor (TelephonyProvider.java:993) à com.android.providers.telephony.TelephonyProvider $ DatabaseHelper.copyPreservedApnsToNewTable (TelephonyProvider.java:905)
à com.android.providers.telephony.TelephonyProvider $ DatabaseHelper.onUpgrade (TelephonyProvider.java:641) à android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:256) à android.database.sqliteHelper.getDatabaseLocked (SQLiteOpenHelper.java:256) à android.database.sqliteHperabase. .java: 187) sur com.android.providers.telephony.TelephonyProvider.onCreate (TelephonyProvider.java:1457) sur android.content.ContentProvider.attachInfo (ContentProvider.java:1748) sur android.content.ContentProvider.attachInfo (ContentProvider. java: 1723) sur android.app.ActivityThread.installProvider (ActivityThread.java:5202) ... 10 de plus

Une fois que je me suis débarrassé de la fenêtre contextuelle persistante de l'interface utilisateur, il semble que com.android.phone plante au moins 10 fois par seconde, inondant logcat et rendant presque impossible l'utilisation du téléphone.

Y a-t-il un espoir pour un correctif, ou est-il une réinitialisation matérielle est la seule option?

Effacez les données pour `com.android.providers.telephony` (l'application porte le nom" Téléphone / Stockage de téléphonie / fournisseurs "). Pendant que vous y êtes, faites-le également pour l'application Phone (`com.android.phone`), redémarrez et dites-nous les résultats. Il semble que la base de données de «com.android.providers.telephony» ne puisse pas être lue. Il est possible que vous ne puissiez pas effacer les données de ces applications. Dans ce cas, supprimez leurs répertoires / data / data de la surface de la terre.
Effacer le cache (de la récupération) peut aider
J'ai essayé de supprimer ces dossiers en utilisant Total Commander en mode racine. J'ai réussi à supprimer mais cela n'a pas aidé. J'ai aussi fait un redémarrage: (Je ne peux appeler personne ...
Cinq réponses:
Aaahh
2015-11-26 13:27:53 UTC
view on stackexchange narkive permalink

Cela était dû à une modification du code.

Comme Firelord l'a dit, effacez les données des applications. Cela peut être fait comme ceci ( cela supprimera également vos SMS / MMS assurez-vous de les sauvegarder au préalable ): 

  adb shellrm -fr /data/data/com.android.providers.telephony/rm -fr / data / data / com.android.phone/exit

L'indicateur -f est pour la force et l'indicateur -r signifie récursif.

Ça a marché! Merci. J'ai également remarqué cette ligne dans mon logcat: `TelephonyProvider: dbh.onUpgrade: + db = SQLiteDatabase: /data/user/0/com.android.providers.telephony/databases/telephony.db oldV = 1114120 newV = 1376264` Après suppression le répertoire de données et un redémarrage, les boîtes de dialogue de fermeture forcée se sont arrêtées. Qu'y avait-il dans la base de données? J'ai remarqué que tous mes SMS avaient disparu. Rien d'autre?
** Lecteurs: ** assurez-vous de redémarrer l'appareil après avoir supprimé ces répertoires.
Fait intéressant, il n'a pas été possible de supprimer les données du menu de l'application. J'avais besoin de redémarrer dans TWRP et de supprimer le dossier (le premier était suffisant)
Cette méthode ne fonctionne pas pour Cyanogenmod 14 / Android 7
@Adem Nov, quel est le logcat?
J'ai purgé cm14 et réinstallé cm13 parce que cm14 était trop inachevé pour moi. Tout fonctionne bien pour moi sur cm13.
Les bases de données @Adem peuvent avoir déplacé http://android.stackexchange.com/a/155895/136434
Sebastian Schrader
2016-01-27 05:43:20 UTC
view on stackexchange narkive permalink

J'ai eu le même problème lors de la mise à niveau vers CM13 depuis CM12.1. Vous pouvez résoudre ce problème sans supprimer vos fichiers de base de données et donc perdre des données comme suggéré dans les autres réponses.

Le coupable semble être la base de données brisée code onUpgrade dans le TelephonyProvider de CM. La colonne ppp_number de la table des transporteurs n'existe pas, mais le code de mise à niveau suppose qu'elle existe déjà.

J'ai résolu le problème en copiant telephony.db sur ma machine Linux locale et en le rétablissant la version de la base de données à la version 16 << 16 | 6 = 1048582 pour forcer le code de mise à jour à ajouter les colonnes manquantes. Les instructions ALTER TABLE dans le code lié sont gardées par des blocs try-catch, de sorte que peu importe si certaines des colonnes existent déjà. Démarrez le téléphone en récupération (par exemple TWRP) pour avoir les privilèges adb root et éviter les courses de verrouillage avec le Runtime Android qui essaie constamment de démarrer le fournisseur de téléphonie. 

 % adb pull / data / user / 0 / com.android.providers.telephony / databases / telephony.db% adb pull /data/user/0/com.android.providers.telephony/databases/telephony.db-journal

Créez des sauvegardes 

 % cp telephony.db telephony.db.bak% cp telephony.db-journal telephony.db-journal.bak

Puis ouvrez la base de données avec sqlite et définissez la version 

 % sqlite3 telephony.dbsqlite> PRAGMA user_version = 1048582; sqlite> .quit

Remettez la base de données modifiée sur le périphérique et corriger les permissions 

 % adb push telephony.db /data/user/0/com.android.providers.telephony/databases% adb shell ~ # cd / data / user / 0 / com. android.providers.telephony / databases / data / data / com.android.providers.telephony / databases # rm telephony.db-journal / data / data / co m.android.providers.telephony / databases # chown radio: radio telephony.db / data / data / com.android.providers.telephony / databases # chmod 660 telephony.db

Vous pouvez également essayer ceci sur le système défectueux, ce que je ne recommanderais pas. Vous devrez probablement devenir root avec adb root pour copier et modifier les fichiers avec adb .

Excellente attention aux détails! L'explication est très appréciée. Comme @gedenkt,, j'ai suivi ces instructions, mais elles n'ont pas fonctionné pour moi non plus. : - / La simple suppression de ces deux fichiers `* .db *` a résolu le problème.
Vous pouvez utiliser la commande "vacuum" pour fusionner le journal avec la base de données. `$ sqlite3 telephony.db VIDE`
gedenkt
2016-03-25 23:47:04 UTC
view on stackexchange narkive permalink

J'ai essayé la solution de Sebastian, mais l'erreur a persisté. La réponse acceptée entraîne la perte de tous vos SMS, donc ce n'était pas une option pour moi. Cependant, après le démarrage en mode de récupération et la suppression des fichiers 

  /data/data/com.android.providers.telephony/databases/telephony.db/data/data/com.android.providers.telephony/databases/telephony.db-journal

le téléphone fonctionnait à nouveau parfaitement. Les fichiers semblent ne contenir que des données générées automatiquement, il est donc prudent de les supprimer.

Comment puis-je supprimer certains fichiers en mode de récupération?
@Hinrich Si vous utilisez une récupération complète comme TWRP, vous pouvez utiliser le gestionnaire de fichiers intégré.
Voici un peu plus de détails sur TWRP. Dans mon cas, j'utilise Safestrap 3.75 (TWRP v2.7.1.0), et j'ai dû utiliser le bouton «Monter», puis cocher «Données», puis revenir en arrière, puis utiliser le bouton «Avancé» pour utiliser le Bouton "Gestionnaire de fichiers" (puis naviguez, à partir du dossier "données").
Bossdwarf
2016-01-15 18:56:49 UTC
view on stackexchange narkive permalink

Si vous ne parvenez pas à accéder à un shell adb ou à supprimer le répertoire de votre téléphone car il est inutilisable, vous pouvez également supprimer le répertoire de whitin TWRP recovery.

Veuillez ajouter les instructions nécessaires pour ce faire dans votre réponse. Et si l'OP n'a pas TWRP?
Hinrich
2016-05-09 12:14:06 UTC
view on stackexchange narkive permalink

Avait le même poblème après la mise à jour de CM12 à CM13. Voici comment j'ai pu résoudre ce problème:

J'ai supprimé ces deux répertoires 

  /data/user/0/com.android.providers.telephony/data/data /com.android.phone/

entièrement depuis mon téléphone (Nexus 5). J'ai utilisé ES Explorer pour ce faire, j'ai dû activer le Mode racine et Afficher les fichiers cachés pour pouvoir supprimer les fichiers de ce répertoire.

Le journal des appels et les SMS sont toujours là, ne peuvent voir aucun inconvénient résultant de la suppression de ces répertoires. Tout semble à nouveau fonctionner correctement.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...