Android: un'app continua a interrompersi o si chiude da sola, come trovare la causa

Un’applicazione Android che si chiude improvvisamente, torna alla schermata iniziale o mostra il messaggio “L’app continua a interrompersi” può diventare un problema particolarmente fastidioso, soprattutto quando il malfunzionamento riguarda applicazioni utilizzate quotidianamente.

La soluzione che vi ripeteranno come un disco rotto consiste nello svuotare la cache, reinstallare l’app o riavviare lo smartphone. Sono interventi che in alcuni casi funzionano ma non permettono di capire perché l’applicazione abbia smesso di funzionare.

Android dispone di procedure diagnostiche capaci di distinguere un errore di programmazione, un processo terminato per insufficienza di memoria, un componente di sistema difettoso e un’applicazione che non risponde più ai comandi.

Perché un’app Android si chiude da sola: non tutte le interruzioni sono uguali

Prima di passare alla parte pratica, è bene distinguere tre situazioni che, all’apparenza, producono lo stesso risultato ovvero l’arresto anomalo dell’app Android:

1. Crash dell’applicazione. Il processo termina a causa di un errore non gestito. Può trattarsi di un’eccezione Java o Kotlin, di un problema nella gestione della memoria oppure di un errore nel codice nativo. Spesso Android mostra un messaggio che avvisa del problema.
2. Applicazione che non risponde (ANR). L’applicazione rimane aperta ma smette di reagire. Android rileva che il thread principale, responsabile anche dell’interfaccia grafica, non riesce a elaborare le varie operazioni entro i tempi previsti. Il sistema può quindi proporre di attendere oppure chiudere l’app.
3. Processo terminato da Android. L’applicazione può scomparire dalla memoria senza aver generato un vero crash. Succede, per esempio, quando il sistema deve recuperare RAM o quando intervengono specifiche politiche di gestione dei processi.

C’è anche una quarta possibilità: l’applicazione decide autonomamente di chiudere una schermata o tornare alla Home, senza che il suo processo termini. Un comportamento del genere richiede un’indagine differente.

Prima diagnosi: capire quando si verifica la chiusura

Il momento in cui l’app Android si interrompe fornisce già delle informazioni utili. Ovviamente sono indizi, non un responso definitivo: un’applicazione che si chiude all’avvio può soffrire di un problema interno ma anche dipendere da un servizio esterno non disponibile:

Comportamento	Possibile origine
Si chiude immediatamente all’avvio	Errore di inizializzazione, dati danneggiati, incompatibilità
Si interrompe aprendo una pagina specifica	Bug nella funzione, contenuto problematico, WebView
Si blocca e mostra “L’app non risponde”	ANR, operazione troppo lunga, thread bloccato
Si riavvia tornando dal background	Processo terminato, memoria insufficiente, stato non ripristinato
Più app iniziano a chiudersi insieme	Componente condiviso, aggiornamento di sistema, problema generale
Funziona solo dopo aver cancellato i dati	Configurazione locale o database probabilmente coinvolti

In tutti i casi il consiglio consiste nell’aprire l’applicazione, ripetere esattamente l’operazione che provoca l’interruzione e annotare l’orario in cui la chiusura inattesa si è manifestata. Sapere quando avviene il problema permette successivamente di cercare le registrazioni pertinenti nei log, evitando di analizzare migliaia di messaggi non correlati.

Come verificare il problema senza installare strumenti aggiuntivi

Aprendo Impostazioni, App, selezionando l’app interessata e accedendo alla sezione relativa allo spazio di archiviazione, è possibile intervenire sulla cache e sui dati locali. I nomi esatti dei menu dipendono dal produttore e dalla versione di Android. Due operazioni, già citate in precedenza, sono quelle spesso determinati per la risoluzione:

• Svuota cache: elimina file temporanei ricreabili, senza normalmente cancellare configurazioni e dati personali.
• Cancella dati o Cancella spazio di archiviazione: reimposta i dati locali dell’applicazione, con il rischio di perdere sessioni, impostazioni e contenuti non sincronizzati.

La seconda opzione non dovrebbe mai essere utilizzata al primo tentativo e comunque non bisogna servirsene “con leggerezza”: se l’app contiene dati importanti, è preferibile accertarsi prima che siano stati salvati o sincronizzati correttamente prima di procedere!

Avviare Android in modalità provvisoria per individuare le app problematiche

