Quando l'app è in background, Android può terminarne il processo per liberare memoria, senza alcun avviso e senza alcun report di crash. L'utente torna all'app e si aspetta di continuare da dove si era fermato. Se lo stato viveva solo in memoria, si ritrova nella schermata iniziale con il suo input perso. Questo bug è comune perché non si manifesta su un telefono di sviluppo con molta memoria libera, ed è facile da riprodurre a comando.
Due modi per simularlo
Opzione 1: Non conservare le attività. Nelle Opzioni sviluppatore (tocca sette volte Numero build in Info sul telefono per sbloccarle), attiva Non conservare le attività. Ogni schermata che lasci viene distrutta. Ricordati di disattivarla dopo. Testa la ricreazione delle schermate, che è un parente stretto della chiusura del processo.
Opzione 2: Termina il processo. Metti l'app in background (tasto home, non lo scorrimento per chiuderla dalle recenti), poi esegui da un computer con adb:
adb shell am kill <your.package.name>
Poi riapri l'app dalle recenti. Il comando termina solo un processo in background; se non succede nulla, l'app era ancora in primo piano. Scorrere via l'app dalle recenti è una chiusura forzata da parte dell'utente, un caso diverso: in quel caso il sistema non ripristina lo stato.
Checklist
Esegui ogni caso, termina il processo, torna indietro e confronta.
- Modulo con testo digitato. Atteso: l'input è ancora lì, oppure l'utente viene avvisato chiaramente di cosa è andato perso.
- Schermata profonda. Apri una schermata di dettaglio tre livelli più in là. Atteso: torni a quella schermata, non a quella iniziale.
- Posizione di scorrimento e scheda. Atteso: stessa scheda, più o meno stessa posizione.
- Voci selezionate e filtri. Atteso: selezione e filtro attivo restano.
- Flusso in più passaggi, come onboarding, checkout o procedura guidata di configurazione. Atteso: il passaggio e le risposte precedenti restano. È qui che gli utenti perdono di più.
- Finestra di dialogo o pannello inferiore aperto. Atteso: ripristinato oppure chiuso in modo pulito, mai disegnato a metà.
- Stato di accesso. Atteso: l'utente resta connesso.
- Attività in corso. Caricamento, download, timer. Atteso: riprende, ricomincia in sicurezza o mostra un errore chiaro, senza duplicati.
- Deviazione su un permesso o una schermata di sistema. Vai a una finestra di dialogo di sistema, termina il processo, torna. Atteso: l'app prosegue il flusso.
- Link profondo o intent di condivisione. Avvia da un link, termina il processo, torna. Atteso: schermata corretta.
- Avvio a freddo dopo molto tempo. Lascia l'app per ore, torna. Atteso: si avvia senza crash dovuti a dati obsoleti.
Cosa segnalare
I passaggi prima della chiusura, il metodo esatto usato, cosa ha visto l'utente al ritorno e il nome della schermata. Indica se il dispositivo aveva poca memoria, perché può far scattare questo comportamento in modo naturale.
Correggere
Salva ciò che l'utente perderebbe, nei punti che Android mette a disposizione per lo stato salvato, e conserva i dati durevoli nella memoria di archiviazione invece che in memoria. Ritesta con gli stessi passaggi.
Limiti
Il comportamento reale con poca memoria varia da un dispositivo all'altro. La simulazione verifica come gestisci la situazione, non quanto spesso il sistema la provocherà.
Panoramica: Test delle app Android. Correlati: rotazione e cambi di configurazione e risparmio batteria e Doze.
Inizia gratis su AppReviewX e fai eseguire questi passaggi ai tester, che segnaleranno in modo strutturato.