Sto sviluppando un'applicazione e ogni volta che la eseguo ricevo il messaggio:

Sfortunatamente, MyApp si è fermata.

Cosa posso fare per risolvere questo?

A proposito di questa domanda - ovviamente ispirata a Cos'è una traccia dello stack e come posso usarla per eseguire il debug degli errori dell'applicazione? , ci sono molte domande che affermano che la loro applicazione è andata in crash, senza ulteriori dettagli. Questa domanda ha lo scopo di istruire i programmatori Android alle prime armi su come provare a risolvere i problemi da soli o porre le domande giuste.

Questa risposta descrive il processo di recupero della traccia dello stack. Hai già la traccia dello stack? Leggi le tracce dello stack in " Che cos'è una traccia dello stack e come posso utilizzarla per eseguire il debug degli errori dell'applicazione? "

Il problema

L'applicazione è stata chiusa perché è RuntimeExceptionstato generato un non catturato .
Il più comune di questi è il NullPointerException.

Come risolverlo?

Ogni volta che un'applicazione Android si arresta in modo anomalo (o qualsiasi altra applicazione Java per quella materia), un Stack traceviene scritto sulla console (in questo caso, logcat). Questa traccia dello stack contiene informazioni vitali per la risoluzione del problema.

Android Studio

Nella barra in basso della finestra, fai clic sul Logcatpulsante. In alternativa, puoi premere alt+ 6. Assicurati che il tuo emulatore o dispositivo sia selezionato nel Devicespannello. Quindi, prova a trovare la traccia dello stack, che viene mostrata in rosso. Potrebbero esserci molte cose registrate in logcat, quindi potrebbe essere necessario scorrere un po '. Un modo semplice per trovare la traccia dello stack è quello di cancellare il logcat (usando il cestino sulla destra) e lasciare di nuovo in crash l'app.

Ho trovato la traccia dello stack, e adesso?

Sìì! Sei a metà strada per risolvere il tuo problema.
Hai solo bisogno di scoprire che cosa ha causato l'arresto anomalo dell'applicazione, analizzando la traccia dello stack.

Leggi le tracce dello stack in " Che cos'è una traccia dello stack e come posso utilizzarla per eseguire il debug degli errori dell'applicazione? "

Non riesco ancora a risolvere il mio problema!

Se hai trovato la tua Exceptione la riga in cui si è verificato e non riesci ancora a capire come risolverlo, non esitare a fare una domanda su StackOverflow.

Cerca di essere il più conciso possibile: pubblica la traccia dello stack e il relativo codice (ad es. Alcune righe fino alla riga che ha lanciato il Exception).

È possibile utilizzare strumento di ADB di Google per arrivare Logcat filead analizzare la questione.

adb logcat > logcat.txt

apri il logcat.txtfile e cerca il nome della tua applicazione. Dovrebbero esserci informazioni sul perché non è riuscito, il numero di riga, il nome della classe, ecc.

Innanzitutto, controlla a quale punto la tua app è andata in crash ( Unfortunately, MyApp has stopped.). Per questo, puoi usare Log.e("TAG", "Message");, usando questa linea puoi vedere il tuo registro app in logcat.

Dopodiché, scopri a che punto la tua app si è fermata è molto facile da risolvere al tuo fianco.

Controlla l'errore nel log cat.

Puoi ottenere l'opzione log cat da in eclipse:

finestra-> mostra vista-> altri-> Android-> Logcat

Log cat contiene errori.

In alternativa, puoi anche verificare l'errore eseguendo un'applicazione in modalità debug. Innanzitutto imposta il punto di interruzione dopo quello facendo:

tasto destro del mouse su progetto-> debug as-> applicazione Android

Nota: questa risposta utilizza Android Studio 2.2.2

Nota 2: sto considerando che il dispositivo è stato collegato correttamente.

La prima cosa che fai quando l'applicazione si blocca è guardare LogCat, nella parte inferiore di Android Studio c'è una barra degli strumenti con un elenco di menu:

Fai clic su "Android Monitor" (Quello che ho sottolineato nell'immagine sopra. ^)

Ora otterrai qualcosa del genere:

Cambia " Verbose" in " Error" Ora ti mostrerà solo gli errori registrati. Non preoccuparti di tutti questi errori (se li hai) ora.

Ok. Ora fai quello che hai fatto per bloccare l'app. Dopo il crash dell'app, vai al tuo logcat. Dovresti trovare un nuovo registro degli arresti anomali che ha molti at:x.x.x: e Caused by: TrumpIsPresidentExceptionper esempio. Vai a quella Caused by:dichiarazione nel tuo logcat.

Accanto a ciò Caused By:, dovrebbe esserci l'eccezione che si è verificata. Nel mio caso, è a RuntimeExceptione sotto dovrebbe esserci una linea che contiene un collegamento blu come:

Se quelloCaused by: NON ha una linea con un testo blu da qualche parte sotto di esso, quindi cercare un altro Caused by:che lo fa.

Fai clic su quel link blu . Dovrebbe portarti dove si è verificato il problema. Nel mio caso, era dovuto a questa riga:

throw new RuntimeException();

Quindi, ora so perché si sta schiantando. È perché sto lanciando l'eccezione da solo. Questo è stato un errore evidente .

Tuttavia, supponiamo di avere un altro errore:

java.lang.NullPointerException

Ho controllato il mio logcat, ho cliccato sul link blu che mi ha dato e mi ha portato qui:

mTextView.setText(myString);

Quindi, ora voglio eseguire il debug. Secondo questa domanda StackOverflow , una NullPointerException dice che qualcosa lo è null.

Quindi, scopriamo cosa è nullo . Ci sono due possibilità. O mTextViewè nullo o myStringè nullo. Per scoprire, prima della mTextView.setText(mString)riga, aggiungo queste due righe:

Log.d("AppDebug","mTextView is null: " + String.valueOf(mTextView == null);
Log.d("AppDebug","myString is null: " + String.valueOf(myString== null);

Ora, come abbiamo fatto in precedenza (abbiamo cambiato Verose in Error), vogliamo cambiare "Error" in "Debug". Dal momento che stiamo registrando tramite il debug. Ecco tutti i metodi di registro:

Log.
  d means Debug
  e means error
  w means warning
  v means verbose
  i means information
  wtf means "What a terrible failure". This is similar to Log.e

Quindi, dal momento che abbiamo usato Log.d, stiamo controllando Debug. Ecco perché l'abbiamo cambiato in debug.

L'avviso Log.dha un primo parametro, nel nostro caso "AppDebug". Fare clic sul menu a discesa "Nessun filtro" in alto a destra nel logcat. Selezionare "Modifica configurazione filtro", assegnare un nome al filtro e in "Tag registro" inserire "Debug app". Fai clic su "OK". Ora dovresti vedere due righe nel logcat:

yourPackageNameAndApp: mTextView is null: true
yourPackageNameAndApp: myString is null: false

Quindi ora sappiamo che mTextView è nullo.

Osservo il mio codice, ora noto qualcosa.

Ho private TextView mTextViewdichiarato ai vertici della mia classe. Ma non lo sto definendo.

Fondamentalmente ho dimenticato di farlo nel mio onCreate ():

mTextView = (TextView) findViewById(R.id.textview_id_in_xml);

Quindi, questo mTextViewè il motivo per cui è nullo, perché ho dimenticato di dire alla mia app di cosa si tratta. Quindi aggiungo quella riga, eseguo la mia app e ora l'app non si arresta in modo anomalo.

Questo popup viene visualizzato solo quando si ottiene un'eccezione irreversibile nel codice che interrompe l'esecuzione dell'app. Potrebbe essere un'eccezione NullPointerException, OutOfMemoryExceptionecc.

Il modo migliore per verificare è tramite Logcat se stai ancora sviluppando l'app in Android Studio, che è un modo rapido per leggere la traccia dello stack e verificare la causa dell'app.

Se la tua app è già attiva, non puoi utilizzare logcat . Quindi, per quello che puoi implementare Crashlyticsper fornire segnalazioni di bug di qualsiasi eccezione che si verifica.

Controlla il tuo Logcatmessaggio e vedi il tuo Manifestfile. Dovrebbe mancare qualcosa come la definizione Activity,dell'autorizzazione dell'utente`, ecc.

Puoi usare uno di questi strumenti:

1. adcat logcat

2. adb logcat> logs.txt (puoi usare gli editor per aprire e cercare errori).

3. eclipse logcat (se non visibile in eclipse, vai su Windows-> Mostra vista-> Altro-> Android-> LogCat)

4. Monitoraggio debug Android o Monitor dispositivo Android (digita monitor comandi o apri l'interfaccia utente)

5. Android Studio

Suggerisco di usare Android Debug Monitor , è buono. Perché eclipse si blocca quando ci sono troppi registri e attraverso il filtro adb logcat e tutti difficili.

Devi controllare il Stack trace

Come farlo?

sul tuo IDE Controlla la finestra di LOGCAT

Se non riesci a vedere le finestre di logcat vai su questo percorso e aprilo

window->show view->others->Android->Logcat

se stai usando Google-Api vai su questo percorso

adb logcat> logcat.txt

Nel seguente metodo showToast () devi passare un altro parametro per il contesto o il contesto dell'applicazione facendo così puoi provarlo.

  public void showToast(String error, Context applicationContext){
        LayoutInflater inflater = getLayoutInflater();
        View view = inflater.inflate(R.layout.custom_toast, (ViewGroup)      
        findViewById(R.id.toast_root));
        TextView text = (TextView) findViewById(R.id.toast_error);
        text.setText(error);
        Toast toast = new Toast(applicationContext);
        toast.setGravity(Gravity.TOP | Gravity.FILL_HORIZONTAL, 0, 0);
        toast.setDuration(Toast.LENGTH_SHORT);
        toast.setView(view);
        toast.show();
}

Vorrei condividere un'analisi Logcat di base per quando si incontra una chiusura forzata (quando l'app smette di funzionare).

DOCS

Lo strumento di base di Android per raccogliere / analizzare i registri è il logcat.

QUI è la pagina di Android su logcat

Se usi Android Studio, puoi anche controllare questo LINK .

cattura

Fondamentalmente, puoi catturare MANUALMENTE logcat con il seguente comando (o semplicemente controllare la finestra di AndroidMonitor in AndroidStudio):

adb logcat

Ci sono molti parametri che puoi aggiungere al comando che ti aiutano a filtrare e visualizzare il messaggio che desideri ... Questo è personale ... Uso sempre il comando seguente per ottenere il timestamp del messaggio:

adb logcat -v time

È possibile reindirizzare l'output su un file e analizzarlo in un editor di testo.

Analizzando

Se l'app si sta bloccando, otterrai qualcosa del tipo:

07-09 08:29:13.474 21144-21144/com.example.khan.abc D/AndroidRuntime: Shutting down VM
07-09 08:29:13.475 21144-21144/com.example.khan.abc E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.khan.abc, PID: 21144
    java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
     at com.example.khan.abc.AudioFragment$1.onClick(AudioFragment.java:125)
     at android.view.View.performClick(View.java:4848)
     at android.view.View$PerformClick.run(View.java:20262)
     at android.os.Handler.handleCallback(Handler.java:815)
     at android.os.Handler.dispatchMessage(Handler.java:104)
     at android.os.Looper.loop(Looper.java:194)
     at android.app.ActivityThread.main(ActivityThread.java:5631)
     at java.lang.reflect.Method.invoke(Native Method)
     at java.lang.reflect.Method.invoke(Method.java:372)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754)
07-09 08:29:15.195 21144-21144/com.example.khan.abc I/Process: Sending signal. PID: 21144 SIG: 9

Questa parte del registro mostra molte informazioni:

• Quando si è verificato il problema: 07-09 08:29:13.475

È importante controllare quando si è verificato il problema ... Potresti trovare diversi errori in un registro ... devi essere sicuro di controllare i messaggi corretti :)

• Quale app è andata in crash: com.example.khan.abc

In questo modo, sai quale app si è arrestata in modo anomalo (per essere sicuro di controllare i log relativi al tuo messaggio)

• Quale ERRORE: java.lang.NullPointerException

Un errore di eccezione del puntatore NULL

• Informazioni dettagliate sull'errore: Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference

Hai provato a chiamare il metodo onBackPressed()da un FragmentActivityoggetto. Tuttavia, quell'oggetto era nullquando l'hai fatto.

• Stack Trace: Stack Trace mostra l'ordine di invocazione del metodo ... A volte, l'errore si verifica nel metodo chiamante (e non nel metodo chiamato).

  su com.example.khan.abc.AudioFragment $ 1.onClick (AudioFragment.java:125)

Errore nel file com.example.khan.abc.AudioFragment.java, all'interno del onClick()metodo alla riga: 125(stacktrace mostra la riga in cui si è verificato l'errore)

È stato chiamato da:

at android.view.View.performClick(View.java:4848)

Che è stato chiamato da:

at android.view.View$PerformClick.run(View.java:20262)

che è stato chiamato da:

at android.os.Handler.handleCallback(Handler.java:815)

eccetera....

Panoramica

Questa era solo una panoramica ... Non tutti i registri sono semplici, ecc ... È solo per condividere l'idea e fornirti informazioni di livello base ...

Spero di poterti aiutare in qualche modo ... Saluti

Utilizzare LogCat e prova a trovare ciò che sta causando l'arresto anomalo dell'app.

Per vedere Logcat se usi Android Studio, premi ALT + 6 o

se usi Eclipse, quindi Finestra -> Apri prospettiva -> Altro - LogCat

Vai a LogCat, dal menu a discesa seleziona errore. Questo conterrà tutte le informazioni richieste per aiutarti a eseguire il debug. Se ciò non aiuta, pubblica LogCat come modifica alla tua domanda e qualcuno ti aiuterà.

Se la tua app si blocca per qualche motivo senza una buona stacktrace. Prova a eseguire il debug dalla prima riga e procedi riga per riga fino all'arresto anomalo. Quindi avrai una risposta, quale riga ti sta causando problemi. Probabilmente potresti quindi inserirlo in try catch block e stampare l'output degli errori.

È inoltre possibile ottenere questo messaggio di errore da solo, senza alcuna traccia di stack o ulteriori messaggi di errore.

In questo caso devi assicurarti che il tuo manifest Android sia configurato correttamente (incluso l'eventuale fusione manifest da una libreria e qualsiasi attività che provenga da una libreria) e prestare particolare attenzione alla prima attività visualizzata nella tua applicazione nei tuoi file manifest .

Arresto anomalo durante lo sviluppo

Prova il mio toolview preferito per ottenere i log e analizzarli durante lo sviluppo.
Assicurarsi di contrassegnare ./logviewe ./lib/logview.jarcome eseguibile quando si esegue in Linux.

Se non ti piace, ci sono molti visualizzatori di registri desktop alternativi per Android .

Crash in the wild

Integra uno strumento di segnalazione degli arresti anomali in tempo reale come Firebase Crashlytics in per ottenere stack stack di eccezioni non gestite che si sono verificate sui dispositivi degli utenti.

Leggi Come rilasciare un'app Buggy (e Live to Tell the Tale) per saperne di più sulla gestione dei bug sul campo.

Le persone commettono errori e anche la programmazione.

Quando mai è errorsuccesso, verifica sempre con il logcat con il testo in colore rosso, tuttavia puoi scoprire il vero problema nel testo di colore blu con sottolineatura in quel testo di colore rosso.

Assicurati di crearne uno nuovo activity, dichiara sempre activityil fileAndroidManifest file.

Se si aggiunge l'autorizzazione, dichiararla nel AndroidMainifest file.

Logcat : per controllare i log nella fase di sviluppo di Android Studio

Inizialmente cancella Logcat e lascia che l'app si blocchi di nuovo in modo da poter ottenere solo i dettagli del registro in crash. Devi controllare la traccia dello Stack

Mentre, purtroppo, MyApp si è fermata. Ci sono molte ragioni per questo. Puoi controllare lo stesso nei registri. Per questo, è possibile utilizzare il Log.e ("TAG", "Messaggio");

Errore comune durante l'arresto anomalo dell'app come:

1. Errore di codifica (uso errato delle parole chiave).
2. Nome della proprietà non corrispondente.
3. Plug-in non supportato (forse).
4. Versione non corrispondente (forse).
5. Attività mancante nel file AndroidManifest.
6. Autorizzazione mancante nel file AndroidManifest.
7. NullPointerException più comune.
8. Dichiarato ma non definito.

Per risolvere l'errore di arresto anomalo dell'app:

• Tieni a mente i punti precedenti e passa attraverso di essa.
• Con l'errore, otterrai il nome del file anche in colore blu (fai clic su di essi e passa al codice in caso di errore).

Innanzitutto, devi verificare dove e perché la tua app è stata arrestata in modo anomalo (Unfortunately, MyApp has stopped.).Con l'aiuto di LOG, puoi capire cosa è andato storto.

Successivamente, scopri quale punto la tua app ha smesso di risolverlo dal tuo punto.

Se non hai alcun tipo di log interessante nel tuo terminale (o non sono direttamente correlati alla tua app), forse il tuo problema è dovuto a una libreria nativa. In tal caso, è necessario verificare la presenza di file "tombstone" all'interno del proprio terminale.

La posizione predefinita per i file tombstone dipende da ogni dispositivo, ma in tal caso, avrai un registro che dice: Tombstone written to: /data/tombstones/tombstone_06

Per ulteriori informazioni, consultare https://source.android.com/devices/tech/debug .

Anche l'esecuzione di questo comando nel terminale può aiutare a trovare il problema:

gradlew build > log.txt 2>details.txt

quindi si dovrebbe andare alla posizione del file gradlew in leggere due file di registro sopra.