Non tutti sanno che anche Android dispone di una modalità provvisoria (Safe Mode) che permette di avviare lo smartphone disabilitando temporaneamente le applicazioni scaricate dall’utente. È uno strumento diagnostico particolarmente utile quando il telefono manifesta rallentamenti, blocchi, riavvii improvvisi o anomalie che potrebbero dipendere da un’app installata.

Per attivare la modalità provvisoria Android, su molti smartphone è sufficiente aprire il menu di spegnimento, tenere premuta per qualche secondo l’icona Spegni visualizzata sullo schermo e selezionare Modalità provvisoria o Modalità sicura. Il dispositivo si riavvierà mostrando un’indicazione della modalità attiva nella parte inferiore del display.

La procedura può variare in base al produttore. Sugli smartphone Samsung Galaxy, ad esempio, è possibile aprire il menu di spegnimento premendo contemporaneamente il tasto laterale e Volume giù, quindi tenere premuta l’icona Spegni e scegliere Modalità sicura. Su molti Google Pixel recenti, invece, il menu di accensione si apre premendo contemporaneamente il tasto di accensione e Volume su; da qui è possibile tenere premuta l’opzione di spegnimento o riavvio e confermare l’accesso alla modalità provvisoria.

Un metodo alternativo, disponibile su alcuni dispositivi, consiste nello spegnere completamente lo smartphone, riaccenderlo e mantenere premuto Volume giù durante l’animazione di avvio, fino alla comparsa della schermata principale.

Una volta entrati in modalità provvisoria, bisogna verificare se i malfunzionamenti generali continuano a manifestarsi. Se scompaiono, è probabile che una delle applicazioni di terze parti interferisca con il normale funzionamento del sistema. Si può quindi riavviare normalmente lo smartphone e procedere alla disinstallazione selettiva delle app sospette, iniziando da quelle installate o aggiornate poco prima della comparsa dei problemi.

Attenzione però perché la modalità provvisoria non consente di eseguire le applicazioni scaricate dal Play Store. Non è quindi adatta a riprodurre direttamente il crash di una specifica app di terze parti. Serve piuttosto a identificare interferenze software che compromettono il funzionamento generale del dispositivo o delle applicazioni di sistema rimaste disponibili.

Per uscire dalla modalità provvisoria basta riavviare lo smartphone. Le applicazioni precedentemente disabilitate tornano disponibili senza doverle reinstallare; Google segnala comunque che alcuni widget della schermata Home potrebbero dover essere ripristinati manualmente.

Android System WebView: un componente provoca il crash di più app

Quando più app Android iniziano a chiudersi dopo un aggiornamento, anche se apparentemente non hanno nulla in comune, il responsabile può essere Android System WebView, componente utilizzato da numerose applicazioni per visualizzare contenuti Web direttamente al loro interno.

Un precedente significativo risale al marzo 2021, quando un aggiornamento difettoso di WebView provocò arresti anomali di Gmail e di numerose altre applicazioni Android. Google confermò il problema, distribuendo una versione corretta del componente.

L’episodio dimostra perché, quando più applicazioni si interrompono contemporaneamente, reinstallarle singolarmente potrebbe essere inutile.

In un caso del genere conviene aprire il Play Store e verificare gli aggiornamenti disponibili per Android System WebView, Google Chrome e le applicazioni coinvolte. Non tutti i dispositivi gestiscono WebView allo stesso modo: su alcune configurazioni, Chrome può avere un ruolo fondamentale.

Aggiornare manualmente un’app Android tramite APK quando il Play Store non offre ancora la soluzione

Un’applicazione Android che continua a interrompersi potrebbe aver già ricevuto una correzione da parte dello sviluppatore, anche se il Play Store non propone ancora alcun aggiornamento. Non sempre, infatti, le nuove versioni vengono distribuite contemporaneamente a tutti gli utenti: Google Play supporta i cosiddetti staged rollout, aggiornamenti graduali che raggiungono inizialmente soltanto una percentuale dei dispositivi.

Ci sono capitati casi in cui lo sviluppatore aveva già pubblicato una versione correttiva sul proprio sito ufficiale o attraverso un canale di distribuzione alternativo. È quindi possibile risolvere il problema installando manualmente il nuovo pacchetto APK, senza attendere che la stessa versione diventi disponibile sul Play Store.

