Prueba cerrada de Google Play para apps de Ionic y Capacitor

Google Play exige la firma de aplicaciones de Play para apps nuevas. El keystore que creas en el asistente de Android Studio (Create new) o que pasas a npx cap build es tu clave de subida; Google guarda la clave de firma de la app, que es distinta, después de tu primera subida.

Android Studio recomienda una validez de al menos 25 años para una clave nueva. Guarda el archivo .jks fuera de la carpeta android/ por si algún día regeneras el proyecto nativo, y haz copia junto con las dos contraseñas. Si pierdes la clave de subida, puedes pedir un restablecimiento en Play Console.

Si guardas opciones de build en la configuración de Capacitor, no pongas las contraseñas en el archivo que subes al repositorio. La configuración forma parte de él.

Capacitor no lee la versión de package.json. Los valores que ve Google Play están en android/app/build.gradle; sube versionCode antes de cada subida:

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). Capacitor fija targetSdkVersion en android/variables.gradle y cada versión mayor admite exactamente un valor: Capacitor 8 usa 36 y Capacitor 7 usa 35. No se admiten valores personalizados, así que el camino a la API 36 es actualizar a Capacitor 8 junto con tus plugins, no cambiar el número.

ext {
    // ...
    targetSdkVersion = 36
}

• Live reload activado. Un server.url en la configuración de Capacitor hace que la app cargue la dirección de tu máquina de desarrollo. Los testers ven una pantalla en blanco. Quítalo antes del build de release.
• Recursos web caducados. Generar el bundle en Android Studio sin ejecutar antes npx cap sync android publica el build web anterior.
• Plugins en otra versión mayor. Todos los paquetes @capacitor/* y los plugins de la comunidad deben coincidir con la versión mayor de @capacitor/android. Si no, aparecen errores de build nativo o cierres en ejecución.
• Peticiones en texto plano. Android bloquea por defecto el tráfico http:// sin cifrar. Los builds de producción deben llamar solo a APIs HTTPS.
• Plugins nativos y páginas de 16 KB. 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.
• Probar solo en el navegador. El botón atrás, los permisos y los enlaces profundos se comportan distinto en la WebView de Android. Instala el build de release en un dispositivo real antes de subirlo.

La mayoría de los problemas de un build de release de Capacitor están en la capa web, así que las herramientas del navegador que ya conoces son la mejor entrada. En un build de release están desactivadas: webContentsDebuggingEnabled es false por defecto, y los logs propios de Capacitor siguen loggingBehavior, cuyo valor por defecto es debug, de modo que los builds de release no registran nada.

1. 1

   Reprodúcelo en un build de debug

   Ejecuta la app en un teléfono desde Android Studio, abre chrome://inspect en Chrome en tu ordenador y elige la WebView. Tendrás la consola, el panel de red y los puntos de interrupción de tu código web. edge://inspect funciona igual en Edge.

2. 2

   Inspecciona un build de release solo en local

   Si un error solo aparece en release, pon temporalmente webContentsDebuggingEnabled en true en un build que instales tú. No subas nunca ese build: hace que el contenido web de tu app se pueda depurar en cualquier dispositivo.

3. 3

   Recoge los fallos nativos en Play Console

   Los fallos en el código Java de Capacitor o en plugins 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.

const config: CapacitorConfig = {
  // ...
  android: {
    // Never ship this to Google Play
    webContentsDebuggingEnabled: true,
  },
};

Pide a los testers el modelo del dispositivo, la versión de Android y la versión de Android System WebView. Muchos errores exclusivos de la WebView dependen de ese último número, y todo lo que esté por debajo de android.minWebViewVersion queda fuera de lo que admite tu app.

En cuanto tu bundle de Ionic / Capacitor 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.

Vuelve a compilar la app web, sincroniza, sube versionCode y genera un nuevo bundle firmado para el mismo canal cerrado:

npm run build
npx cap sync android
npx cap open android

La política de Google Play sobre uso inadecuado de dispositivos y redes prohíbe que una app se actualice fuera de Google Play, con una excepción para el código que se ejecuta en un intérprete o una máquina virtual, como JavaScript en una WebView. Por eso existen servicios de actualización en vivo para la capa web. El código nativo, los plugins y los permisos siempre necesitan un bundle nuevo a través de Google Play.

Durante la prueba cerrada, un versionCode nuevo en el canal cerrado es el camino directo: se revisa, los testers lo reciben por Google Play y queda en tu historial de versiones. Si además usas un servicio de actualización en vivo, resérvalo para correcciones reales y mantén sincronizado con él el build web del canal cerrado.

• Ojo con el mínimo de WebView. android.minWebViewVersion vale 60 por defecto y no puede bajar de 55. Los testers con problemas deberían actualizar primero Android System WebView desde Google Play.
• Nada de contenido mixto. android.allowMixedContent está desactivado por defecto y no está pensado para producción. Sirve cada API y cada recurso por HTTPS y deja server.cleartext en su valor por defecto, false.
• Sincroniza antes de cada build. Cada corrección necesita npx cap sync android después del build web, o el bundle nuevo seguirá llevando el JavaScript antiguo.