Configurar Android Sandbox Testing

Probar compras in-app requiere una configuración correcta en Google Play Console. Esta guía te explica cómo configurar las pruebas en sandbox para tu app de Android.

Usa el build adecuado para cada tarea

Antes de empezar, distingue estos tres tipos de build de Android:

• Build local de debug/dev: Ideal para probar la UI e integraciones nativas en tu dispositivo.
• AAB de release firmado en Play Console: Necesario para pruebas realistas de Google Play billing.
• Build de prueba instalado desde Play: El build que tus testers instalan desde un track interno o cerrado. Úsalo para el QA de compras.

Si solo haces sideload de un APK desde Android Studio o adb, Google Play Billing podría no comportarse igual que en producción. Para validar suscripciones y compras in-app, prueba siempre con un build instalado desde Google Play.

Requisitos

• Una cuenta de desarrollador en Google Play Console. Si aún no tienes una, empieza en el registro en Play Console.
• Un registro de app creado en Play Console con el nombre de paquete de Android final
• Tus productos in-app o suscripciones creados en Play Console
• Una cuenta de Gmail de prueba que puedas añadir a las pruebas de licencia
• Un release build firmado y listo para subir

Antes de dedicar tiempo a la configuración de la facturación, crea la app en Play Console y decide si será gratuita o de pago. Google permite pasar una app de pago a gratuita después, pero una vez que una app se ofrece gratis, no puede volver a ser de pago.

Usa un Android App Bundle (.aab) para nuevas apps de Play Store:

bunx cap sync android
cd android
./gradlew bundleRelease

Asegúrate de tener configurada la firma de release de Android antes de ejecutar bundleRelease. Si aún no has configurado el keystore, la signing config o las contraseñas de release, genera el bundle firmado desde Android Studio con Build > Generate Signed App Bundle / APK, donde podrás introducir esos valores.

Proceso de configuración

1. Añadir cuenta de prueba

   En Play Console, abre Ajustes > Pruebas de licencias y añade la cuenta principal de Google usada en tu dispositivo Android de prueba.

   Esto asegura que las compras muestren el flujo de sandbox de Play en lugar de intentar un cargo real.

   

2. Elige una vía de prueba

   Ve a Prueba y lanzamiento > Pruebas y elige una de estas vías:

   • Pruebas internas: La vía más rápida para QA y smoke tests de facturación. Los nuevos bundles suelen estar listos en minutos.
   • Pruebas cerradas: Mejor para pruebas exhaustivas y obligatorio en producción para cuentas de desarrollador personales creadas después del 13 de noviembre de 2023.

   En el primer lanzamiento, Play puede mostrar un nombre de app y datos de la ficha temporales a los testers internos hasta por 48 horas.

   

3. Crear lista de testers

   Tras abrir tu canal, crea una lista de testers y añade las cuentas de Google que recibirán el build.

   Si buscas acceso a producción con una cuenta personal recién creada, asegúrate de usar pruebas cerradas y mantén al menos 12 testers inscritos durante 14 días consecutivos.

   

4. Subir un build de release firmado

   Crea un nuevo release en el canal de pruebas seleccionado y sube tu build firmado .aab.

   Las nuevas apps de Google Play deben usar Android App Bundle en vez de APK. Tras la subida, guarda el release, corrige los bloqueos de políticas o de la ficha de la tienda que Play señale y publica el release en el canal de pruebas.

   

5. Unirse al programa de pruebas

   Abre la URL de registro en tu dispositivo de prueba y haz clic en el botón “Become a tester” para inscribirte.

   Instala la app desde la ficha de la Play Store creada por ese flujo, no desde un APK exportado localmente.

   

6. Build y Test

   Ejecuta la build instalada desde Play en el dispositivo de prueba e intenta realizar una compra. Deberías ver un mensaje como:

   “Esta es una orden de prueba; no se te realizará ningún cargo.”

   

Notas importantes

• Para QA de facturación, desinstala cualquier copia de la app instalada vía sideload antes de instalar la build de testing de Play.
• Las pruebas internas son ideales para smoke tests rápidos, pero las pruebas cerradas son el camino real para obtener acceso a producción con cuentas personales.
• Las cuentas de prueba no recibirán cargos por las compras
• Las compras de prueba usan el mismo flujo que las de producción
• Puedes probar todas las funciones de suscripción, incluyendo periodos de prueba y ofertas de bienvenida
• Las suscripciones de prueba tienen periodos de renovación acelerados para agilizar los tests
• Usa la misma cuenta de Google en los tres sitios: la Play Store del dispositivo, el flujo de opt-in del tester y License testing

Solución de problemas

Si los productos no aparecen en modo de prueba:

• Asegúrate de que tu app esté subida a una vía de pruebas
• Verifica que la cuenta de prueba esté añadida a License testing
• Comprueba que los productos estén activos en Google Play Console
• Confirma que el build se instaló desde Google Play y no mediante sideload local

Error “Item not available”:

• Espera 2-3 horas tras crear los productos para que estén disponibles
• Asegúrate de que el package name de tu app coincida con el de Play Console
• Verifica que hayas iniciado sesión con una cuenta de prueba
• Confirma que subiste el signed release build que apunta al mismo package name y catálogo de productos

Compras de prueba que aparecen como cargos reales:

• Revisa que la cuenta esté añadida a License testing
• Asegúrate de usar el build del track de pruebas
• Verifica que aparezca el banner de prueba durante la compra

Recursos adicionales

• Prueba compras con Google Play Billing
• Configura una prueba abierta, cerrada o interna
• Requisitos de prueba para nuevas cuentas de desarrollador personales

Continúa desde Configurar pruebas en el sandbox de Android

Si estás usando Configurar pruebas en el sandbox de Android para planificar la aprobación y distribución en la tienda, conéctalo con Uso de @capgo/native-purchases para la capacidad nativa al usar @capgo/native-purchases, @capgo/capacitor-in-app-review para el detalle de implementación en @capgo/capacitor-in-app-review, Usando @capgo/capacitor-in-app-review para la capacidad nativa en «Usando @capgo/capacitor-in-app-review», @capgo/capacitor-native-market para el detalle de implementación en @capgo/capacitor-native-market, y Usando @capgo/capacitor-native-market para la capacidad nativa en «Usando @capgo/capacitor-native-market.»