Prima di procedere, bisogna verificare nelle informazioni dell’applicazione quale versione sia attualmente installata e confrontarla con quella disponibile sul sito dello sviluppatore. Se è presente una versione più recente, si può scaricare il relativo APK, aprirlo sullo smartphone e autorizzare, quando richiesto, l’installazione da quella specifica origine. Android tenterà quindi di aggiornare l’applicazione esistente.

Affinché l’aggiornamento sia applicato senza problemi, il pacchetto deve utilizzare lo stesso identificativo dell’applicazione, una firma digitale compatibile con quella già installata e un codice di versione appropriato. Non sempre, quindi, un APK apparentemente più recente può sostituire la versione distribuita attraverso Google Play.

Per ragioni di sicurezza, è sempre preferibile scaricare l’aggiornamento dal sito ufficiale dello sviluppatore o da un canale espressamente riconosciuto, evitando archivi sconosciuti e pacchetti modificati.

Come scoprire la vera causa di un crash Android usando ADB

Quando le verifiche iniziali non forniscono risultati, il metodo più efficace consiste nell’analizzare i messaggi diagnostici prodotti da Android. Per farlo, basta scaricare il pacchetto ufficiale Android SDK Platform Tools.

Su Windows è sufficiente estrarre l’archivio ZIP, aprire PowerShell nella cartella contenente adb.exe e collegare lo smartphone tramite cavo USB.

Sul telefono bisogna attivare le Opzioni sviluppatore, toccando per almeno 7 volte di fila il numero di build nelle informazioni sul dispositivo, quindi abilitare la voce Debug USB. Per verificare il collegamento, in PowerShell si può digitare:

.\adb.exe devices

Se compare il messaggio unauthorized, occorre autorizzare il computer dallo smartphone: diventa possibile interfacciarsi dal PC con il dispositivo Android quando il comando ADB restituisce lo stato device.

Registrare il crash nel momento in cui avviene

A questo punto possiamo raccogliere i messaggi generati durante l’interruzione dell’app:

.\adb.exe logcat -v threadtime > android-crash.txt

Il comando avvia la registrazione continua dei log in un file di testo.

Mentre la registrazione è attiva, apriamo l’applicazione problematica e ripetiamo l’operazione che normalmente provoca la chiusura. Subito dopo, torniamo alla finestra PowerShell e premiamo CTRL+C in modo da interrompere la registrazione.

Il file android-crash.txt contiene le informazioni disponibili durante l’esecuzione. È importante acquisire i log mentre il problema si manifesta, perché Android utilizza buffer circolari che possono sovrascrivere progressivamente i messaggi più vecchi.

Per esaminare soltanto il buffer dedicato ai crash, è disponibile anche il comando seguente:

.\adb.exe logcat -b crash -v threadtime -d > crash-only.txt

L’opzione -d consente di esportare i messaggi attualmente conservati senza mantenere aperta una sessione di monitoraggio. Il buffer crash è però insufficiente quando l’app non genera un crash tradizionale, ad esempio nei casi di terminazione per memoria insufficiente.

Come leggere un log e identificare l’applicazione che si interrompe

Supponiamo che un’applicazione con nome del pacchetto com.esempio.app si chiuda immediatamente dopo l’apertura. Nel log potremmo trovare un messaggio simile al seguente, qui riportato come esempio illustrativo:

FATAL EXCEPTION: main
Process: com.esempio.app, PID: 18432
java.lang.NullPointerException
    at com.esempio.app.MainActivity.onCreate(MainActivity.kt:87)

FATAL EXCEPTION indica la presenza di un’eccezione non gestita che ha provocato l’interruzione; Process permette di identificare il processo coinvolto; NullPointerException indica che il codice ha tentato di utilizzare un riferimento nullo in un’operazione che non lo consentiva.

La riga che cita MainActivity.kt:87 individua un punto critico nel codice applicativo ma non implica che la causa del malfunzionamento risieda esattamente in quel punto. Il responsabile dell’anomalia potrebbe trovarsi in una chiamata precedente o in un componente dal quale l’applicazione dipende.

Altri messaggi importanti da riconoscere:

Messaggio nel log	Significato
FATAL EXCEPTION	Eccezione non gestita nel codice dell’app
OutOfMemoryError	Allocazione di memoria fallita
ANR in	Applicazione non reattiva
Fatal signal 11 (SIGSEGV)	Accesso non valido alla memoria nel codice nativo
SecurityException	Operazione rifiutata per motivi di sicurezza o autorizzazione
SQLiteException	Errore relativo a operazioni su SQLite
ClassNotFoundException	Classe richiesta non trovata

