Prueba cerrada de Google Play para apps de Expo (EAS)

En el primer build de Android, EAS ofrece generar un keystore y lo guarda en los servidores de Expo; los builds posteriores lo reutilizan. Para Google Play, ese keystore es tu clave de subida. Al subir el primer bundle se configura la firma de aplicaciones de Play y Google guarda la clave de firma de la app.

Usa eas credentials para ver el keystore configurado, descargar una copia o sustituirlo. Guarda esa copia en un lugar seguro: la necesitarás si algún día compilas en local o dejas EAS.

eas credentials -p android

No generes un keystore nuevo después de la primera subida. Un bundle firmado con otra clave de subida se rechaza hasta que pidas un restablecimiento de la clave de subida en Play Console.

Play Console rechaza cualquier bundle cuyo versionCode ya se haya usado. Lo más sencillo es que EAS lo gestione en remoto y lo incremente en cada build de producción:

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "production": { "autoIncrement": true }
  },
  "submit": {
    "production": {
      "android": { "track": "alpha", "releaseStatus": "draft" }
    }
  }
}

Con appVersionSource en remote, EAS guarda el código de versión e ignora android.versionCode en la configuración de la app. Si ya subiste builds a mano, ejecuta una vez eas build:version:set para que EAS siga desde tu último número.

Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (nivel de API 36). Cada versión del SDK de Expo fija el SDK objetivo por ti, así que la solución fiable es una versión del SDK que apunte a 36. El plugin de configuración expo-build-properties puede sobrescribir targetSdkVersion, pero hazlo solo si tu SDK y tus bibliotecas lo admiten.

• eas submit va a la prueba interna. Por defecto, eas submit -p android envía el build al canal interno, que no cuenta para la regla de 12 testers. Pon "track": "alpha" (el canal cerrado predeterminado de Google) en el perfil de envío, como arriba, o sube a mano el .aab descargado al canal cerrado.
• Primeras versiones solo en borrador. Mientras la app no se haya publicado nunca, Google solo acepta versiones en borrador a través de la API. Mantén "releaseStatus": "draft" y termina el lanzamiento en Play Console.
• Hace falta una cuenta de servicio. eas submit usa una clave de cuenta de servicio de Google que subes a EAS en las credenciales de la app. Sin ella, sube el bundle a mano.
• Builds de desarrollo. Un build con developmentClient: true espera un servidor de desarrollo. Asegúrate de que los testers reciben el perfil de producción.
• Variables de entorno que faltan. Los valores de un archivo .env ignorado por git no se suben a EAS Build. Define los valores de producción como variables de entorno de EAS o la release hablará con el backend equivocado.
• Los cambios nativos necesitan un build nuevo. Los permisos, el nombre de paquete y los plugins de configuración solo llegan a los testers con un build nuevo de EAS, no con una actualización over-the-air.

eas submit -p android --profile production

Un build de producción no se comporta como Expo Go ni como un development build: no hay servidor de desarrollo, el JavaScript está minificado y solo están los módulos nativos que compilaste. Reproduce lo que ven los testers antes de hacer suposiciones.

1. 1

   Ejecuta el modo producción en local

   npx expo start --no-dev --minify ejecuta tu JavaScript como un bundle de release y muestra errores que el modo desarrollo nunca lanza.

2. 2

   Lee los logs nativos

   Conecta el teléfono por USB y ejecuta adb logcat. Los logs nativos suelen revelar la causa cuando una error boundary de JavaScript no atrapa el problema.

3. 3

   Revisa Play Console

   Los fallos de los testers aparecen en Supervisar y mejorar → Android vitals → Fallos y ANR. El informe previo al lanzamiento, que Google genera automáticamente tras una subida, también ejecuta la app en dispositivos de prueba y enumera los fallos que encontró.

4. 4

   Haz legibles los errores de JavaScript

   Con Sentry, EAS Build sube los source maps automáticamente en cuanto SENTRY_AUTH_TOKEN está definido como variable de entorno sensible de EAS. Después de eas update, ejecuta npx sentry-expo-upload-sourcemaps dist para que las actualizaciones también sean legibles.

¿Necesitas depurar lo nativo? npx expo prebuild -p android crea la carpeta android para que puedas conectar el depurador de Android Studio. Bórrala después para que Expo siga gestionando el proyecto.

En cuanto tu bundle de Expo 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.

Con el versionado remoto, vuelve a lanzar el build de producción y súbelo o envíalo al canal cerrado; el código de versión sube solo.

eas build -p android --profile production

Para correcciones que solo tocan JavaScript, EAS Update puede entregar un bundle nuevo sin volver a enviar la app a la tienda. La política de Google Play sobre uso inadecuado de dispositivos y redes permite actualizar así el código que se ejecuta en un intérprete o una máquina virtual, como JavaScript; no permite descargar código nativo. Usa las actualizaciones para correcciones reales y mantenlas dentro de lo que hace el build revisado.

eas update --channel production --message "Fix checkout crash" --environment production

• Canales. eas update:configure define un channel en los perfiles de build preview y production. Un build solo recibe actualizaciones publicadas en su canal. Desde el SDK 55, --environment es obligatorio.
• Versión de runtime. Una actualización solo llega a builds con la misma versión de runtime. La política fingerprint la cambia con cualquier cambio que afecte al runtime nativo, así que las actualizaciones incompatibles son muy improbables.
• Reinicios. Los builds de release descargan la actualización en segundo plano y la aplican tras reiniciar la app. Pide a los testers que cierren y vuelvan a abrir la app, hasta dos veces.
• Los cambios nativos necesitan un build. Permisos nuevos, config plugins o bibliotecas nativas solo llegan a los testers con un build de producción nuevo en el canal cerrado, que además deja una versión visible en Play Console.