Prueba cerrada de Google Play para apps de Flutter

La firma de aplicaciones de Play es obligatoria para apps nuevas: Google guarda la clave de firma de la app y tú firmas cada subida con tu propia clave de subida. Si alguna vez la pierdes, puedes pedir a Google que la restablezca; tu app no se pierde con ella. Crea la clave con keytool:

keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA \
        -storetype JKS -keysize 2048 -validity 10000 -alias upload

Después crea android/key.properties con las contraseñas y la ruta del keystore. Ni este archivo ni el .jks deben entrar en el control de versiones:

storePassword=<keystore password>
keyPassword=<key password>
keyAlias=upload
storeFile=/Users/<you>/upload-keystore.jks

Carga el archivo en android/app/build.gradle.kts y haz que el tipo de build release use la nueva configuración de firma:

import java.util.Properties
import java.io.FileInputStream

val keystoreProperties = Properties()
val keystorePropertiesFile = rootProject.file("key.properties")
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(FileInputStream(keystorePropertiesFile))
}

android {
    // ...
    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties.getProperty("keyAlias")
            keyPassword = keystoreProperties.getProperty("keyPassword")
            storeFile = keystoreProperties.getProperty("storeFile")?.let { file(it) }
            storePassword = keystoreProperties.getProperty("storePassword")
        }
    }
    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Los proyectos antiguos usan build.gradle (Groovy) en lugar de build.gradle.kts; los campos son los mismos. Ejecuta flutter clean después de cambiar archivos de Gradle.

Cada subida necesita un código de versión mayor que el de cualquier bundle que hayas subido antes, en cualquier canal. En Flutter es el número que va después del + en pubspec.yaml:

version: 1.0.0+1

1.0.0 es el nombre de versión que ven los usuarios y 1 es el código de versión. Súbelo a +2, +3, etc., o sobrescribe ambos al compilar con --build-name y --build-number.

Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (nivel de API 36) o superior. El archivo de Gradle usa targetSdk = flutter.targetSdkVersion, así que actualizar Flutter es la forma habitual de subirlo. Si tu versión de Flutter es antigua, pon targetSdk = 36 tú mismo y prueba en una versión reciente de Android antes de subir.

• Número de build repetido. Play Console rechaza un bundle cuyo código de versión ya se usó. Sube el +N de pubspec.yaml antes de cada build que pienses subir.
• Ofuscación sin símbolos. --obfuscate solo funciona junto con --split-debug-info. Guarda la carpeta de símbolos de cada build que subas; sin ella no podrás leer los fallos que reporten los testers.
• Flavor equivocado. Con flavors es fácil subir el build de staging con los endpoints de staging. Los testers reportan entonces errores que los usuarios de producción nunca verían.
• Sin red en release. Si falta el permiso INTERNET en el manifiesto principal, la app funciona en debug y falla en silencio a los testers.
• Bundle firmado en debug. Si el tipo de build release sigue usando la firma de debug, Play Console rechaza la subida.
• Plugins con código nativo antiguo. Los plugins que incluyen bibliotecas .so deben admitir páginas de memoria de 16 KB. Play Console avisa de ello y, a partir del 1 de febrero de 2027, no se podrán publicar actualizaciones sin esa compatibilidad. Actualiza plugins y el SDK de Flutter antes de la prueba, no a mitad.

flutter build appbundle --obfuscate --split-debug-info=build/symbols

Los testers pegan stack traces en sus informes de errores, y Play Console reúne los fallos en Supervisar y mejorar → Android vitals → Fallos y ANR. Un stack trace de Flutter tiene dos mitades: la parte de Dart, que --obfuscate convierte en nombres cortos y sin sentido, y la parte de Android, que R8 reduce. Flutter activa siempre la reducción de código en los builds de release, así que prepárate para ambas.

1. 1

   Guarda los símbolos de Dart

   Un build hecho con --split-debug-info escribe un archivo de símbolos por arquitectura, como app.android-arm64.symbols. Guarda la carpeta junto al código de versión al que pertenece: el archivo de otro build no puede descifrar el stack trace.

2. 2

   Descifra los stack traces de Dart

   Guarda el stack trace en un archivo y pásalo a flutter symbolize junto con el archivo de símbolos de la arquitectura del dispositivo. La mayoría de los teléfonos actuales son arm64.

3. 3

   Deja la parte Java a Play Console

   Con el plugin de Android para Gradle 4.1 o posterior, el archivo de mapeo de R8 viaja dentro del .aab, así que Play Console desofusca las líneas Java y Kotlin de los plugins sin subir nada aparte.

flutter symbolize -i crash.txt -d build/symbols/app.android-arm64.symbols

La ofuscación solo renombra símbolos; no cifra nada y no es un lugar para secretos. El código que compara runtimeType.toString() con un nombre de clase se rompe al ofuscar, mientras que los nombres de los enum siguen siendo legibles.

En cuanto tu bundle de Flutter esté compilado y firmado, el resto ocurre en Play Console y funciona igual con cualquier framework. Esta es la lista de comprobación; cada menú y cada pantalla están en la guía completa de Play Console.

• Termina la configuración de la app en el Panel: política de privacidad, acceso a la app, anuncios, clasificación de contenido, público objetivo, seguridad de los datos y ficha de Play Store.
• Crea una versión de prueba cerrada en Probar y publicar → Pruebas → Prueba cerrada: elige los países de tus testers, sube el .aab y envíalo a revisión.
• Añade testers con un Google Group en la pestaña Testers y comparte el enlace de opt-in. Funciona en cuanto el canal muestra Publicado.
• Mantén al menos 12 testers con opt-in durante 14 días seguidos. Las pruebas internas no cuentan, y quien sale y vuelve empieza sus 14 días de nuevo.
• Publica al menos una actualización durante la prueba y apunta qué encontraron los testers y qué cambiaste.
• Solicita acceso a producción desde el Panel y responde las tres secciones sobre tu prueba, tu app y tu preparación. La decisión es de Google; nadie puede garantizar la aprobación.

Cuenta con bajas: recluta más de 12 testers para que una baja no retrase tu calendario. Ver todos los pasos de Play Console.

En Flutter: sube el número de build, vuelve a compilar y sube el nuevo bundle al mismo canal cerrado.

flutter build appbundle --build-name=1.0.1 --build-number=2

Antes de cada subida, ejecuta el build de release en un teléfono real. flutter install instala el APK de release en un dispositivo conectado y detecta en minutos permisos que faltan, flavors equivocados y fallos que solo ocurren en release:

flutter build apk
flutter install

Para probar el bundle exacto que vas a subir, conviértelo en APK de dispositivo con bundletool de Google, o súbelo al canal cerrado e instálalo desde Google Play con una cuenta de tester. Así pruebas lo que reciben los testers, incluidos los APK divididos por dispositivo de Play.

• Un cambio concreto por actualización. Las versiones pequeñas dejan claro qué corrección respondió a qué informe de un tester y te dan ejemplos concretos para el formulario de acceso a producción.
• No cambies de versión de Flutter a mitad de la prueba, salvo que un error informado por los testers lo exija. Una actualización del SDK cambia a la vez el motor, el código nativo de cada plugin y quizá targetSdk.
• Deja tiempo para la revisión. Cada nueva versión del canal cerrado se envía a Google antes de llegar a los testers, así que no dejes tu última corrección para el último día.