Un controllo più avanzato: Android può registrare perché un processo si è arrestato

A partire da Android 11, Google ha introdotto l’API ApplicationExitInfo, che consente alle applicazioni di recuperare informazioni storiche sulle terminazioni dei propri processi. L’aspetto interessante è che Android distingue formalmente diverse cause di uscita, senza considerarle tutte semplicemente come crash:

Codice Android	Interpretazione
REASON_CRASH	Eccezione non gestita
REASON_CRASH_NATIVE	Arresto del codice nativo
REASON_ANR	Applicazione non reattiva
REASON_LOW_MEMORY	Terminazione per pressione sulla memoria
REASON_EXCESSIVE_RESOURCE_USAGE	Utilizzo eccessivo di risorse
REASON_DEPENDENCY_DIED	Terminazione di un processo dal quale l’app dipende
REASON_EXIT_SELF	Chiusura volontaria del processo

Le informazioni sono particolarmente utili agli sviluppatori perché permettono di distinguere i malfunzionamenti dell’applicazione dalle decisioni del sistema operativo. L’API ApplicationExitInfo non è però una schermata diagnostica accessibile universalmente dalle impostazioni Android. L’API è progettata principalmente per le applicazioni stesse e il recupero dei dati è soggetto a limitazioni.

Su diversi dispositivi è possibile esplorare anche informazioni diagnostiche storiche tramite dumpsys, per esempio usando la sintassi che segue:

.\adb.exe shell dumpsys activity exit-info

La disponibilità e la struttura dell’output dipendono dalla versione e dall’implementazione di Android: non è sicuro che lo strumento mostri tutti gli arresti o che restituisca informazioni utilizzabili per qualunque app di terze parti.

Quando l’app viene chiusa per mancanza di RAM

Uno dei casi più difficili da riconoscere riguarda la pressione sulla memoria. Android gestisce la RAM cercando di preservare i processi importanti e liberando progressivamente le risorse occupate da quelli meno prioritari.

Quando la memoria disponibile diventa insufficiente, il sistema può terminare processi attraverso il meccanismo low memory killer: ne abbiamo parlato anche nel caso di Linux e il funzionamento è molto simile su Android. Le applicazioni in background sono generalmente più esposte, ma in condizioni critiche possono essere interessati anche processi visibili.

Per verificare le condizioni generali della memoria, ADB mette a disposizione il comando seguente:

.\adb.exe shell dumpsys meminfo

È possibile approfondire anche il consumo di una specifica applicazione, conoscendo il suo package name:

.\adb.exe shell dumpsys meminfo com.esempio.app

Il risultato può aiutare a individuare consumi anomali, ma rappresenta una fotografia del momento: non dimostra che una precedente chiusura sia stata causata dalla mancanza di RAM. Inoltre, i processi Android interessati non sono ormai più presenti in memoria dopo un’interruzione.

Quando Android dice che l’app non risponde: il problema ANR

Un’applicazione che si blocca per diversi secondi prima di mostrare un messaggio di errore può essere interessata da un problema ANR (Application Not Responding).

Il thread principale dell’applicazione deve poter elaborare rapidamente gli eventi dell’interfaccia: se rimane bloccato troppo a lungo durante determinate operazioni, Android può considerare l’app non reattiva. Le cause possono essere diverse: un’elaborazione particolarmente impegnativa, un’operazione di lettura o scrittura troppo lenta, una chiamata verso un servizio di sistema che non restituisce una risposta nei tempi attesi o un blocco tra thread.

Google distingue i problemi interni dell’applicazione dalle situazioni in cui il sistema stesso è sovraccarico. Per raccogliere informazioni più complete nei casi difficili da riprodurre, è possibile generare una segnalazione diagnostica:

.\adb.exe bugreport

ADB produce un archivio ZIP contenente numerose informazioni sul dispositivo, tra cui log, dati dei servizi di sistema e altre registrazioni diagnostiche. È uno degli strumenti ufficialmente suggeriti da Google per approfondire malfunzionamenti complessi.

I bug report possono contenere informazioni personali e riservate, come dettagli delle applicazioni, attività del dispositivo e altri dati personali: è quindi opportuno esaminarli prima di condividerli eventualmente con soggetti terzi.