Por qué necesito una checklist y no confío en la memoria

La primera vez que generé una build release para Caladero, mi app de pesca que todavía estoy desarrollando, me llevé un buen susto: la app compilaba, se instalaba y se abría sin problemas, pero un fragmento de la pantalla de mapa se quedaba en blanco. En debug funcionaba perfecto. En release, no.

El motivo era la ofuscación de código. R8 había eliminado una clase que se usaba por reflexión y que yo nunca había marcado como excepción en las reglas de ProGuard. En debug esa optimización no se aplica con la misma agresividad, así que el problema pasó completamente inadvertido durante semanas.

Desde entonces uso una checklist fija antes de generar cualquier build release, aunque sea para pruebas internas. No es una lista teórica: cada punto está ahí porque en algún momento me falló.

Versión, firma y configuración de build

Lo primero que reviso es lo más aburrido y, precisamente por eso, lo que más se olvida:

  • versionCode incrementado respecto a la build anterior. Google Play rechaza subir una build con el mismo código de versión que otra ya existente en cualquier pista.
  • versionName coherente con lo que voy a comunicar (no siempre necesito subir el número visible aunque suba el versionCode interno).
  • El keystore de release es el correcto, no el de debug. Uso un archivo local.properties que no subo a git para las rutas y contraseñas, y compruebo con jarsigner -verify que el APK final está firmado con la clave que espero.
  • minifyEnabled y shrinkResources activados si es la build que voy a distribuir, para que el comportamiento sea el mismo que tendrá el usuario final.

Si alguno de estos puntos falla, prefiero descubrirlo aquí, no después de subir la build a una pista de pruebas.

Reglas de ofuscación y comportamiento en release

Este es el bloque que más tiempo me ha hecho perder, así que lo trato aparte:

  1. Reviso las reglas de proguard-rules.pro cada vez que añado una librería nueva, porque muchas dependencias (parsers JSON, librerías de mapas, clientes HTTP) necesitan reglas -keep específicas.
  2. Genero la build release y la instalo en un dispositivo físico, nunca me fío solo del emulador para esta comprobación.
  3. Navego manualmente por las pantallas que usan reflexión, serialización o librerías de terceros con configuración dinámica. En mi caso, eso incluye la capa de mapas y los modelos de datos que se serializan para guardarse en local.
  4. Si algo falla solo en release, activo temporalmente los logs de R8 (-printusage y -printmapping) para ver qué se ha eliminado o renombrado.

Una build release que compila sin errores no es lo mismo que una build release que funciona. Son dos comprobaciones distintas y las trato como tales.

Permisos, privacidad y contenido de prueba

Antes de considerar una build "lista para revisión externa" (aunque sea de una sola persona probándola), reviso:

  • Que no queden permisos de desarrollo que no debería pedir la versión final. En Caladero, por ejemplo, el permiso de ubicación precisa solo se solicita cuando el usuario va a marcar un punto exacto, no al abrir la app.
  • Que no haya datos de prueba visibles por defecto: nombres, coordenadas o comentarios que use durante el desarrollo y que no deberían aparecer en una build que otra persona pueda instalar.
  • Que los textos de permisos y de la política de privacidad reflejen exactamente lo que la app hace en esa versión, no lo que hacía hace dos semanas.

Esto tiene que ver con la política de datos de Google Play, que exige coherencia entre lo declarado y lo que la app realmente pide.

Errores que he cometido y prefiero no repetir

Algunos de estos ya me han pasado más de una vez, lo cual dice más sobre mí que sobre Android:

  • Subir una build con debuggable="true" en el manifest porque venía de una variante de build mal configurada.
  • Olvidar actualizar el versionCode después de un cambio pequeño, algo que solo descubro cuando la subida falla.
  • Probar la build únicamente en el mismo dispositivo con el que desarrollo, que suele tener más memoria y una versión de Android más reciente que la media.
  • Confiar en que "ya lo probé la semana pasada" cuando desde entonces he tocado dependencias o reglas de ofuscación.

Ninguno de estos errores es grave por separado, pero juntos explican por qué prefiero una lista escrita antes que confiar en la memoria del momento.

Dónde encaja esto en el resto del proceso

Esta checklist no sustituye las pruebas funcionales ni la revisión de accesibilidad; es un paso previo, específico de la build en sí. Antes de subir nada a una pista de Google Play, además de esto reviso los puntos que explico en mi checklist de errores antes de publicar en Google Play y en cómo preparo la información de Data Safety, porque una build técnicamente correcta con una ficha de Play mal preparada tampoco sirve de mucho.

Documentación oficial: Preparar una app para su lanzamiento y Android App Bundle.

Conclusión

No tengo una checklist porque sea especialmente ordenado por naturaleza; la tengo porque cada punto de esta lista representa un fallo real que ya cometí una vez. Cuando desarrollo solo, sin un equipo de QA detrás, la única red de seguridad que tengo es la que yo mismo decido escribir. Y esa lista solo funciona si la sigo siempre, incluso cuando tengo prisa por probar algo "rápido".