Cuando tu app está en segundo plano, Android puede cerrar su proceso para liberar memoria, sin aviso ni informe de fallo. El usuario vuelve y espera continuar donde lo dejó. Si tu estado solo vivía en memoria, aparece en la pantalla de inicio y lo que escribió se ha perdido. Este fallo es común porque nunca ocurre en un teléfono de desarrollo con mucha memoria libre, y es fácil de reproducir a voluntad.
Dos formas de simularlo
Opción 1: No conservar actividades. En Opciones de desarrollador (toca el número de compilación en Acerca del teléfono siete veces para desbloquearlas), activa No conservar actividades. Cada pantalla que abandones se destruye. Acuérdate de desactivarlo después. Prueba la recreación de pantallas, que es un primo cercano del cierre del proceso.
Opción 2: Matar el proceso. Envía la app a segundo plano (botón de inicio, no deslizar desde recientes) y, desde un ordenador con adb, ejecuta:
adb shell am kill <tu.nombre.de.paquete>
Luego vuelve a abrir la app desde recientes. El comando solo termina un proceso que está en segundo plano; si no pasa nada, la app seguía en primer plano. Deslizar la app fuera de recientes es una parada forzada por el usuario, que es un caso distinto: en ese caso el sistema no restaura el estado.
Lista de comprobación
Ejecuta cada caso, mata el proceso, vuelve y compara.
- Formulario con texto escrito. Esperado: la entrada sigue ahí, o se avisa claramente al usuario de lo que se perdió.
- Pantalla profunda. Abre una pantalla de detalle tres niveles abajo. Esperado: vuelves a esa pantalla, no a la de inicio.
- Posición de desplazamiento y pestaña. Esperado: la misma pestaña y, más o menos, la misma posición.
- Elementos seleccionados y filtros. Esperado: la selección y el filtro activo se mantienen.
- Flujo de varios pasos, como incorporación, pago o asistente de configuración. Esperado: el paso y las respuestas anteriores siguen ahí. Aquí es donde los usuarios pierden más.
- Diálogo o hoja inferior abierta. Esperado: o se restaura o se cierra limpiamente, nunca a medio dibujar.
- Estado con sesión iniciada. Esperado: el usuario sigue con la sesión iniciada.
- Tareas en curso. Subida, descarga, temporizador. Esperado: se reanuda, se reinicia de forma segura o muestra un fallo claro, sin duplicados.
- Desvío a un permiso o pantalla del sistema. Sal a un diálogo del sistema, mata la app y vuelve. Esperado: la app continúa el flujo.
- Enlace profundo o intent de compartir. Abre desde un enlace, mata la app y vuelve. Esperado: la pantalla correcta.
- Arranque en frío tras mucho tiempo. Deja la app horas y vuelve. Esperado: arranca sin fallos por datos obsoletos.
Qué reportar
Los pasos previos al cierre, el método exacto usado, lo que vio el usuario al volver y el nombre de la pantalla. Menciona si el dispositivo tenía poca memoria, porque puede provocar esto de forma natural.
Arreglar
Guarda lo que el usuario echaría de menos, en los lugares que Android ofrece para el estado guardado, y conserva los datos duraderos en almacenamiento y no en memoria. Vuelve a probar con los mismos pasos.
Límites
El comportamiento real con poca memoria varía entre dispositivos. La simulación comprueba cómo manejas el caso, no con qué frecuencia lo hará el sistema.
Visión general: Pruebas de apps Android. Relacionado: rotación y cambios de configuración y ahorro de batería y Doze.
Empieza gratis en AppReviewX y pide a los testers que sigan estos pasos e informen de forma estructurada.