Quand ton app est en arrière-plan, Android peut arrêter son processus pour libérer de la mémoire, sans avertissement ni rapport de crash. L'utilisateur revient et s'attend à reprendre là où il s'était arrêté. Si ton état ne vivait qu'en mémoire, il atterrit sur l'écran d'accueil et sa saisie a disparu. Ce bug est courant parce qu'il n'arrive jamais sur un téléphone de développeur qui a beaucoup de mémoire libre, et qu'il est facile à reproduire à la demande.
Deux façons de le simuler
Option 1 : ne pas conserver les activités. Dans les options pour développeurs (touche sept fois le numéro de build dans À propos du téléphone pour les activer), active Ne pas conserver les activités. Chaque écran que tu quittes est détruit. Pense à le désactiver ensuite. Ce test vérifie la recréation d'écran, un proche cousin de la mort de processus.
Option 2 : tuer le processus. Mets l'app en arrière-plan (bouton d'accueil, pas un balayage pour la fermer dans les récents), puis lance depuis un ordinateur avec adb :
adb shell am kill <your.package.name>
Rouvre ensuite l'app depuis les récents. La commande ne termine qu'un processus en arrière-plan ; si rien ne se passe, l'app était au premier plan. Balayer l'app dans les récents est un arrêt forcé par l'utilisateur, un cas différent : le système ne restaure pas l'état après.
Checklist
Lance chaque cas, tue le processus, reviens et compare.
- Formulaire avec du texte saisi. Attendu : la saisie est toujours là, ou l'utilisateur est clairement informé de ce qui a été perdu.
- Écran profond. Ouvre un écran de détail à trois niveaux. Attendu : tu reviens sur cet écran, pas sur le début.
- Position de défilement et onglet. Attendu : même onglet, à peu près le même endroit.
- Éléments sélectionnés et filtres. Attendu : la sélection et le filtre actif restent.
- Parcours en plusieurs étapes comme l'intégration, le paiement ou un assistant de configuration. Attendu : l'étape et les réponses précédentes restent. C'est là que les utilisateurs perdent le plus.
- Dialogue ou feuille du bas ouvert. Attendu : soit restauré, soit proprement fermé, jamais à moitié dessiné.
- État connecté. Attendu : l'utilisateur reste connecté.
- Tâches en cours. Envoi, téléchargement, minuteur. Attendu : reprise, redémarrage sûr ou échec clairement affiché, sans doublons.
- Détour par une permission ou un écran système. Quitte vers un dialogue système, tue l'app, reviens. Attendu : l'app poursuit le parcours.
- Lien profond ou intention de partage. Lance depuis un lien, tue l'app, reviens. Attendu : le bon écran.
- Démarrage à froid après longtemps. Laisse l'app pendant des heures, reviens. Attendu : elle démarre sans plantage dû à des données périmées.
Quoi signaler
Les étapes avant la mise à mort, la méthode exacte utilisée, ce que l'utilisateur a vu au retour et le nom de l'écran. Mentionne si l'appareil manquait de mémoire, car cela peut déclencher le phénomène naturellement.
Corriger
Sauvegarde ce que l'utilisateur perdrait, aux endroits prévus par Android pour l'état sauvegardé, et garde les données durables dans le stockage plutôt qu'en mémoire. Reteste avec les mêmes étapes.
Limites
Le comportement réel en cas de mémoire faible varie selon les appareils. La simulation vérifie ta gestion, pas la fréquence à laquelle le système le fera.
Vue d'ensemble : Test d'applications Android. Liens associés : rotation et changements de configuration et économiseur de batterie et Doze.
Commence gratuitement sur AppReviewX et fais exécuter ces étapes à des testeurs, avec un rapport structuré.