Respuesta rápida
Google Play le aplica a un juego de Android el mismo requisito previo de prueba cerrada para el acceso a producción que a cualquier otra app. Si el juego se publica desde una cuenta personal de desarrollador creada después del 13 de noviembre de 2023, al menos 12 testers tienen que haber aceptado participar en una prueba cerrada durante al menos los últimos 14 días de forma continua antes de que puedas solicitar el acceso a producción. Google exigía en un principio 20 testers y rebajó el mínimo a 12 el 11 de diciembre de 2024; en su documentación actual no aparece ningún número de testers, ninguna duración ni ninguna excepción aparte para los juegos. Llegar a la cifra no es la aprobación, porque Google pregunta además cómo interactuaron los testers, qué comentarios dieron y qué cambiaste tú, y puede exigir más pruebas. Los juegos cargan encima con riesgos de publicación que ese contador no mide nunca: la entrega de recursos, el tiempo de fotograma, el código nativo de 64 bits, la prueba de las compras integradas y la autorización de Play Games Services. Si la parte que no puedes cubrir es la de los testers, PrimeTestLab la ejecuta con testers reales en dispositivos reales.
También vigente ahora mismo si publicas juegos
El 31 de agosto de 2026 ya pasó: los juegos móviles nuevos y actualizados tienen que apuntar a Android 16 (nivel de API 36) o posterior, y Play Billing Library 7 ya ha superado su fecha límite para apps nuevas y actualizaciones. Los envíos para Wear OS y Android Automotive OS necesitan el nivel de API 35, y los de Android TV y Android XR, el 34. Si tienes una prórroga, llega hasta el 1 de noviembre de 2026. Ninguno de los dos forma parte del requisito de testers, y los dos pueden bloquear justo la publicación que ese requisito debería desbloquear.
La mayoría de las guías que ya existen responden a la mitad de este problema. Las páginas generales sobre la prueba cerrada explican el requisito de 12 testers sin tocar los riesgos de publicación propios de un juego, mientras que las páginas de QA de juegos hablan de rendimiento y de laboratorios de dispositivos sin explicar la puerta del acceso a producción, que es la que de verdad está bloqueando el lanzamiento. Los hilos de la comunidad rellenan el hueco entre unas y otras con folclore dicho con mucha seguridad: jugar una vez al día, subir tres actualizaciones, treinta minutos por sesión, un número mínimo de niveles. Nada de eso son reglas publicadas por Google, y este artículo lo dice cada vez que aparece una. Todo lo que hay aquí está actualizado a 12 de agosto de 2026, con las fechas límite de las políticas vueltas a comprobar el 14 de agosto de 2026, y todo procede de documentación primaria de Google; cuando la respuesta honesta es “Google no publica eso”, la página escribe eso en lugar de una cifra.
El orden de abajo sigue el orden en que se resuelve el problema de verdad. Primero la puerta en sí, porque no puedes planificar nada hasta saber si te afecta y qué cuenta exactamente. Después la capa propia de un juego: lo que no detecta una prueba que solo acumula cuentas que han aceptado participar, y cómo probar cada uno de esos riesgos antes de que los revisores de Google vean el resultado.
El banco de pruebas
Tres instrumentos hechos para las tres preguntas que quien desarrolla un juego no puede responder solo con la documentación de Google. Cada uno funciona por completo en tu navegador, con los valores que tú escribes. No se sube nada y no hace falta ninguna cuenta.
Tabla de contenidos
¿Google Play exige una prueba cerrada para los juegos de Android?
Sí, en las mismas condiciones que cualquier otra app. Si el juego se publica desde una cuenta personal de desarrollador creada después del 13 de noviembre de 2023, tienes que ejecutar una prueba cerrada con al menos 12 testers (verificadores, en la documentación oficial de Google en español) que hayan aceptado participar durante los últimos 14 días de forma continua antes de poder solicitar el acceso a producción. Google no publica ni un número de testers aparte, ni una duración más corta, ni ninguna excepción para los juegos.
“Si acabas de crear una cuenta personal de desarrollador, tienes que ejecutar una prueba cerrada de tu app con un mínimo de 12 testers que hayan aceptado participar durante al menos los últimos 14 días de forma continua.”
Ayuda de Play Console, respuesta 14151465
Lee esa frase por lo que no dice. No menciona categorías de apps. El disparador va pegado a la cuenta, no a lo que subes, así que el hecho de que tu bundle esté catalogado como juego no cambia nada respecto a si te aplica la puerta. El propio material de Google sobre la prueba cerrada trata apps y juegos dentro del mismo proceso de acceso a producción, y menciona de forma explícita las pruebas previas al lanzamiento de juegos móviles como uso de los canales de pruebas (segmento de pruebas en la documentación de Google en español de LatAm).
Léela una vez más fijándote en tu app. La fecha de creación de la cuenta decide si el requisito te aplica, pero la prueba que cuenta y la solicitud de acceso a producción se completan para una app concreta. Superar el proceso con un juego no se traslada al siguiente paquete que publiques desde la misma cuenta: un segundo juego tiene su propia prueba cerrada, sus propios 12 testers y sus propias dos semanas. Esa conclusión se apoya en que Google escribe la condición sobre “tu app” y en que el acceso a producción se solicita por paquete, y no en una frase publicada que descarte el traslado; planifica una prueba nueva por juego y mira el panel de tu consola para esa app concreta antes de dar nada por hecho en un sentido o en el otro.
Hallazgo negativo “No hay excepción para los juegos” es una conclusión que sale de que no aparezca ninguna en la documentación actual de Google, no una frase que Google publique. Es una distinción con sentido y este artículo la mantiene: en todo el material actual sobre el acceso a producción no se encontró ningún número de testers ni ninguna duración alternativos para los juegos, así que la lectura segura es que las cuentas personales afectadas usan el mismo requisito previo, publiquen lo que publiquen.
Qué cuenta de verdad la regla
12
Testers, mínimoCuentas individuales que completaron la aceptación. Ni la gente a la que escribiste, ni la gente que te dijo que sí.
14
Días continuosCada una de esas 12 cuentas tiene que llevar participando los 14 últimos días completos cuando solicitas el acceso.
1
Alcance por cuenta, prueba por appLa cuenta decide si la regla te aplica. La prueba que cuenta se ejecuta por app.
Si has leído que el número es 20, esa página está desactualizada. Google fijó al principio el umbral en 20 testers y lo rebajó a 12 el 11 de diciembre de 2024, describiendo el cambio con sus propias palabras como exigir “12 testers en lugar de 20”, y dejando intacto el periodo de dos semanas. La historia está contada en detalle en el artículo sobre el cambio de 20 a 12 testers, y la mecánica del requisito en sí en el artículo sobre el requisito de los 12 testers. Este artículo da las dos cosas por sabidas y se centra en lo que cambia cuando lo que publicas es un juego.
¿Qué desarrolladores de juegos necesitan de verdad 12 testers?
El requisito previo se limita a las cuentas personales de desarrollador creadas después del 13 de noviembre de 2023. Las cuentas de organización y las cuentas personales anteriores quedan fuera de este requisito concreto. Subir un juego en vez de una app no te mete ni te saca de él, y hacer una prueba interna con hasta 100 personas no lo cumple.
| Tu situación | ¿12 testers, 14 días? | La explicación segura |
|---|---|---|
| Cuenta personal creada después del 13 de nov de 2023 | Sí | Haz una prueba cerrada con al menos 12 testers que hayan aceptado participar de forma continua durante los últimos 14 días y después solicita el acceso a producción. |
| Cuenta personal creada antes de esa fecha | No por esta regla | Google limita el requisito a las cuentas personales creadas después del 13 de noviembre de 2023. |
| Cuenta de organización | No por esta regla | El requisito está escrito expresamente para las cuentas personales que entran en ese supuesto. Eso no es lo mismo que estar exento de las pruebas, de la calidad o de la revisión de políticas. |
| Un juego en lugar de una app normal | Sin caso especial | En la documentación actual de Google sobre el acceso a producción no aparece ningún número de testers ni ninguna duración alternativos para los juegos. |
| Ya hiciste una prueba interna con 100 personas | Sigue siendo obligatorio | La prueba interna y la prueba cerrada son canales distintos. El requisito previo exige específicamente una prueba cerrada. |
| Ya cumpliste esto con otro juego en la misma cuenta | Sigue siendo obligatorio | Google redacta el requisito como una prueba cerrada «para tu app». La cuenta decide si la regla te aplica; la prueba que califica se completa por cada nombre de paquete. |
«Las cuentas de organización están exentas» es la frase equivocada
Una cuenta de organización queda fuera de este requisito previo concreto de las cuentas personales nuevas. Sigue teniendo todas las obligaciones normales: revisión, política de contenido, estándares de calidad, declaraciones y reglas de distribución. Registrarse como organización para esquivar un requisito de testers también significa asumir la verificación de organización, y el tipo de cuenta que elijas tiene consecuencias mucho más allá de esta única puerta. Las contrapartidas están explicadas en el artículo sobre la cuenta personal frente a la de organización.
Un apunte de contexto general sobre las cuentas, porque sale en la misma conversación y se confunde a menudo con el coste de las pruebas: Google cobra una tarifa de registro única de 25 USD para abrir una cuenta de desarrollador. Esa tarifa no tiene nada que ver con el requisito de pruebas. Hacer una prueba cerrada no cuesta dinero en Play Console; lo que cuesta es encontrar a doce personas que se queden.
Que es el problema real cuando se trata de un juego. Comparado con una app de utilidades, un juego suele necesitar sesiones más profundas para que sus defectos salgan a la luz siquiera: la progresión y el estado guardado, la entrega de recursos, el comportamiento térmico y la monetización solo se portan mal cuando alguien ha jugado lo bastante como para tener algo que perder. Ninguna de las dos categorías se prueba bien con gente que instala una versión y la deja quieta durante dos semanas, y Google valora la participación y los comentarios tanto en las apps como en los juegos. Un juego solo hace que la versión superficial de ese error salga más cara, porque necesitas gente que juegue de verdad, con hardware parecido al de un jugador y durante el tiempo suficiente para llegar al segundo acto. De esa brecha va el resto de este artículo.
¿Cómo funciona la prueba cerrada de 14 días en un juego?
Publica una versión en el canal cerrado, consigue que al menos 12 testers completen la aceptación de participar y mantenlos participando mientras juegan de verdad. Cuando solicites el acceso, al menos 12 de ellos tienen que llevar participando los últimos 14 días de forma continua. Después solicita el acceso a producción desde el panel de Play Console. La prueba interna admite hasta 100 testers y es útil, pero no cubre este paso.
Fuente: el requisito de prueba cerrada para las cuentas personales nuevas (respuesta 14151465). El mínimo de 12 testers sustituyó al de 20 el 11 de diciembre de 2024; el periodo continuo de 14 días no cambió.
-
01
Antes del día uno
Publica la versión de la prueba cerrada y ponla a disposición de tus testers. Comprueba que la compilación entregada por Play se instala y se ejecuta, que llegan los paquetes de recursos, que el inicio de sesión de Play Games funciona y que todo lo que la prueba necesita alcanzar es accesible. Una compilación que funciona desde tu máquina no dice nada sobre la compilación que ensambla Play.
-
02
Aceptar participar
Cada tester tiene que aceptar la invitación, no basta con que aparezca en una lista. Aquí tropieza muchísima gente: añadir a alguien a una lista de correos o a un grupo de Google es una acción tuya, y aceptar participar es una acción suya. Cuenta solo las cuentas que la han completado.
-
03
Del día uno al catorce
Al menos 12 testers siguen participando de forma continua mientras juegan. Recluta por encima del mínimo para que una sola baja no te deje corto. Google pregunta por la interacción y por los comentarios cuando solicitas el acceso, así que el resultado útil de estas dos semanas es una lista de cosas que te ha dicho la gente, no una captura de pantalla de un contador.
-
04
Durante la prueba
Corrige defectos reales y sigue actualizando la compilación. Subir versiones nuevas durante la ventana es normal y no reinicia nada: la condición que cuenta está escrita sobre el historial de participación de cada tester, no sobre la antigüedad de una compilación congelada. Esto se deduce de la redacción de Google sobre la participación continua de cada tester; Google no publica ninguna regla aparte sobre actualizar la compilación, ni en un sentido ni en el otro. Pon a prueba las rutas de instalación y actualización, la progresión y las partidas guardadas, las descargas de recursos, los fallos, el rendimiento, las compras y Play Games tal y como los use tu juego.
-
05
Tras la ventana que cuenta
Ve a Dashboard > Apply for production y responde con honestidad sobre quién probó el juego, cómo interactuó, qué dijo, qué cambiaste tú y por qué el juego está listo.
-
06
Revisión
Google dice que esto suele tardar 7 días o menos y que alguna vez puede tardar más. No es un acuerdo de nivel de servicio y nadie te puede prometer una fecha.
Una corrección que conviene hacer pronto, porque a mucha gente le cuesta dos semanas. La prueba interna es otro canal, con un tope mucho más alto: hasta 100 testers y disponible enseguida. Es de verdad útil para poner una compilación delante de la gente rápido. Lo que no hace es sustituir a la prueba cerrada que nombra el requisito. Las diferencias entre los tres canales están en el artículo sobre pruebas internas, cerradas y abiertas, y la prueba abierta solo queda disponible cuando ya tienes acceso a producción.
¿Los testers tienen que jugar todos los días?
Aquí es donde se equivoca casi cualquier respuesta de la comunidad, así que estas son las tres categorías, bien separadas.
Obligatorio y publicado
- Al menos 12 testers que hayan aceptado participar.
- Que lleven participando los últimos 14 días de forma continua.
- Una prueba cerrada en concreto, no una interna.
- Respuestas honestas en la solicitud de acceso a producción.
Buena práctica, no una regla
- Testers que llegan de verdad al bucle principal y no se quedan en la pantalla de título.
- Sesiones lo bastante largas como para que aparezcan el calor y la presión de memoria.
- Comentarios por escrito que puedas citar cuando solicites el acceso.
- Correcciones publicadas durante la ventana, cuando los comentarios las justifican.
No es una regla publicada
- Abrir el juego una vez al día.
- Un mínimo de minutos por sesión.
- Un número obligatorio de compilaciones durante la prueba.
- Un mínimo de niveles, pantallas o mecánicas.
Google exige participación continua y dice que la interacción cuenta cuando revisa tu solicitud. Lo que no publica es una cuota de aperturas diarias, una cifra de minutos por sesión ni un número de actualizaciones. Trata la columna de la derecha por lo que es: consejos que se convirtieron en folclore de tanto repetirlos con seguridad. Apunta a probar de verdad y cumplirás la columna del medio sin necesitar la tercera.
Si un tester se da de baja, ¿vuelven a empezar las dos semanas?
Por sí solo no, y esta es la regla que más se exagera de todas las que circulan. La condición de Google se mide en el momento en que solicitas el acceso: al menos 12 testers, cada uno de ellos participando de forma continua los 14 días anteriores. No es un requisito de que un grupo intacto de exactamente doce personas sobreviva sin cambios a esas dos semanas.
Así que la aritmética va por tester, no por grupo. Si empiezas con 12 justos y pierdes uno el día nueve, te quedas corto: ahora tienes once cuentas que pueden enseñar la ventana completa, y la duodécima, la que entra en su lugar, tiene que completar sus propios 14 días continuos antes de que puedas solicitar el acceso. Si empiezas con quince y pierdes uno, los catorce que quedan pueden seguir cumpliendo cada uno la condición, así que no pierdes nada salvo margen. Ese es todo el argumento para reclutar por encima del mínimo en lugar de justo en el mínimo.
Cómo lo sabemos Esta lectura se deduce de la propia redacción de Google sobre la participación continua de cada tester, que es contra lo que está escrito el requisito. Google no publica ninguna regla aparte de reinicio del grupo que diga con todas las letras que la salida de un tester conserva el periodo de los demás, así que tómalo como una lectura cuidadosa de la condición publicada y no como una frase que le puedas citar a un revisor. El consejo práctico no cambia en ningún caso: recluta por encima de 12 para no tener que responder nunca a esa pregunta.
¿Qué pasa después del día 14?
Solicitas el acceso y Google lee las respuestas. La solicitud de acceso a producción pregunta cómo interactuaron los testers con el juego, qué comentarios dieron, qué cambiaste tú a raíz de ello y por qué lo consideras listo. En el caso de un juego hay además una petición propia de la categoría: describir qué lo hace destacar. Esa pregunta tampoco es un trámite: es donde un juego que funciona bien pero no tiene nada que decir de sí mismo empieza a parecer un juego que nadie probó en serio.
Escribe las respuestas durante la prueba, no después
Las preguntas van sobre cosas que ocurrieron a lo largo de catorce días. Si esperas al día quince para pensarlas, vas a reconstruirlas de memoria, y al leerlas se nota. Ve anotando sobre la marcha qué te reportaron los testers y qué publicaste en respuesta; así la solicitud te lleva veinte minutos y dice algo verdadero. Tienes un recorrido completo del cuestionario en el artículo sobre el cuestionario de acceso a producción.
¿Qué se le escapa a una prueba genérica de app cuando se trata de un juego?
Una prueba montada alrededor de «instálalo y deja aceptada la participación» mide el contador y nada más. Los juegos mantienen carga sostenida de CPU y GPU, entregan grandes paquetes de recursos a través de un sistema de distribución con sus propios modos de fallo, casi siempre llevan binarios nativos, guardan el estado de progresión entre sesiones y muchas veces cobran dinero. Cada una de esas cosas es un punto donde una versión pasa en tu escritorio y falla en el teléfono de un jugador.
Ninguno de estos riesgos es exclusivo de los juegos, y este artículo no dice lo contrario: muchas apps normales llevan bibliotecas nativas, venden suscripciones o entregan recursos grandes. Lo distintivo es la concentración. Un juego suele encontrarse con casi toda esta lista a la vez, en la misma versión y durante las mismas dos semanas, y por eso una lista de comprobación escrita para una app genérica deja sin probar gran parte de un juego.
Abajo tienes el mapa del resto de este artículo. La columna de la derecha es la parte que la gente confunde en las dos direcciones: algunas de estas cosas son requisitos de Google con consecuencias y otras son práctica de calidad normal que ninguna política menciona. Tratar una práctica como una regla te malgasta esas dos semanas, y tratar una regla como una práctica te cuesta la publicación.
| Área de riesgo | Por qué un juego es diferente | Estado |
|---|---|---|
| Entrega de recursos y tamaño | Cargas grandes repartidas entre paquetes install-time, fast-follow y on-demand, cada uno con sus propios límites y su propia forma de llegar tarde o de no llegar. | Límites de Google |
| Tiempo de fotograma y calor | La carga sostenida de renderizado calienta el dispositivo, el sistema limita el rendimiento y los tiempos de fotograma suben en el minuto seis de una sesión que en el minuto uno pintaba bien. | Métrica de vitals |
| Código nativo y 64 bits | Los motores y los plugins traen binarios compilados. Que falte la cobertura de 64 bits o que una ABI esté mal se lleva por delante familias enteras de dispositivos, no una sola función. | Requisito de Google |
| Compras dentro de la app | Estar en un canal de pruebas no hace que las compras sean gratis, y una compra de prueba sin confirmar desaparece a los tres minutos. | Mecanismo de Google |
| Play Games Services | Una segunda capa de autorización, con su propia lista de testers, que falla con errores de OAuth y 404 cuando no está configurada. | Requisito de Google |
| Política de monetización y de contenido | Mostrar las probabilidades de los objetos aleatorios, las mecánicas con dinero real y la exactitud del cuestionario de clasificación son una exposición a políticas con forma de juego que una app de utilidades normal no encuentra nunca. | Política de Google |
| Progresión y estado guardado | Salir, retomar, reinstalar y cambiar de dispositivo tienen que conservar el progreso, y un bug de guardado es invisible hasta que alguien juega lo bastante como para tener algo que perder. | Práctica de QA |
| Profundidad de la sesión | Los fallos que importan viven más allá del tutorial. Un tester que abre el juego una vez no aporta ninguna evidencia sobre ninguna de las filas de arriba. | Práctica de QA |
Fíjate en lo que no está en esa tabla: un número obligatorio de dispositivos, una duración obligatoria de la sesión, una tasa de fotogramas obligatoria o un número mínimo de niveles. Se afirman constantemente y ninguno de ellos está publicado. Lo que Google sí publica son límites, umbrales, mecanismos y políticas, y todos ellos se pueden probar durante las mismas dos semanas que ya estás dedicando al contador.
¿Cuánto puede pesar tu juego en Google Play?
A fecha de 12 de agosto de 2026, la Ayuda de Play Console indica 500 MB de módulo base, 500 MB por módulo de funciones, 1,5 GB por paquete de recursos, 4 GB para todos los módulos más los paquetes de recursos install-time, 30 GB para los paquetes fast-follow y on-demand, y un máximo total de 34 GB. Cada una de esas cifras es un tamaño de descarga comprimido calculado por Play Console, no el tamaño del .aab que tienes en el disco.
Este es el dato que más probablemente esté mal en lo que hayas leído antes de llegar aquí. La cifra de 200 MB que todavía circula era el límite base hace años, y algunas de las propias páginas antiguas de Google sobre juegos en Android no se han puesto al día con la página de la Ayuda de Play Console que rige las subidas reales. Cuando dos páginas de Google no coinciden, la página específica de límites de tamaño de la Ayuda de Play Console es la concreta y la actual para lo que la Console va a aceptar. Vuelve a comprobarla antes de planificar una publicación en torno a cualquiera de las cifras de abajo.
Instrumento 01
Medidor del presupuesto de tamaño
Introduce tus tamaños de descarga comprimidos en megabytes. Todo se ejecuta en esta página; no se sube nada. Esta calculadora usa 1 GB = 1024 MB.
Límites comprobados en la Ayuda de Play Console el 12 de agosto de 2026. Google los calcula a partir del tamaño de descarga comprimido que deriva de tu bundle, así que el tamaño del archivo en tu equipo es solo una aproximación de lo que se va a medir. Fuentes: los límites máximos de tamaño de app (respuesta 9859372) y Play Asset Delivery.
La tabla completa de límites
| Componente | Límite actual | A qué se aplica |
|---|---|---|
| Módulo base | 500 MB | El módulo base del bundle por sí solo. |
| Módulo de funciones | 500 MB | Cada módulo de funciones concreto, medido por separado. |
| Paquete de recursos | 1,5 GB | Cada paquete de recursos concreto, medido por separado. |
| Módulos más paquetes install-time | 4 GB | Total acumulado de todo lo que se entrega durante la instalación. |
| Paquetes fast-follow más on-demand | 30 GB | Total acumulado de todo lo que se entrega después de la instalación. |
| Descarga total | 34 GB | Tamaño máximo global de descarga comprimida. |
| Paquetes de recursos por bundle | 100 | Número máximo de paquetes de recursos en un app bundle. |
| Apps de más de 1 GB | minSdk 21 | Todo lo que supere 1 GB tiene que apuntar como mínimo a Android 5.0 Lollipop. |
| Aviso con datos móviles | 200 MB | Por encima de esto, las instalaciones con datos móviles muestran un aviso de tamaño grande que no bloquea. |
| APK heredado | 100 MB | Máximo para un único APK con la publicación heredada de APK. |
Límites de tamaño de Google Play comprobados el 12 de agosto de 2026. Todos los valores son tamaños de descarga comprimidos calculados por Play Console. Fuentes: los límites máximos de tamaño de app (respuesta 9859372) y Play Asset Delivery.
¿Qué modo de Play Asset Delivery debería probar tu juego?
Play Asset Delivery tiene tres modos, y cada uno falla en un sitio distinto. El modo que elegiste al compilar determina qué casos de prueba son los que importan, así que recorre esta tabla y prueba solo las filas que tu juego usa de verdad.
| Modo | Cuándo llega | ¿Listo al arrancar? | ¿En el tamaño que muestra la ficha? | El caso de prueba que encuentra bugs |
|---|---|---|---|---|
| Install-time | Se entrega durante la instalación en forma de APK divididos. | Sí | Sí | El primer arranque, la ruta de actualización y la instalación con el dispositivo casi sin almacenamiento. |
| Fast-follow | Se descarga automáticamente justo después de la instalación, sin bloquear la entrada al juego. | No necesariamente | No | Un jugador que abre el juego antes de que el paquete termine, y la recuperación de una descarga interrumpida. |
| On-demand | Se descarga con el juego en marcha, cuando tu código lo pide. | Solo cuando se pide | No | Entrar al nivel o a la función antes de que su paquete esté disponible, más los reintentos y las interrupciones. |
No des por hecho que los paquetes siguen donde los dejaste
Google advierte de que los archivos de los paquetes fast-follow y on-demand los puede borrar el usuario o los puede mover la biblioteca de Play Asset Delivery entre sesiones, así que un juego no debe dar por hecho que un paquete que existía ayer sigue hoy en la misma ubicación. Prueba el segundo y el tercer arranque, no solo el primero, y prueba qué pasa cuando una actualización invalida un paquete. La segmentación por formato de compresión de texturas añade otra dimensión: Play puede entregar recursos de textura distintos según lo que admita el dispositivo, así que los recursos que recibe tu dispositivo de prueba pueden no ser los que recibe otro dispositivo.
Las pruebas locales de entrega de recursos no reproducen exactamente la entrega de Play. Google documenta que, en una prueba local, un paquete fast-follow se comporta como uno on-demand, y que ciertos comportamientos de red y de espera a la Wi-Fi no se pueden reproducir en local en absoluto. Ese es el argumento para probar la versión que Play entrega de verdad a un tester del canal cerrado en lugar de la que produce tu editor, y es uno de los pocos puntos en los que la prueba cerrada hace trabajo real de control de calidad en vez de limitarse a alimentar un contador.
¿Qué cifras de tasa de fotogramas y de fallos publica Google en realidad?
Android vitals publica un umbral de tasa de fallos percibidos por el usuario del 1,09% a nivel global y del 8% por modelo de teléfono, y una tasa de ANR percibidos por el usuario del 0,47% a nivel global y del 8% por modelo de teléfono. Para los juegos en concreto define una sesión lenta como aquella en la que más del 25% de los fotogramas son lentos, medidos frente a 50 ms (20 FPS) como métrica principal y 34 ms (unos 30 FPS) como métrica secundaria. Ninguna de esas cifras es un umbral publicado de aprobación de la prueba cerrada.
La distinción importa porque se pierde una y otra vez. Los umbrales de vitals describen la calidad técnica, y Google ha dicho que con el tiempo Play alejará a los usuarios de los juegos que no consigan alcanzar 20 FPS en su teléfono. Eso es un mecanismo de visibilidad y de calidad. No es la revisión del acceso a producción, y ninguna fuente de Google convierte una tasa de fotogramas en una nota de aprobado para la prueba de 14 días. Las dos cosas pueden ser ciertas a la vez: tu juego puede superar el requisito de testers y aun así ser un juego que Play dejará de recomendar sin decir nada.
Instrumento 02
Laboratorio de sesiones lentas
Cuarenta fotogramas de una sesión de juego. Mueve el control deslizante para indicar cuántos se renderizaron lentamente y el laboratorio aplica la definición de Google al resultado.
Android vitals empieza a medir la tasa de fotogramas de un juego solo después de que el juego lleve 1 minuto en marcha, y por eso mismo un tester que abre el juego y lo cierra no genera ninguna señal de rendimiento útil. Un minuto es un punto de inicio de la medición, no una duración obligatoria de la sesión de juego de una persona. Fuente: Sesiones lentas en Android vitals.
Las cifras, y lo que cada una no es
| Métrica | Valor de Google | Qué significa | Qué no significa |
|---|---|---|---|
| Tasa de fallos percibidos por el usuario | 1.09% | Umbral de calidad técnica de Android vitals, medido a nivel global. | No es un umbral de la prueba cerrada de ningún tipo. |
| Tasa de fallos por modelo de teléfono | 8% | El umbral de vitals específico por dispositivo. | No es permiso para tolerar un 8% de fallos en tu propio control de calidad. |
| Tasa de ANR percibidos por el usuario | 0.47% | Umbral de calidad técnica de Android vitals, medido a nivel global. | No forma parte de la fórmula del acceso a producción. |
| Tasa de ANR por modelo de teléfono | 8% | El umbral de vitals específico por dispositivo. | No es un objetivo al que apuntar en el diseño. |
| Sesión lenta | >25% de fotogramas lentos | La definición de calidad de fotogramas, solo para juegos. | No mide la participación de los testers. |
| Fotograma lento, principal | 50 ms, 20 FPS | El tiempo de referencia principal de las sesiones lentas. | No es un mínimo de FPS publicado para el acceso a producción. |
| Fotograma lento, secundario | 34 ms, unos 30 FPS | Una métrica adicional de sesiones lentas que reporta vitals. | No es prueba de que Google exija que todos los juegos funcionen a 30 FPS. |
| Inicio de la medición | Tras 1 minuto | La medición de la tasa de fotogramas empieza cuando el juego lleva un minuto en marcha. | No es la duración que Google exige para una sesión de juego de una persona. |
El bug que solo aparece en el minuto seis
Google incluye el sobrecalentamiento y la limitación térmica entre las causas documentadas de los fotogramas lentos: la carga sostenida de CPU y GPU calienta el dispositivo, el sistema limita el rendimiento y los tiempos de fotograma suben. Ese modo de fallo es invisible en una prueba rápida de dos minutos y evidente en una sesión de veinte minutos con el teléfono caliente. Es también el ejemplo más claro de por qué un juego necesita testers que jueguen de verdad y no testers que solo instalan. Si vas a perfilar esto, el Android Dynamic Performance Framework (ADPF) expone señales de gestión térmica, de CPU y de GPU justo para eso, de modo que el juego pueda adaptarse antes de que la limitación se vuelva severa.
Bibliotecas nativas y 64 bits
Los juegos hechos con Unity, Unreal, Cocos o cualquier motor con plugins nativos llevan binarios compilados, y esos binarios tienen sus propias reglas de compatibilidad, independientes de todo lo que dice este artículo. Google Play exige que las apps admitan arquitecturas de 64 bits: cuando se admite una arquitectura nativa de 32 bits, hay que incluir también la arquitectura de 64 bits correspondiente. Prueba en un entorno de 64 bits y da por hecho que cualquier plugin de terceros puede traer su propio binario incompatible, diga lo que diga la versión de tu motor.
Si durante este trabajo tu versión también activa el aviso del tamaño de página de memoria de 16 KB, ese es un requisito aparte, con su propio plazo y su propia vía de reparación, que se explica en el artículo sobre cómo arreglar el error de tamaño de página de 16 KB.
No es una regla publicada No existe ningún número publicado por Google de dispositivos, versiones de Android o familias de GPU en los que haya que probar un juego para obtener el acceso a producción. Quien cite «cinco teléfonos y tres versiones de Android» está citando una preferencia, no una política. Cubre el rango que tu juego admite de verdad, ponderado según el hardware que probablemente tenga tu público, y recuerda que los emuladores no te dicen nada útil sobre el comportamiento térmico.
¿Cómo pruebas las compras integradas sin cobrarles a los testers?
Añade en Settings > License testing de Play Console todas las cuentas que vayan a hacer una compra de prueba. Estar en tu canal cerrado no hace que las compras sean gratis. A un tester normal que pulse el botón de compra en tu juego sin publicar se le puede cobrar dinero real, y lo único que cambia eso es que la cuenta que hace la compra tenga estado de tester de licencia.
“Los usuarios asumen cargos reales ... salvo que el usuario sea un tester de licencia.”
Google Play Billing, documentación sobre cómo probar la facturación integrada
Son dos listas distintas que controlan dos cosas distintas. La lista de testers del canal cerrado controla quién puede instalar la compilación sin publicar. La lista de testers de licencia controla a quién se le procesan las compras con los métodos de pago de prueba de Google en lugar de con una tarjeta real. Quien añade a doce personas a la primera lista y a ninguna a la segunda ha montado una prueba en la que todas las compras son reales, y el primero en enterarse suele ser un tester pidiendo que le devuelvan el dinero.
Instrumento 03
Comprobador de cobros a testers
Responde pensando en el dispositivo y en la cuenta concretos que van a hacer la compra. El veredicto cambia con cada cuenta, no con cada compilación.
Tester del canal cerrado frente a tester de licencia
| Situación | ¿En el canal cerrado? | ¿Tester de licencia? | Qué pasa cuando compra |
|---|---|---|---|
| Un tester invitado normal | Sí | No | Puede instalar la compilación sin publicar, y las compras pueden ser transacciones con cargo real. |
| Un tester de licencia que además está en el canal | Sí | Sí | Instala la compilación cerrada y recibe los métodos de pago de prueba de Google. |
| Un tester de licencia con una compilación local del mismo paquete | No necesariamente | Sí | Google permite que los testers de licencia prueben la facturación sin el requisito habitual de compilación subida y firmada, siempre que se cumplan las condiciones de paquete y de cuenta. |
| Un dispositivo con varias cuentas de Google | Cualquiera | Depende de la cuenta | La compra usa normalmente la cuenta que descargó la app; si no la descargó ninguna, Google usa la primera cuenta. |
| Una compra de prueba que nunca se confirma | Cualquiera | Sí | Se reembolsa automáticamente a los 3 minutos en el entorno de prueba acelerado. |
Las pruebas de compra que debería hacer un juego monetizado
| Prueba | Mecanismo | Comportamiento esperado |
|---|---|---|
| Compra de consumible con éxito | El instrumento de prueba que siempre aprueba. | El objeto se concede y después se confirma o se consume correctamente. |
| Compra rechazada | El instrumento de prueba que siempre rechaza. | No se concede ningún objeto y no queda ningún estado a medias. |
| Consumible repetido | Volver a comprar el mismo consumible. | La segunda y la tercera compra funcionan exactamente igual que la primera. |
| No consumible | Una compra de prueba con éxito. | Se concede una vez y se impide una recompra no deseada. |
| Pendiente que después sale bien | El método de prueba que aprueba con retraso. | No se concede nada hasta que el estado pasa a comprado, y entonces se concede una sola vez. |
| Pendiente que falla | El método de prueba que rechaza con retraso. | El derecho no se concede en ningún momento. |
| Reinicio a mitad de compra | Cerrar y volver a abrir el juego durante un estado pendiente. | El estado del derecho se reconcilia correctamente al volver a abrir. |
| Confirmación | Una compra con éxito que se deja sin tocar. | Aguanta más de 3 minutos en lugar de reembolsarse sola. |
| Cuenta equivocada | Un dispositivo con varias cuentas de Google con la sesión iniciada. | La cuenta de facturación es el tester de licencia que querías. |
Antes de que nada de esto funcione
La prueba con licencia está en Settings > License testing de Play Console, y la lista de correos de ahí admite hasta 2.000 direcciones, mientras que un grupo de Google se puede usar sin ese límite de lista de usuarios. Tus productos de pago único y tus suscripciones también tienen que estar configurados y publicados como corresponda antes de poder probarlos bien: un producto sin publicar provoca fallos que parecen errores de facturación y en realidad son huecos de configuración.
Calendario de la biblioteca de facturación: Play Billing Library 7 pasó su fecha límite para apps nuevas y actualizaciones el 31 de agosto de 2026. Si tienes una prórroga, llega hasta el 1 de noviembre de 2026; si no, las versiones nuevas necesitan una versión posterior compatible. Ser la versión más nueva no es lo mismo que ser la versión mínima permitida, así que apunta a una versión compatible y con mantenimiento en lugar de dar por hecho que la última es obligatoria. Fuente: Probar la facturación integrada, incluidos los testers de licencia.
¿Las cajas de botín convierten tu juego en una app de juegos de azar?
No. Google separa los objetos virtuales aleatorios comprados de los juegos de azar con dinero real. Si los jugadores gastan dinero o valor comprado en objetos virtuales aleatorios como las cajas de botín, tienes que indicar con claridad las probabilidades antes de la compra y junto a ella. Pagar por la posibilidad de ganar un premio del mundo real es un régimen de políticas distinto, con sus propias reglas de elegibilidad y de licencias.
| Tu mecánica | A qué política afecta | Qué tienes que hacer |
|---|---|---|
| El jugador compra un objeto virtual conocido y fijo | Reglas normales de compra digital. | Prueba la compra como es debido y sigue las reglas de facturación de Play que correspondan. Nada especial. |
| El jugador gasta dinero o valor en un objeto virtual aleatorio | La política de elementos aleatorios, que menciona expresamente las cajas de botín. | Muestra las probabilidades antes de la compra y junto a ella, donde el jugador pueda verlas de verdad. |
| El juego representa juegos de azar simulados | Clasificación de contenido. | Responde el cuestionario de clasificación con exactitud. La clasificación resultante depende de la autoridad y del cuestionario que correspondan. |
| El jugador paga por la posibilidad de ganar un premio del mundo real | La política aparte de juegos de azar, juegos y concursos con dinero real. | Trátalo como una categoría restringida, no como una monetización normal con cajas de botín. |
| Producto de juegos de azar con dinero real y con licencia | Reglas especializadas de elegibilidad, de países y de licencias. | Queda fuera del alcance de los consejos habituales para un juego indie. Trabaja directamente con la política específica de juegos de azar de Google. |
El cuestionario de clasificación de contenido no es un trámite
Todo juego necesita respuestas exactas y completas en el cuestionario de clasificación de contenido, al que se llega desde Policy > App content en Play Console, y hay que actualizarlo cuando cambian el contenido o las funciones que describe. Tergiversar lo que hay en un juego puede acabar en retirada o suspensión, lo que convierte un cuestionario inexacto en un error bastante más caro que un fotograma lento.
Los juegos tocan más partes del cuestionario que las apps: violencia, juegos de azar simulados, compras dentro del juego, comunicación entre usuarios, contenido generado por los usuarios. Si tu prueba cerrada añade un chat o una recompensa aleatoria en la segunda semana, las respuestas que diste en la primera ya son incorrectas. Vuelve a abrir el cuestionario antes de solicitar el acceso a producción, no después de que alguien se dé cuenta.
La política de funcionalidad y calidad básicas está por debajo de todo esto: las apps y los juegos tienen que ofrecer experiencias estables, con buena respuesta y suficientemente funcionales, y algo que falla, no carga o es prácticamente no funcional puede incumplirla. No es una regla publicada No hay un número mínimo publicado de niveles, de pantallas, de mecánicas ni de minutos de juego. Un juego corto no es un problema de políticas; uno roto sí.
Fuente: la política de objetos virtuales aleatorios de Google Play (respuesta 9858738), que exige mostrar las probabilidades antes de la compra y junto a ella.
¿Por qué falla el inicio de sesión de Play Games durante la prueba cerrada?
Porque Play Games Services tiene su propia lista de testers. Mientras tu configuración de Play Games Services no esté publicada, los testers tienen que estar autorizados uno a uno o a través de un canal de publicación habilitado; si no, Google dice que se encontrarán con errores de OAuth y 404. Estar en el canal cerrado le da al tester la versión. No le da la capa de Play Games.
El síntoma es característico y engañoso: el inicio de sesión funciona en tu máquina, te funciona a ti en un dispositivo y luego falla para todos los demás en cuanto la versión se descarga desde Play. Eso parece una versión rota, lo que lleva a los desarrolladores a reconstruir algo que nunca estuvo mal.
La configuración que lo soluciona
-
01
Abre la lista de testers de Play Games Services
En Play Console: Grow users > Play Games Services > Setup and management > Testers. Esta lista es independiente de la lista de testers de tu canal cerrado y no hereda nada de ella.
-
02
Autoriza a los testers o habilita el canal
Añade las cuentas una a una, o habilita el canal de publicación de Play Console que corresponda para las pruebas de Play Games Services, de modo que todo el que tenga acceso a la versión de prueba obtenga también acceso a Play Games. La segunda opción es la que escala más allá de un puñado de personas.
-
03
Comprueba que las credenciales coinciden con la versión
La autenticación falla cuando el nombre de paquete o la huella del certificado de firma configurados no coinciden con lo que se subió. Con Play App Signing de por medio, la huella que necesita tu configuración de Play Games es la que usa Play, no la de tu equipo de trabajo.
-
04
Prueba todas las funciones que hayas activado de verdad
Primero el inicio de sesión y después los logros, las clasificaciones y las partidas guardadas, según lo que use tu juego. Las partidas guardadas merecen atención especial porque interactúan con la progresión: una partida guardada que no se restaura es un bug que tus testers solo encontrarán si llegan lo bastante lejos como para tener progreso que valga la pena restaurar.
| Sistema | Qué controla | ¿Sustituye a la prueba cerrada de 12/14? | Dónde se configura |
|---|---|---|---|
| Prueba cerrada | Quién puede recibir el juego no publicado y, en las cuentas personales a las que les aplica, el propio requisito previo del acceso a producción. | Este es el requisito obligatorio. | Canal de prueba cerrada de Play Console. |
| Pruebas de Play Games Services | Acceso a una configuración de Play Games Services no publicada y a sus APIs. | No | Grow users > Play Games Services > Setup and management > Testers. |
| Prueba interna | Distribución temprana y rápida a un máximo de 100 testers. | No | Un canal de pruebas opcional aparte. |
| Registro previo | Una campaña de la tienda para dar a conocer el lanzamiento. | No | Desactivado de inicio para los desarrolladores sujetos al requisito previo de pruebas. |
Cuatro sistemas, cuatro listas, un juego. Esta sección existe porque tres de esos cuatro son invisibles desde la pantalla del canal cerrado, así que un desarrollador que ha configurado bien el único que ve da por supuesto, con toda lógica, que los demás vienen incluidos. No es así.
Fuente: Configuración de Play Games Services en la consola y autorización de testers, que documenta la lista de testers, la alternativa del canal habilitado y los errores de OAuth y 404 que ve un tester sin autorizar.
¿Puedes usar el registro previo mientras tu juego está en prueba cerrada?
Al principio no. Para los desarrolladores sujetos al requisito de pruebas de las cuentas personales nuevas, el registro previo está entre las funciones desactivadas hasta que se cumple el requisito. Una vez disponible, una campaña de registro previo puede durar hasta 90 días, y un desarrollador puede tener como máximo 2 apps o juegos en registro previo al mismo tiempo.
Esto duele más en los juegos que en las apps, porque el registro previo es una herramienta de lanzamiento y el lanzamiento de un juego casi siempre se planifica hacia atrás desde una fecha. Si tu plan daba por hecha una campaña de registro previo en paralelo a la prueba cerrada, ese plan hay que reordenarlo: primero cumple el requisito previo, después lanza la campaña y después publica.
| Etapa | Prueba cerrada | Registro previo |
|---|---|---|
| Antes de cumplir el requisito | En marcha: esta es la ventana que califica. | Desactivado para las cuentas afectadas. |
| Después de conceder el acceso a producción | Opcional, y sigue siendo útil para las futuras actualizaciones. | Disponible, hasta 90 días por campaña. |
| Llevar varios títulos | Cada app nueva tiene que cumplir el requisito con su propio nombre de paquete. | Un máximo de 2 títulos en registro previo a la vez. |
| Prueba abierta | El canal que nombra el requisito previo es el cerrado. | La prueba abierta queda disponible en cuanto tienes el acceso a producción. |
La secuencia práctica para un primer juego: pon en marcha la prueba cerrada en cuanto la versión se pueda jugar, en lugar de esperar a que parezca terminada, porque esas dos semanas corren en paralelo con el trabajo que ya estás haciendo de todos modos. El marketing que depende de funciones de la tienda va después, no durante.
Fuente: el requisito de prueba cerrada para las cuentas personales nuevas (respuesta 14151465), que es donde Google indica que el acceso a producción y el registro previo siguen restringidos hasta que se cumple el requisito.
¿Qué deberían hacer de verdad tus testers con el juego?
Recorre las rutas por donde un juego se rompe de forma distinta a una app: la instalación entregada por Play, el tutorial, el bucle principal, el progreso guardado entre reinicios, una sesión lo bastante larga como para calentar el dispositivo, el paso a segundo plano y la vuelta, las descargas de recursos, las compras y el inicio de sesión de Play Games. Google no publica ni un número de dispositivos obligatorio ni una duración de sesión, así que cubre el rango que tu juego admite de verdad y dedica la profundidad allí donde tu juego se sale de lo común.
| Área de prueba | Qué cubrir | Por qué merece el tiempo | Estado |
|---|---|---|---|
| Instalación y primer arranque | Una instalación limpia desde Play, los permisos y la primera entrega de recursos. | Un juego que se instala en local puede fallar igualmente por el comportamiento de los splits y de los recursos que entrega Play. | Práctica de QA |
| Tutorial e introducción | Todos los pasos, más la navegación hacia atrás y las rutas que la gente toma sin querer. | El acceso a producción pregunta cómo interactuaron los testers, y los primeros minutos son lo que va a ver la mayoría. | Práctica de QA |
| Bucle de juego principal | Jugar lo suficiente como para ejercitar los controles, una victoria, una derrota, un reinicio y una progresión normal. | Esta es la diferencia entre una prueba con sentido y una instalación pasiva. | Práctica de QA |
| Progresión y partidas guardadas | Salir, retomar, reiniciar la app, reiniciar el dispositivo y volver a cargar el progreso. | Perder la partida guardada es el fallo que más castigan los jugadores, y hace falta alguien que tenga progreso que perder. | Práctica de QA |
| Rendimiento sostenido | Jugar bastante más allá del primer minuto y vigilar la degradación de los fotogramas y los tirones. | Android vitals empieza a medir la tasa de fotogramas después de un minuto, y el calor llega más tarde todavía. | Métrica de vitals |
| Variedad de dispositivos | Dispositivos reales que cubran el rango que admite tu juego, con más peso en los que tienen tus jugadores. | La cobertura debería ir por riesgo; no hay publicado ningún número fijo de dispositivos ni de GPU. | Práctica de QA |
| Rutas gráficas | Las rutas de renderizado y las variantes de texturas que lleva de verdad tu compilación. | La segmentación por compresión de texturas hace que dispositivos distintos puedan recibir recursos distintos. | Práctica de QA |
| Memoria y estabilidad | Transiciones de nivel, reinicios repetidos, escenas pesadas y sesiones largas. | Los fallos y los ANR son métricas de calidad que Play mide y que tienen umbrales publicados. | Métrica de vitals |
| Segundo plano y reanudación | El botón de inicio, una notificación que interrumpe, apagar y encender la pantalla y, cuando sea viable, la recreación del proceso. | Los juegos pierden el estado y el contexto de renderizado en los cambios de ciclo de vida más a menudo que las apps. | Práctica de QA |
| Entrega de recursos | El modo que use tu juego entre install-time, fast-follow y on-demand, incluidas las descargas interrumpidas. | Los modos se comportan de forma distinta y probar en local no reproduce la entrega de Play. | Límites de Google |
| 64 bits | La compilación funcionando en un entorno de 64 bits, sobre todo si hay plugins nativos. | Google Play exige compatibilidad con 64 bits en las apps publicadas. | Requisito de Google |
| Compras integradas | Aprobada, rechazada, pendiente, consumible repetido, derecho concedido y confirmación. | Google ofrece métodos de pago de prueba para los testers de licencia justo para estos casos. | Mecanismo de Google |
| Play Games Services | El inicio de sesión y todos los logros, clasificaciones y funciones de partida guardada que hayas activado. | Las configuraciones sin publicar necesitan una autorización de testers aparte y credenciales que coincidan. | Requisito de Google |
| Declaraciones de contenido | El cuestionario de clasificación, el público objetivo y cualquier comportamiento de probabilidades de los objetos aleatorios. | Una clasificación inexacta o una divulgación que falta son un riesgo de política, al margen de las pruebas. | Política de Google |
Dales a los testers un recorrido, no la instrucción de “prueba esto”
La forma más rápida de convertir doce instalaciones en doce informes útiles es darle a la gente un recorrido corto y numerado por el juego, con una cosa que mirar en cada parada y una pregunta que de verdad quieras que te respondan. Los testers a los que les dices que exploren no reportan nada; los testers a los que les dices “llega al nivel tres, cierra el juego, vuelve a abrirlo y dime si tu progreso sigue ahí” reportan el fallo de guardado el día dos y no el día trece. Los emuladores no ayudan con las filas de arriba que dependen del calor, de GPU reales o de condiciones de red reales, y los riesgos de apoyarse en ellos están en el artículo sobre los emuladores en la prueba cerrada.
¿Por qué Google pide otros 14 días después de llegar a los 12?
Porque el acceso a producción revisa la calidad de la prueba, y no solo el contador. Google pregunta qué hicieron los testers, qué comentarios dieron y qué cambiaste tú, y señala a los testers que no interactuaron con tu app como un motivo por el que puede exigir más pruebas. Llegar a 12 y a 14 es el suelo de elegibilidad, no una aprobación.
Hay desarrolladores que cuentan este desenlace con regularidad: los números estaban, la solicitud se envió y la respuesta fue más pruebas. Reportado por la comunidad Los hilos coinciden en la experiencia y son mucho menos fiables sobre la causa, porque nadie fuera de Google ve el razonamiento. Lo que sí se puede afirmar a partir de la documentación de Google es que la interacción y los comentarios forman parte de lo que se evalúa, y con eso ya se puede trabajar.
| Síntoma | Lo primero que hay que comprobar | La solución real |
|---|---|---|
| Play dice que no hay suficientes testers que cumplan | Alguien no llegó a completar la aceptación, alguien se fue o la ventana continua todavía no ha terminado. | Confirma que al menos 12 cuentas válidas han seguido participando de forma continua durante toda la ventana exigida. |
| 12 testers y 14 días cumplidos, y acceso denegado | Google consideró que hacían falta más pruebas, y eso puede incluir poca interacción o un trabajo de comentarios flojo. | Lee la respuesta, sigue probando de forma significativa, recoge comentarios reales, corrige lo que señalen y responde con exactitud a la solicitud. |
| El juego funciona en local y los recursos fallan desde Play | El modo de entrega de recursos, el comportamiento de las actualizaciones o la presión de almacenamiento son distintos de los de tu entorno local. | Prueba la compilación entregada por Play y gestiona la disponibilidad de los paquetes y los estados de actualización en lugar de dar por hecho que vale lo que pasa en local. |
| El juego da tirones tras un rato largo de juego | Un cuello de botella de CPU o GPU, ajuste térmico, ritmo de fotogramas o un desajuste con la frecuencia de actualización. | Analiza sesiones largas y el estado térmico, y no sesiones cortas, con las herramientas de rendimiento de juegos de Android. |
| El diálogo de compra muestra una tarjeta real | La cuenta no está actuando como tester de licencia, o quien compra es otra cuenta del dispositivo. | Añade la cuenta que quieres en Settings > License testing y confirma qué cuenta descargó la compilación. |
| La compra de prueba se reembolsa a los pocos minutos | La compra nunca se confirmó. | Arregla la lógica de confirmación o de consumo. Las compras de los testers de licencia se reembolsan solas a los 3 minutos si no se confirman. |
| El inicio de sesión de Play Games devuelve un error de OAuth o un 404 | El tester no está autorizado en la configuración de Play Games sin publicar. | Añade a ese tester concreto en Play Games o habilita el canal de publicación para las pruebas de Play Games. |
| Play Games funcionaba y dejó de funcionar tras subir la versión | Un desajuste de nombre de paquete o de certificado de firma entre la configuración y la compilación subida. | Verifica la huella de Play App Signing, el nombre de paquete y la credencial vinculada. |
| El juego nativo no aparece en algunos dispositivos | Un hueco de compatibilidad de ABI o de 64 bits. | Confirma que existe una biblioteca de 64 bits para cada arquitectura nativa compatible y prueba en un entorno de 64 bits. |
| Marcado por funcionalidad rota o trivial | El juego se cierra, no carga o no ofrece una funcionalidad que funcione. | Arregla los problemas funcionales. No te pongas a buscar un número mínimo de niveles inventado que cumplir. |
| Compra de objetos aleatorios cuestionada | Las probabilidades de los objetos aleatorios de pago no se muestran donde las ven los jugadores. | Muestra las probabilidades antes de la compra y cerca de ella. |
Qué aspecto debería tener un segundo ciclo
Si te piden más pruebas, la tentación es repetir la primera vuelta con el mismo patrón de instalaciones pasivas y esperar otra respuesta. Un segundo ciclo más útil cambia algo de verdad: mantén el grupo estable, dales a los testers un recorrido real por el juego, recoge por escrito lo que reporten, publica las correcciones que esos comentarios justifiquen y cuenta todo eso con claridad cuando vuelvas a solicitar el acceso. Y eso, no por casualidad, es también lo que produce un juego mejor.
Lo que no debería incluir es un ritual inventado. No hay ningún número publicado de aperturas, ningún número obligatorio de actualizaciones ni ninguna cuota de juego diario que convierta una negativa en una aprobación, y nadie te puede prometer que un patrón concreto de actividad vaya a cambiar la decisión de Google. Más sobre los patrones de rechazo en general en el artículo sobre por qué se rechaza la prueba cerrada.
Fechas límite clave de Google Play para quien publica juegos en 2026 y principios de 2027
El 31 de agosto de 2026 ya pasó: los juegos móviles nuevos y actualizados tienen que apuntar a Android 16 (nivel de API 36) o posterior, y Play Billing Library 7 ya ha superado su fecha límite para apps nuevas y actualizaciones. Si tienes una prórroga, llega hasta el 1 de noviembre de 2026, dentro de 57 días.
A su alrededor hay otras tres: el 30 de septiembre de 2026 para el registro del nombre de paquete en Play y para la primera fase de aplicación de la verificación de desarrolladores, y el 1 de febrero de 2027 para los tamaños de página de memoria de 16 KB, que es la que tiene más papeletas de pillar a un juego hecho con un motor. Ninguna de ellas forma parte del requisito de testers, y todas pueden bloquear la publicación que ese requisito debería desbloquear.
| Fecha | Requisito | Qué significa para un juego |
|---|---|---|
| 31 de agosto de 2026 | Nivel de API objetivo | Los juegos móviles nuevos y actualizados tienen que apuntar a Android 16, nivel de API 36 o posterior. Otros formatos de dispositivo van por otro camino: Wear OS y Android Automotive OS necesitan el nivel de API 35, y Android TV y Android XR, el 34. El desglose completo está en el artículo sobre el nivel de API objetivo. |
| 31 de agosto de 2026 | Play Billing Library | Play Billing Library 7 llega a su fecha límite para apps nuevas y actualizaciones. Los juegos monetizados necesitan una versión posterior compatible para las versiones nuevas, salvo que les aplique una prórroga. |
| 30 de septiembre de 2026 | Registro del nombre de paquete en Play | Cualquier app o juego de Play cuyo nombre de paquete siga sin registrar en esa fecha se arriesga a que lo retiren de Play. Se aplica en todo el mundo y no tiene nada que ver con la antigüedad de tu cuenta. |
| 30 de septiembre de 2026 | Verificación de desarrolladores, primera fase | Primera aplicación de la verificación de desarrolladores de Android, para las instalaciones a través de las tiendas participantes en Brasil, Indonesia, Singapur y Tailandia. No es un apagón mundial. El detalle está en el artículo sobre la verificación de desarrolladores. |
| 1 de noviembre de 2026 | Fin de la prórroga | La última fecha que cubre la prórroga disponible, tanto para el requisito de nivel objetivo como para Play Billing Library 7. Las prórrogas se solicitan desde el aviso correspondiente de Play Console, no se conceden solas. |
| 1 de febrero de 2027 | Tamaños de página de memoria de 16 KB | Las actualizaciones afectadas que apunten al nivel de API 35 o posterior y lleven código nativo no se pueden publicar sin compatibilidad con los tamaños de página de 16 KB. Los binarios del motor y de los plugins son justo donde esto muerde. La ruta de reparación está en el artículo sobre el error de 16 KB. |
| 27 de enero de 2027 | Permisos de contactos | Solo afecta a las apps que apuntan a Android 17, nivel de API 37 o posterior, y que usan el acceso amplio a contactos afectado, algo que la mayoría de los juegos no pide nunca. El cronograma de políticas de Google y la tabla de fechas límite de la Ayuda de Play Console dan ya las dos esta fecha. |
Estas fechas se mueven sin anuncios
Vuelve a comprobarlo antes de planificar Google publica las fechas límite de las políticas en dos sitios que se van separando y que después se reconcilian en silencio. Las fechas límite de contactos y de ubicación de aquí arriba decían 28 de octubre de 2026 en el cronograma de Android Developers hasta mediados de agosto de 2026, cuando esa página se editó para poner 27 de enero de 2027 y cuadrar con la Ayuda de Play Console, sin ninguna entrada en el registro de cambios. Los boletines antiguos de Google siguen citando la fecha retirada. Contrasta la tabla de fechas límite de la Ayuda de Play Console con el cronograma de políticas antes de montar un plan de publicación sobre cualquier fila de aquí, y no te fíes ni de un boletín ni de un artículo por encima de las páginas vivas. Hoy sigue habiendo una fila que no cuadra: Child Safety Standards es el 26 de agosto de 2026 en la tabla de la Ayuda y el 28 de octubre de 2026 en el cronograma. Planifica para el 26 de agosto.
Fuentes: los requisitos de nivel de API objetivo (respuesta 11926878) para las fechas del 31 de agosto y los niveles por formato de dispositivo, y para el resto las dos páginas de política de Google: la tabla de fechas límite de la Ayuda de Play Console y el cronograma de políticas de Android Developers.
Conviene decirlo claro, porque el orden pilla a mucha gente: ninguna de estas fechas tiene nada que ver con el requisito de testers, y cumplir el requisito de testers no te libra de ninguna de ellas. Un juego puede terminar una prueba cerrada de 14 días impecable y seguir sin poder publicarse porque la compilación apunta al nivel de API equivocado. Comprueba los requisitos que bloquean la publicación antes de empezar las dos semanas, no después.
¿Dónde encuentras 12 testers reales para un juego?
Reclutarlos es la parte que más subestima quien desarrolla en solitario. El requisito de prueba que Google publica no dice cómo hay que reclutar a los testers, así que pagar por QA no descalifica automáticamente, pero léelo como la ausencia de una prohibición y no como que Google respalde los servicios de testers como categoría, porque Google no ha publicado ningún respaldo así. Lo que las políticas de Google sí prohíben es manipular las valoraciones, las reseñas, la posición o el número de instalaciones por medios ilegítimos: bots, cuentas falsas, instalaciones fraudulentas, interacción manipulada. El listón son personas reales que prueban de verdad y dan comentarios honestos, sea como sea que las hayas encontrado.
Si las comunidades de motores están llenas de mensajes de “necesito 12 testers” es por pura aritmética: quien hace su primer juego no suele conocer a doce personas que tengan un teléfono Android, que completen la aceptación de participar y que sigan participando dos semanas después. Los amigos lo instalan, juegan una vez por cortesía y se van desenganchando. Nada de eso es un defecto de carácter. Es que un favor tiene una vida media de unos tres días y el requisito dura catorce.
Los grupos de intercambio de testers resuelven la cifra y muchas veces poco más, porque quien intercambia contigo tiene el mismo incentivo que tú: aceptar participar, quedarse y pasar a otra cosa. Eso cumple el contador y produce justo el patrón de interacción pasiva por el que Google pregunta en el formulario de solicitud. En un juego es peor que en una app, porque los fallos que importan están varias sesiones más adentro y un tester recíproco no va a llegar nunca hasta ahí.
Qué cubre una prueba gestionada
PrimeTestLab aporta 12 testers reales en dispositivos reales, de Android 7 a 17, que aceptan participar y se mantienen los 14 días completos, y la prueba arranca en 4-6 horas. Lo hemos hecho con 7,400+ apps en 120+ países con una tasa de éxito del 99.9%, y la prueba va respaldada por una repetición gratis o un reembolso completo. Los planes empiezan en $19.99.
Vamos a ser claros con el límite, porque un juego tiene partes que no se pueden delegar: una prueba gestionada se encarga del lado de los testers durante esas dos semanas. No reconstruye tus paquetes de recursos, no ajusta tus tiempos de fotograma, no implementa la confirmación en tu código de facturación ni responde a tu cuestionario de clasificación. Eso es cosa tuya, y las secciones de arriba están para que te lleve menos tiempo. Lo que desaparece es la carrera por reclutar y el riesgo de que el grupo se desmorone el día nueve.
Reclutar por tu cuenta frente a una prueba gestionada
| El requisito de Google | Reclutar por tu cuenta | Una prueba gestionada |
|---|---|---|
| Al menos 12 testers que hayan aceptado participar | Encontrar, informar y perseguir a personas reales, y después esperar que todas completen la aceptación. | 12 aportados y mantenidos durante toda la ventana. |
| 14 días de forma continua | Una baja solo te cuesta la prueba si te deja con menos de 12 testers que puedan enseñar cada uno 14 días continuos cuando solicites el acceso. | El grupo se supervisa para que la ventana siga intacta. |
| Dispositivos reales, personas reales | Los emuladores y las cuentas inactivas son el atajo de siempre, y el motivo de siempre de que una prueba no produzca nada que contar. | Dispositivos reales, de Android 7 a 17. |
| Interacción que se le puede contar a Google | Depende por completo de si tus testers pasan de verdad del tutorial. | Testers que juegan al juego en lugar de dejarlo aparcado en la pantalla de inicio. |
| Tiempo hasta la primera aceptación | Días, según quién te conteste. | La prueba arranca en 4-6 horas. |
| Coste | Tu tiempo, durante las dos semanas que ya vas a dedicar a la compilación. | Desde $19.99, con repetición gratis o reembolso completo. |
Hay algo que ningún servicio puede ofrecer, y conviene desconfiar de quien lo haga: el acceso a producción en sí. Eso lo decide Google, que valora la calidad de tus pruebas además de la cifra, y puede pedirte otro ciclo. Lo que sí se puede prometer es el grupo de testers, las dos semanas y la garantía que hay detrás. Ver los planes y qué incluye cada uno →
Preguntas frecuentes
¿Los juegos necesitan 12 testers durante 14 días en Google Play?
Sí, cuando el juego se publica desde una cuenta personal de desarrollador de Google Play creada después del 13 de noviembre de 2023. Google exige al menos 12 testers que hayan aceptado participar de forma continua en una prueba cerrada durante al menos los últimos 14 días antes de que ese desarrollador pueda solicitar el acceso a producción, y en la documentación actual no aparece por ningún lado un mínimo de testers específico para juegos. Google trata las apps y los juegos dentro del mismo proceso de acceso a producción.
Sigo viendo 20 testers por internet. ¿Son 12 o 20 en 2026?
Son 12. Google exigía originalmente 20 testers y redujo oficialmente el mínimo a 12 el 11 de diciembre de 2024, describiendo el cambio como exigir 12 testers en lugar de 20. El periodo de pruebas continuo de dos semanas no cambió. Las páginas que siguen diciendo 20 se escribieron antes de ese cambio.
¿Cada juego nuevo necesita su propia prueba cerrada?
Sí, en las cuentas personales de desarrollador afectadas. La fecha de creación de la cuenta decide si el requisito te aplica, pero Google escribe la condición como una prueba cerrada «para tu app», y la solicitud de acceso a producción se envía para un paquete concreto. Una prueba válida para un juego no se traslada al siguiente juego que publiques desde la misma cuenta.
¿Mis 12 testers de juego tienen que jugar todos los días?
La regla explícita es que la participación se mantenga aceptada de forma continua. Google exige que los testers que califican sigan participando sin interrupciones y dice que la implicación de los testers cuenta cuando revisa el acceso a producción, pero no publica ninguna regla del tipo abrir el juego una vez al día o jugar un número determinado de minutos. Jugar de verdad, de forma significativa y con comentarios útiles es el objetivo seguro. La cuota de juego diaria es folclore de la comunidad, no política.
¿Si un tester se va, se reinician los 14 días enteros?
No de forma automática. Cuando solicitas el acceso, al menos 12 testers tienen que haber mantenido cada uno su participación durante los 14 días continuos anteriores. Si empezaste con más de 12 y todavía tienes esa cantidad de testers que califican, una baja no invalida la prueba. Si esa baja te deja con once, tienes que esperar a que un tester de reemplazo complete su propio periodo continuo de 14 días. Este es el argumento para reclutar por encima del mínimo.
¿Puedo subir una versión nueva del juego durante la prueba de 14 días?
Sí. La condición publicada por Google se basa en el historial de participación de los testers, no en mantener una versión congelada durante 14 días, así que publicar una versión nueva no borra por sí sola el periodo continuo de participación. Deja tiempo a que la versión nueva termine de procesarse, pide a los testers que actualicen y sigue documentando los comentarios y las correcciones que produjeron. Google señala que los cambios en una prueba pueden tardar varias horas en llegar a estar disponibles para los testers.
¿Basta con tener el juego instalado durante 14 días?
No tomes la instalación por sí sola como evidencia de que has probado el juego. El requisito numérico es la participación continua, pero la solicitud de acceso a producción pregunta cómo interactuaron los testers con el juego, qué comentarios se recogieron y qué cambió a raíz de ello. Google señala a los testers que no interactuaron con tu app como uno de los motivos por los que puede exigir más pruebas.
¿Desinstalar el juego reinicia la prueba de 14 días?
Google no publica ninguna regla aparte que diga que una desinstalación por sí sola reinicie el periodo de participación; el requisito numérico explícito es la participación continua. Pero un juego desinstalado no produce partidas, ni comentarios, ni evidencia de pruebas, y Google puede exigir más pruebas cuando la implicación es insuficiente. Mantener aceptada la participación sin abrir nunca el juego no es una estrategia segura y, en un juego, además significa que nadie está ejercitando las rutas de guardado, de entrega de recursos y de rendimiento que son las que de verdad se rompen.
¿Puedo usar la prueba interna en lugar de la prueba cerrada de 12 personas?
Para este requisito previo, no. La prueba interna es un canal aparte que admite hasta 100 testers, pero el requisito de Google para las cuentas personales nuevas afectadas exige específicamente una prueba cerrada válida antes de solicitar el acceso a producción. La prueba interna es útil para una distribución temprana y rápida; no cumple el paso obligatorio de la prueba cerrada.
¿Cuánto puede pesar mi juego Android en Google Play en 2026?
La Ayuda de Play Console indica 500 MB de módulo base, 500 MB por módulo de funciones, 1,5 GB por paquete de recursos, 4 GB acumulados para todos los módulos más los paquetes de recursos install-time, 30 GB acumulados para los paquetes fast-follow y on-demand, y un tamaño máximo total de descarga comprimida de 34 GB, con un máximo de 100 paquetes de recursos por bundle. Son tamaños de descarga comprimidos calculados por Play Console, no el tamaño del bundle en tu disco. Valores comprobados el 12 de agosto de 2026.
¿Los testers tienen que comprar un juego de pago durante la prueba cerrada?
Sí. Los testers de una prueba abierta o cerrada siguen teniendo que comprar el juego de pago. Los testers del canal de prueba interna sí pueden instalar un juego de pago gratis. Ese es un mecanismo distinto de la prueba con licencia para las compras integradas, que decide si una IAP usa los métodos de pago de prueba de Google en lugar de cobrar dinero real.
¿Por qué Google Play les cobra las compras integradas a los jugadores de mi prueba cerrada?
Estar en el canal cerrado y la prueba con licencia de la facturación son dos cosas distintas. Google indica que a los usuarios se les cobra de verdad salvo que sean testers de licencia, así que a un tester normal de tu canal cerrado se le puede cobrar dinero real. Añade en Settings y License testing las cuentas destinadas a probar compras para tener los métodos de pago de prueba de Google, incluidos los de aprobación siempre, rechazo siempre y los escenarios con retraso.
¿Por qué falla el inicio de sesión de Google Play Games en mi juego en prueba cerrada?
Play Games Services tiene su propia capa de acceso. Mientras la configuración de Play Games Services no esté publicada, los testers tienen que estar autorizados uno a uno o a través de un canal de publicación habilitado en Play Console; si no, Google dice que se encontrarán con errores de OAuth y 404. Añádelos en Grow users, Play Games Services, Setup and management, Testers, y comprueba que el nombre de paquete y la huella del certificado de firma coinciden con la versión.
¿Rechazan un juego pequeño o sencillo por funcionalidad mínima?
Google tiene una política de funcionalidad y calidad que exige experiencias estables, con buena respuesta y suficientemente funcionales, y las apps o los juegos que fallan, no cargan o son prácticamente no funcionales pueden incumplirla. Ninguna fuente primaria de Google publica un número mínimo fijo de niveles, pantallas, mecánicas ni minutos de juego. Trata cualquier cifra concreta que leas como folclore y arregla los problemas funcionales reales.
¿Las cajas de botín convierten automáticamente un juego Android en una app de juegos de azar?
No. Las políticas de Google separan los objetos virtuales aleatorios comprados de los juegos de azar con dinero real. Los juegos que ofrecen objetos virtuales aleatorios como las cajas de botín tienen que indicar con claridad las probabilidades antes de la compra y junto a ella. Pagar dinero o valor comprado por la posibilidad de ganar un premio del mundo real entra en la política aparte de Google sobre juegos de azar, juegos y concursos con dinero real, que es un régimen distinto con sus propios requisitos de elegibilidad y de licencias.
¿Puede otra persona aportar los 12 testers de mi juego?
Sí. El requisito de pruebas de Google no prescribe cómo hay que reclutar a los testers, así que pagar por pruebas de calidad no descalifica automáticamente. Léelo como la ausencia de una prohibición, no como que Google respalde los servicios de testers, cosa que nunca ha hecho. Lo que sí incumple la política es manipular valoraciones, reseñas, posicionamiento o número de instalaciones por medios ilegítimos, como bots, cuentas falsas o instalaciones fraudulentas. PrimeTestLab aporta 12 testers reales en dispositivos reales desde $19.99, mantiene al grupo participando los 14 días completos y respalda la prueba con repetición gratis o reembolso completo. Nadie puede prometer el acceso a producción, porque esa decisión es de Google y valora la calidad de tus pruebas además del número.
Conclusión
En resumen
Google Play no tiene ninguna cláusula para juegos. Una cuenta personal de desarrollador creada después del 13 de noviembre de 2023 necesita 12 testers que hayan aceptado participar durante 14 días de forma continua antes de poder solicitar el acceso a producción, tanto si publica un juego como si publica una calculadora, y la cifra de 20 que todavía circula quedó sustituida el 11 de diciembre de 2024. Cumplir ese contador es el suelo, no el veredicto: Google pregunta qué hicieron tus testers, qué te dijeron y qué cambiaste tú. Un juego se enfrenta además a una segunda capa que el contador no toca nunca, y ahí es donde esas dos semanas valen de verdad: paquetes de recursos que solo fallan cuando los entrega Play, fotogramas que se ralentizan cuando el teléfono se calienta, binarios nativos de 64 bits, testers a los que se les cobra dinero real porque nadie los añadió en Settings > License testing, el inicio de sesión de Play Games devolviendo un 404 a todo el mundo menos a ti, y la divulgación de probabilidades de los objetos aleatorios. Prueba todo eso durante las dos semanas que vas a invertir de todas formas. Si la parte que no puedes cubrir es la de los testers, PrimeTestLab aporta 12 testers reales de $19.99 con repetición gratis o reembolso completo. Ver planes y precios →
Fuentes principales
Qué se quedará desactualizado antes en esta página
- Los límites de tamaño. Es la tabla de más riesgo de esta página. La página específica de tamaños de Play Console y algunas páginas antiguas de juegos de Android ya se contradicen entre sí, y los topes de fast-follow y on-demand parecen haberse ampliado hace poco. Vuelve a consultar esa página de tamaños antes de planificar una versión en torno a 30 GB o 34 GB.
- Las fechas de facturación. Las ventanas de soporte de Play Billing Library se mueven versión a versión, y las fechas del 31 de agosto y del 1 de noviembre que aparecen en esta página cambian de significado en cuanto pasan. Esta página cambia sola su redacción en esas fechas; la tabla de soporte que hay detrás hay que volver a leerla de todos modos.
- Las fechas límite de las políticas. Es lo que más se mueve de toda la página. A mediados de agosto de 2026, Google pasó las fechas límite de contactos y de ubicación del 28 de octubre de 2026 al 27 de enero de 2027 en una sola de sus páginas y sin anuncio, y sus propios boletines siguieron citando después la fecha retirada. Cualquier fecha de aquí confírmala en las dos páginas de política vigentes de Google, y no en un boletín ni en un artículo, este incluido.
- Las rutas de la consola. Settings > License testing, Policy > App content y la ruta de testers de Play Games Services son la redacción actual, y la navegación de Play Console cambia al margen de las políticas.
- Los umbrales de Android vitals. Los valores de fallos, ANR y sesiones lentas son umbrales de calidad que Google puede revisar cuando le parezca, al margen de todo lo que tenga que ver con los requisitos de prueba.
- Las cifras de testers. Son las de menor riesgo del conjunto, pero el 20 ya se convirtió en 12 una vez. Si una cifra de aquí no coincide con la página de Google, la que tiene razón es la de Google y esta se ha quedado vieja.
Comprobado con la documentación de Google el 12 de agosto de 2026. Las fechas límite de las políticas se volvieron a comprobar el 14 de agosto de 2026.