Prueba cerrada de Google Play para apps de React Native

Google Play exige la firma de aplicaciones de Play para apps nuevas: Google guarda la clave de firma de la app y tú firmas las subidas con una clave de subida. Genérala con keytool, que viene con el JDK:

keytool -genkeypair -v -storetype PKCS12 -keystore my-upload-key.keystore \
  -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000

Mueve el archivo a android/app/ y guarda las credenciales en ~/.gradle/gradle.properties para que nunca acaben en git:

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
MYAPP_UPLOAD_STORE_PASSWORD=*****
MYAPP_UPLOAD_KEY_PASSWORD=*****

Luego añade una configuración de firma release en android/app/build.gradle y úsala en el tipo de build release. El de la plantilla firma con la clave de debug hasta que lo cambies:

android {
    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_UPLOAD_STORE_FILE')) {
                storeFile file(MYAPP_UPLOAD_STORE_FILE)
                storePassword MYAPP_UPLOAD_STORE_PASSWORD
                keyAlias MYAPP_UPLOAD_KEY_ALIAS
                keyPassword MYAPP_UPLOAD_KEY_PASSWORD
            }
        }
    }
    buildTypes {
        release {
            // ...
            signingConfig signingConfigs.release
        }
    }
}

Cada subida necesita un versionCode mayor que todo lo que hayas subido antes. En un proyecto bare está en android/app/build.gradle; versionName es la etiqueta que ven los usuarios:

android {
    defaultConfig {
        versionCode 2
        versionName "1.0.1"
    }
}

Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (nivel de API 36). Los niveles de SDK están en el bloque ext de android/build.gradle (compileSdkVersion, targetSdkVersion). Las versiones nuevas de React Native los suben. Si tu versión es antigua, actualizar React Native suele ser más seguro que subir solo targetSdkVersion, porque tus bibliotecas nativas también tienen que ser compatibles.

• Bundle firmado en debug. Si olvidas cambiar el tipo de build release a signingConfigs.release, Play Console rechaza la subida por estar firmada en debug.
• Sorpresas de R8/ProGuard. Con enableProguardInReleaseBuilds = true, las bibliotecas que usan reflexión pueden fallar solo en release. Añade sus reglas de conservación en android/app/proguard-rules.pro y prueba la release en un dispositivo.
• Informes de fallos ilegibles. Hermes, el motor predeterminado, ejecuta bytecode precompilado; las trazas de release apuntan al bundle compilado. Guarda los source maps de cada build que subas para simbolizar lo que envían los testers.
• La app busca Metro. Un build de release que intenta conectarse al servidor de desarrollo no tiene el JavaScript empaquetado. Revisa el ajuste configureondemand y vuelve a compilar.
• Módulos nativos y páginas de 16 KB. Las bibliotecas con archivos .so nativos 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. Actualízalas antes de empezar la prueba.
• Keystore perdido. Haz copia del keystore y sus contraseñas. Puedes pedir un restablecimiento de la clave de subida en Play Console, pero lleva un tiempo que no quieres perder en mitad de la prueba.

Un fallo de JavaScript en un build de release te llega como una posición de bytecode de Hermes, por ejemplo p@1:132161, que por sí sola no dice nada. React Native genera source maps para los builds de release de Android por defecto; lo importante es guardar el mapa correcto de cada bundle que subes.

1. 1

   Archiva el source map

   Después de cada build de release, copia el mapa de android/app/build/generated/sourcemaps/react/release/ y etiquétalo con el código de versión. Debe coincidir exactamente con el commit del build que falló: incluso un cambio pequeño desplaza los offsets.

2. 2

   Ejecuta metro-symbolicate

   Guarda el stack trace del tester en un archivo, o léelo directamente de adb logcat, y pásalo por metro-symbolicate con ese mapa. La herramienta convierte los offsets de bytecode en nombres de archivo, líneas y funciones.

3. 3

   Revisa las líneas nativas en Play Console

   Los fallos en el código Java o Kotlin de los módulos nativos aparecen en Supervisar y mejorar → Android vitals → Fallos y ANR. Con R8 activado, el archivo de mapeo incluido en el .aab los hace legibles sin subir nada más.

# From a saved stack trace
npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map < stacktrace.txt

# From a connected device
adb logcat -d | npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map

Si metro-symbolicate termina al instante sin mostrar nada, no recibió entrada: pasa el stack trace con una tubería o una redirección, no escribiéndolo en la terminal.

En cuanto tu bundle de React Native 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 React Native: sube versionCode (y versionName), vuelve a compilar y sube el nuevo bundle al mismo canal cerrado.

cd android
./gradlew bundleRelease

Desinstala la app de debug antes de instalar la variante de release con npm run android -- --mode="release"; Android no reemplaza una app firmada con otra clave. Repite esta comprobación antes de cada subida, porque los problemas exclusivos de release, como reglas keep que faltan, nunca aparecen en debug.

Las actualizaciones de JavaScript over the air son una zona gris por la que preguntan muchos equipos. La política de Google Play sobre uso inadecuado de dispositivos y redes dice que una app no puede actualizarse fuera de Google Play, pero la restricción no se aplica al código que se ejecuta en una máquina virtual o un intérprete, como JavaScript. El código nativo, los permisos nuevos y los módulos nativos siempre necesitan un bundle nuevo a través de Google Play.

• El canal cerrado sigue siendo la vía principal. Un versionCode nuevo en el canal cerrado llega a todos los testers con opt-in a través de Google Play y queda en tu historial de versiones.
• No toques las dependencias nativas. Actualizar React Native o un módulo nativo a mitad de la prueba cambia mucho más que el error que corriges. Hazlo antes de la prueba o después del acceso a producción.
• Un mapa por versión. Cada build nuevo genera un source map nuevo. Guárdalo con el código de versión, o el próximo informe de fallo de esa versión no se podrá descifrar.