En esta guía
La nueva versión ya está publicada y los testers reportan cierres que la anterior nunca tuvo. Algo cambió entre las dos builds. La forma más rápida es seguir un orden fijo de comprobaciones, de la sospecha más probable y barata a la más rara y cara.
Paso 0: separa los dos tipos de cierre
Hazle al tester una pregunta: ¿se cerró después de actualizar sobre la versión anterior, o también en una instalación limpia?
- Solo tras actualizar: el problema está en la ruta de actualización, normalmente datos antiguos que se encuentran con código nuevo.
- También en una instalación limpia: el problema está en la nueva build en sí.
Esta sola respuesta reduce la búsqueda a la mitad.
Las comprobaciones, en orden
- Lee el informe del cierre. Obtén la traza de pila y la versión exacta. Anota la primera línea de tu propio código. Mira [cómo un tester envía un informe de bug de Android para saber qué pueden enviarte.
- Compara la versión. Lista qué cambió desde la última build buena: código, librerías, ajustes de compilación, configuración. El cierre casi siempre está en esa lista.
- Migración de datos. ¿Cambiaste un esquema de base de datos, un ajuste guardado o un formato de archivo? Los datos antiguos que el código nuevo no espera son el clásico cierre al actualizar. Mira [probar una migración de base de datos sin perder datos.
- Librerías o SDK actualizados. Una versión nueva puede cambiar el comportamiento o eliminar una función. Revisa los cambios de cada dependencia que se movió.
- Configuración y claves. Valores de configuración, claves de API, feature flags o ajustes del servidor que faltan o cambiaron y que la nueva build lee.
- Diferencias de compilación. La reducción de código y la ofuscación pueden eliminar o renombrar algo que se usa en tiempo de ejecución. Un cierre que aparece solo en la build de release y no en la de debug apunta aquí.
- Firma. Una build firmada de forma distinta a la anterior puede romper la actualización o el acceso a datos protegidos. Comprueba que las builds de prueba y de release están firmadas como pretendes.
- Cambios en el servidor. Un cambio en el backend lanzado a la vez puede parecer un cierre de la app. Comprueba si también fallan las versiones antiguas de la app.
Reproduce la actualización, no solo la build nueva
La mayoría de los equipos solo prueban una instalación limpia de la nueva versión. Haz esto en su lugar:
- Instala la versión publicada anterior y úsala hasta que tenga datos reales.
- Actualiza sobre ella a la nueva build.
- Abre cada pantalla principal y repite las acciones clave.
- Repite desde una versión mucho más antigua si aún tienes usuarios en una.
[Cómo probar una actualización de una app en producción explica esto en detalle.
Qué preguntar a los testers
- ¿Qué versión tenían antes y cuál tienen ahora?
- ¿Actualizaron o reinstalaron?
- ¿Qué hicieron justo antes del cierre?
- ¿Ocurre siempre?
Contén el problema
Una vez conozcas la causa, decide rápido: lanza una corrección o detén el despliegue si tus herramientas de la tienda lo permiten. Revisa las opciones actuales en la consola de tu tienda. Después, añade el caso de actualización que falló a tu checklist de lanzamiento.
Relacionado
- Hub: [Problemas de pruebas de apps: causas y soluciones
- [Prueba qué pasa cuando los usuarios deniegan permisos
- [Los testers no pueden iniciar sesión: problemas con cuentas de prueba
Los testers que ejecutan la versión anterior y luego actualizan detectan lo que una instalación limpia oculta. En AppReviewX recibes feedback privado y estructurado sobre tu build. Empieza gratis.