Domanda:
"com.android.phone si è fermato" dopo aver lampeggiato in modo sporco CM13
friederbluemle
2015-11-25 23:11:25 UTC
view on stackexchange narkive permalink

Dopo aver sporcato il mio OnePlus One (bacon) da CM12.1 a CM13, ricevo costantemente popup di dialogo di chiusura forzata 

  Sfortunatamente il processo com.android.phone si è interrotto

Logcat è pieno di stacktrace in questo modo: 

  Arresto di VMFATAL ECCEZIONE: mainProcess: com.android.phone, PID: 13148java.lang.RuntimeException: Impossibile ottenere provider com.android.providers.telephony.TelephonyProvider: java.lang.IllegalStateException: Impossibile leggere la riga 0, col -1 da CursorWindow. Assicurarsi che il cursore sia inizializzato correttamente prima di accedere ai dati da esso. su android.app.ActivityThread.installProvider (ActivityThread.java:5205) su android.app.ActivityThread.installContentProviders (ActivityThread.java:4797) su android.app.ActivityThread.handleBindApplication (ActivityThread.java:4737) su android.app. ActivityThread.-wrap1 (ActivityThread.java) su android.app.ActivityThread $ H.handleMessage (ActivityThread.java:1424) su android.os.Handler.dispatchMessage (Handler.java:102) su android.os.Looper.loop ( Looper.java:148) su android.app.ActivityThread.main (ActivityThread.java:5466) su java.lang.reflect.Method.invoke (Native Method) su com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run ( ZygoteInit.java:726) su com.android.internal.os.ZygoteInit.main (ZygoteInit.java:616) Causato da: java.lang.IllegalStateException: Impossibile leggere la riga 0, col -1 da CursorWindow. Assicurarsi che il cursore sia inizializzato correttamente prima di accedere ai dati da esso. su android.database.CursorWindow.nativeGetString (metodo nativo) su android.database.CursorWindow.getString (CursorWindow.java:438) su android.database.AbstractWindowedCursor.getString (AbstractWindowedCursor.java:51) su com.android.providers.telephony .TelephonyProvider $ DatabaseHelper.getStringValueFromCursor (TelephonyProvider.java:993) su com.android.providers.telephony.TelephonyProvider $ DatabaseHelper.copyPreservedApnsToNewTable (TelephonyProvider.java:905)
su com.android.providers.telephony.TelephonyProvider $ DatabaseHelper.onUpgrade (TelephonyProvider.java:641) su android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:256) su android.database.sqlite.SQLiteReadableOpen .java: 187) su com.android.providers.telephony.TelephonyProvider.onCreate (TelephonyProvider.java:1457) su android.content.ContentProvider.attachInfo (ContentProvider.java:1748) su android.content.ContentProvider.attachInfo (ContentProvider. java: 1723) su android.app.ActivityThread.installProvider (ActivityThread.java:5202) ... altri 10

Una volta che in qualche modo mi sono sbarazzato del persistente popup dell'interfaccia utente, sembra com.android.phone si arresta in modo anomalo almeno 10 volte al secondo, inondando logcat e rendendo quasi impossibile l'uso del telefono.

C'è qualche speranza per una soluzione, o lo è un hard reset l'unica opzione?

Cancella i dati per `com.android.providers.telephony` (l'app è contrassegnata dall'etichetta" Phone / Telephony storage / providers "). Già che ci sei, fallo anche per l'app Telefono (`com.android.phone`), riavvia e comunicaci i risultati. Sembra che il database di `com.android.providers.telephony` non possa essere letto. Potrebbe essere possibile che non sia possibile cancellare i dati per quelle app. In tal caso, rimuovere le loro directory / data / data dalla faccia della terra.
La cancellazione della cache (dal ripristino) può aiutare
Ho provato a rimuovere queste cartelle utilizzando Total Commander in modalità root. Sono riuscito a eliminare ma non ha aiutato. Ho anche fatto un riavvio :( Non posso chiamare nessuno ...
Cinque risposte:
Aaahh
2015-11-26 13:27:53 UTC
view on stackexchange narkive permalink

Ciò è stato causato da una modifica nel codice.

Come ha detto Firelord, cancella i dati per le app. Questa operazione può essere eseguita in questo modo ( eliminerai anche i tuoi SMS / MMS database, quindi assicurati di eseguirne il backup in anticipo ): 

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

Il flag -f è per force e il flag -r significa ricorsivo.

Ha funzionato! Grazie. Ho anche notato questa riga nel mio logcat: `TelephonyProvider: dbh.onUpgrade: + db = SQLiteDatabase: /data/user/0/com.android.providers.telephony/databases/telephony.db oldV = 1114120 newV = 1376264` Dopo la rimozione la directory dei dati e un riavvio, le finestre di dialogo di chiusura forzata si sono interrotte. Cosa c'era nel database? Ho notato che tutti i miei messaggi di testo sono spariti. Qualunque altra cosa?
** Lettori: ** assicurati di riavviare il dispositivo dopo aver eliminato quelle directory.
È interessante notare che non è stato possibile eliminare i dati dal menu dell'app. Avevo bisogno di riavviare in TWRP ed eliminare la cartella lì (la prima era sufficiente)
Questo metodo non funziona per Cyanogenmod 14 / Android 7
@Adem novembre, che cos'è il logcat?
Ho eliminato cm14 e reinstallato cm13 perché cm14 era troppo incompleto per me. Tutto funziona bene per me su cm13.
I database di @Adem potrebbero essere stati spostati http://android.stackexchange.com/a/155895/136434
Sebastian Schrader
2016-01-27 05:43:20 UTC
view on stackexchange narkive permalink

Ho avuto lo stesso problema durante l'aggiornamento a CM13 da CM12.1. Puoi risolvere questo problema senza eliminare i file del database e quindi perdere i dati come suggerito nelle altre risposte.

Il colpevole sembra essere il database danneggiato sul codice di aggiornamento nel TelephonyProvider di CM. La colonna ppp_number della tabella carrier non esiste, ma il codice di aggiornamento presume che esista già.

L'ho risolto copiando telephony.db sulla mia macchina Linux locale e ripristinando dalla versione del database alla versione 16 << 16 | 6 = 1048582 per forzare il codice di aggiornamento ad aggiungere le colonne mancanti. Le istruzioni ALTER TABLE nel codice collegato sono protette da blocchi try-catch, quindi non importa se alcune delle colonne esistono già. Avvia il telefono in ripristino (ad esempio TWRP) per avere privilegi di root adb ed evitare gare di blocco con Android Runtime che cerca costantemente di avviare il provider di telefonia. 

 % 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

Crea backup 

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

Quindi apri il database con sqlite e impostare la versione 

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

Carica nuovamente il database modificato sul dispositivo e correggi i permessi 

 % 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

Potresti anche provarlo sul sistema danneggiato, cosa che non consiglierei. Probabilmente dovresti diventare root con adb root per copiare e modificare i file con adb .

Ottima cura dei dettagli! La spiegazione è molto apprezzata. Come @gedenkt, ho seguito queste istruzioni, ma non hanno funzionato neanche per me. : - / La semplice eliminazione di questi due file `* .db *` ha risolto il problema.
È possibile utilizzare il comando "vacuum" per unire il journal al db. `$ sqlite3 telephony.db VACUUM`
gedenkt
2016-03-25 23:47:04 UTC
view on stackexchange narkive permalink

Ho provato la soluzione di Sebastian, ma l'errore persisteva. La risposta accettata comporta la perdita di tutti i tuoi SMS, quindi non era un'opzione per me. Tuttavia, dopo l'avvio in modalità di ripristino e l'eliminazione dei file 

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

il telefono ha funzionato di nuovo perfettamente. I file sembrano contenere solo dati generati automaticamente, quindi è sicuro eliminarli.

Come posso eliminare determinati file in modalità di ripristino?
@Hinrich Se utilizzi un ripristino completo come TWRP, puoi utilizzare il file manager integrato.
Ecco un po 'più di dettagli su TWRP. Nel mio caso, utilizzo Safestrap 3.75 (TWRP v2.7.1.0) e ho dovuto utilizzare il pulsante "Mount", selezionare "Data", quindi tornare indietro, quindi utilizzare il pulsante "Advanced" per utilizzare Pulsante "File Manager" (quindi naviga, partendo dalla cartella "dati").
Bossdwarf
2016-01-15 18:56:49 UTC
view on stackexchange narkive permalink

Se non riesci ad accedere a una shell adb o rimuovere la directory dal tuo telefono perché è inutilizzabile, puoi anche rimuovere la directory dalla recovery TWRP.

Si prega di aggiungere le indicazioni necessarie per farlo nella risposta. Cosa succede se l'OP non ha TWRP?
Hinrich
2016-05-09 12:14:06 UTC
view on stackexchange narkive permalink

Aveva lo stesso problema dopo l'aggiornamento da CM12 a CM13. Ecco come sono riuscito a risolverlo:

Ho rimosso queste due directory 

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

completamente dal mio telefono (Nexus 5). Ho utilizzato ES Explorer per farlo, ho dovuto attivare Root Mode e Mostra file nascosti per poter eliminare i file in quella directory.

Il registro delle chiamate e gli SMS sono ancora presenti, non è possibile riscontrare alcuno svantaggio derivante dall'eliminazione di tali directory. Sembra che tutto funzioni di nuovo senza intoppi.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...