Respuesta rápida
A fecha de 17 de agosto de 2026, Google no publica ninguna regla que diga que una denegación de tipo más pruebas requeridas reinicie el reloj de la prueba cerrada. Su centro de ayuda solo dice que a una app denegada se le puede exigir continuar con las pruebas. Si tu denegación indica expresamente ejecutar la prueba cerrada durante 14 días adicionales con testers reales, completa esos 14 días antes de volver a solicitarlo. Si solo dice continuar las pruebas, no hay publicada ninguna espera numérica aparte, y ninguna fuente de Google exige crear un canal de prueba cerrada nuevo. En cualquier caso el mínimo de elegibilidad no cambia: al menos 12 testers que hayan aceptado participar durante los 14 días de forma continua anteriores, en una prueba cerrada. No pidas a tus testers que se den de baja y vuelvan a entrar para forzar un reinicio, porque darse de baja rompe el periodo continuo que Google cuenta de verdad.
| Tu situación | Qué se sabe oficialmente | Siguiente paso más seguro | Vuelve a solicitar cuando |
|---|---|---|---|
| Tu mensaje menciona explícitamente 14 días adicionales | La decisión que recibiste menciona un período de pruebas adicional. El Centro de ayuda de Google no publica ese período por sí mismo. Texto de decisión reproducido | Mantén en marcha la prueba cerrada que ya califica y completa el período que indica tu mensaje. | Ese período está realmente completo, al menos 12 testers siguen calificando, y tu evidencia de preparación ha mejorado. |
| Tu mensaje solo indica continuar las pruebas | Este texto reproducido no indica ninguna duración adicional, y el Centro de ayuda público de Google no proporciona ningún período de espera numérico universal para él. Texto de decisión reproducido | Continúa la prueba existente y refuerza lo que puedes decir con sinceridad sobre ella. No adoptes un número que tu mensaje no te dio. | Play Console permite la solicitud y tus respuestas han cambiado de forma sustancial, no solo por el paso del tiempo. |
| Actualmente califican menos de 12 testers | No se cumple la elegibilidad publicada, diga lo que diga tu denegación. Requisito oficial de Google | Restablece un grupo que califique antes que cualquier otra cosa. Un tester de reemplazo necesita sus propios 14 días continuos. | Al menos 12 testers tienen, cada uno, sus propios 14 días previos de aceptación de participación sin interrupción. |
| No encuentras el mensaje de la decisión | Se desconoce la duración que se te aplica, y ninguna fuente proporciona un valor por defecto. No documentado públicamente | Recupera el mensaje del correo del titular de la cuenta, las notificaciones de Play Console o el historial de soporte, y mantén mientras tanto en marcha la prueba existente. | Has recuperado la instrucción, o soporte de Play Console la ha confirmado. No inventes una duración. |
La tabla se desplaza lateralmente en pantallas estrechas
Esa tabla tiene que ser condicional porque la orientación pública de Google es menos concreta que los mensajes de decisión que reciben los desarrolladores; promediar ambas cosas en una única respuesta segura produce una página que es incorrecta para la mitad de sus lectores. Cada afirmación de abajo está etiquetada como orientación oficial, texto de decisión reproducido, experiencia de la comunidad o inferencia operativa, y todo ello está vigente a fecha de 17 de agosto de 2026.
Las causas del rechazo quedan deliberadamente fuera del alcance aquí: esta publicación se centra en qué hacer después de que llega el mensaje. Para el lado del diagnóstico, consulta nuestra publicación sobre por qué se deniegan las solicitudes de acceso a producción.
El centro de recuperación
Dos herramientas creadas para esta denegación en concreto. Ambas se ejecutan en tu navegador con el texto que escribes o los taps que haces. Nada se sube, se guarda en un servidor ni se envía a ningún lugar.
Índice de contenidos
Qué dice realmente el mensaje de tu denegación
El mensaje que te envió Google es la instrucción más específica que vas a obtener, y tiene más peso que cualquier respuesta de foro sobre lo que "normalmente" pasa. Se han reproducido públicamente al menos dos versiones sustancialmente distintas. Antes de planear nada, averigua cuál de las dos tienes tú.
Desarrolladores en el mismo hilo de un foro se contradicen entre sí porque están describiendo mensajes genuinamente distintos. Por eso esta publicación clasifica su evidencia en tres niveles en lugar de promediarla:
-
Nivel 1
El Centro de ayuda actual de Google
El único nivel que es política oficial, y el menos específico, porque está escrito para todos los desarrolladores a la vez.
-
Nivel 2
Un mensaje de denegación reproducido por el desarrollador que lo recibió
Directamente accionable para esa app, pero no es texto de política oficial, y Google ha cambiado demostrablemente el texto con el tiempo.
-
Nivel 3
Reportes de foros y de la comunidad
Útil para mostrar que algo es posible, nunca para demostrar que es obligatorio.
Esto es todo lo que el Nivel 1 dice sobre tu situación. Que sea tan breve es precisamente lo importante.
... may be required to continue testing your app.
El fragmento que Google publica sobre lo que puede pasar cuando una solicitud de acceso a producción no se aprueba. Ayuda de Google Play Console, respuesta 14151465, consultada el 17 de agosto de 2026. Ver la página fuente
Ese pasaje público no menciona ningún reinicio, ningún contador nuevo, ningún período de espera ni ninguna instrucción de reconstruir el grupo de testers. Esos detalles aparecen, cuando aparecen, solo en el texto de la decisión específico de cada cuenta o en reportes de la comunidad. Los ejemplos que da Google de por qué una app no está lista son menos testers de los requeridos, o testers que no mostraron interacción. Todo lo demás que circula sobre esta denegación es Nivel 2 o Nivel 3, y el decodificador de abajo te dice cuál es tu propio mensaje.
Herramienta 01
Decodificador de denegaciones
O toca las frases que aparecen en él
Se ejecuta completamente en tu navegador. Sin subidas, sin almacenamiento, sin solicitudes de red.
Pega tu mensaje o toca una frase de arriba, y este panel te dirá qué variante es, qué demuestra y qué no.
Variante
ParcialQué demuestra este texto
Qué no demuestra
Tu instrucción más específica
Señales encontradas en tu texto
Un límite para todo esto: tu denegación es la instrucción más específica disponible para ti, no lo único que se interpone entre tú y una segunda solicitud. Play Console sigue controlando si el botón de solicitar está activo, y tu cuenta todavía tiene que mantener al menos 12 testers con historiales de aceptación de participación que califiquen el día en que lo pulses. Sigue cualquier duración que mencione tu mensaje, y verifica esas dos cosas por separado.
¿Qué pasa si no encuentras el mensaje de la decisión?
En ese caso, la postura honesta es que no sabes qué instrucción se te aplica, y ninguna página puede suplir la que falta. La variante sin duración no es una opción por defecto segura: asumirla cuando tu cuenta en realidad recibió el otro texto significa volver a solicitar antes de que termine un período que sí se indicó.
- Busca en el correo del titular de la cuenta, incluida la carpeta de spam y cualquier dirección distinta a la que revisas a diario, el párrafo que empieza con "Before applying again".
- Revisa las notificaciones de Play Console y las páginas de estado de políticas o de publicación de la app en busca de la decisión.
- Revisa tu historial de soporte de Play Console, donde un contacto anterior sobre la misma decisión puede citártela de nuevo.
- Mantén en marcha la prueba cerrada existente mientras buscas. Nada en la búsqueda del mensaje te obliga a pausar, vaciar o reconstruir nada.
- Contacta con soporte de Play Console si no se puede recuperar la instrucción, y pídeles que confirmen qué le dijeron a tu app. Inferencia operativa
Hasta que tengas el texto exacto o una confirmación, no asumas ninguna duración en ningún sentido: ni otra quincena, ni ninguna.
¿Se reinicia la prueba cerrada de 14 días después de una denegación?
Google no documenta un reinicio universal: su Centro de ayuda dice únicamente que a una app denegada se le puede exigir continuar con las pruebas. Tu mensaje de denegación es la instrucción específica, y esos mensajes han llegado en al menos dos formas: una menciona 14 días adicionales, la otra no menciona nada.
La palabra "reinicio" es la que causa el daño: se usa para tres cosas distintas, y solo la tercera es una regla publicada.
- Un reinicio de la plataforma. Un evento del lado de Google que borra el período de calificación de todos los que están en la prueba. No se encontró ninguna fuente
- Un período de pruebas adicional. Una instrucción, entregada en el mensaje de denegación, de probar durante un tiempo adicional indicado antes de volver a solicitar. Documentado en una familia de mensajes
- Una racha individual interrumpida. El período de aceptación de participación continua de un tester que termina porque salió de la prueba. Mecánica publicada
Ese tercero se aplica a los testers de forma individual, no a la prueba en su conjunto. Aquí está el conjunto completo de evidencia, clasificado.
| Evidencia | Qué dice | Qué puedes concluir | Confianza |
|---|---|---|---|
| Centro de ayuda de Google, consultado el 17 de agosto de 2026 | A una app denegada se le puede exigir continuar con las pruebas. Los ejemplos que se dan son menos testers de los requeridos, y testers que no mostraron interacción. | Google espera que las pruebas continúen después de una denegación, y no define ningún evento de reinicio universal en ninguna parte de la página. | Texto verificado |
| Denegación de 2024, reproducida en la comunidad de desarrolladores de Google | Indica al desarrollador que pruebe usando pruebas cerradas durante 14 días adicionales con testers reales antes de volver a solicitar. | Ese destinatario tuvo que hacer otros 14 días. Es una evidencia sólida de que Google ha usado una variante con un período adicional explícito. | Parcial, reproducido por un usuario |
| Denegación de 2025, reproducida en la comunidad de desarrolladores de Google | Indica al desarrollador únicamente que continúe las pruebas, siguiendo la guía de Google para obtener acceso a producción. No aparece ningún número de días. | Al menos una familia de mensajes no indica ningún período posterior a la denegación en absoluto. | Parcial, reproducido por un usuario |
| abril de 2026, un foro turco de desarrolladores | El mismo mensaje sin duración, publicado por un desarrollador que ya había pagado por dos rondas de pruebas cerradas. | La redacción más reciente seguía circulando en 25 de abril de 2026, fuera de la propia comunidad de Google y en otro idioma. | Reportado por la comunidad |
| La guía de buenas prácticas de pruebas de Google | Sigue usando pruebas cerradas mientras resuelves los problemas que reportan los testers. | Esto respalda mantener activa la prueba cerrada actual mientras se resuelven los problemas reportados. No documenta qué pasa si un desarrollador crea otro canal. | Inferencia operativa |
La tabla se desplaza lateralmente en pantallas estrechas
Esas cinco filas respaldan una única respuesta honesta, y es condicional: sigue el texto de la denegación que realmente recibiste, y no trates ningún rechazo como prueba de que Google reinició formalmente un temporizador.
Si tu correo dice 14 días adicionales
Entonces esa es tu instrucción, y el punto más temprano y seguro para volver a solicitar es después de que esos 14 días estén realmente completos. Google no publica dónde debe cumplirse el período, así que cumplirlo en el canal existente que ya califica es una inferencia operativa y no una regla de Google. Aprovecha la quincena en lugar de solo esperar a que pase: el mismo mensaje que te dio el número también pide testers reales. Inferencia operativa
No es evidencia de un mecanismo a nivel de toda la plataforma: a un desarrollador le dijeron que hiciera 14 días más, y esa es toda la afirmación. La pérdida normal de testers todavía puede costarte el grupo, así que revisa quién está aceptando participar actualmente antes de asumir que los 12 siguen intactos.
Si tu correo solo dice continuar las pruebas
Entonces no se te dio ninguna duración, y el Centro de ayuda de Google no publica ningún período de espera numérico que llene ese vacío. No inventes uno. Y cuidado con el error contrario, porque "continuar las pruebas" no es un permiso para volver a solicitar esa misma tarde. Mantén en marcha la prueba que ya califica y solicita cuando se cumplan dos cosas: que Play Console te lo permita, y que puedas mejorar de forma sustancial tus respuestas de preparación. Si tu denegación mencionó la interacción o el número de testers, esas son las cosas que hay que describir de otra manera.
Sobre la regla de los 14 días en sí
Los 14 días de la regla de elegibilidad y los 14 días de ese mensaje de denegación de 2024 comparten un número y nada más. La regla es cuánto tiempo lleva cada tester aceptando participar de forma continua; la instrucción es cuánto tiempo seguir con las pruebas antes de volver a solicitar. Nuestra publicación sobre el requisito de los 14 días consecutivos cubre la primera en detalle.
¿Deberías mantener la misma prueba cerrada o crear un canal nuevo?
Google no publica ninguna regla que exija un nuevo canal de pruebas cerradas después de una denegación de acceso a producción. Salvo que tu decisión o Play Console indiquen otra cosa, mantener activo el canal existente que ya califica es la opción por defecto de menor riesgo, porque conserva la configuración de pruebas y las relaciones con los testers que ya tienes. La propia guía de buenas prácticas de Google apunta en la misma dirección: seguir usando pruebas cerradas mientras corriges lo que reportaron los testers. Crear un nuevo canal tampoco está documentado como algo prohibido, pero no es obligatorio, y mover a las personas cuesta un historial de aceptación de participación que no se recupera fácilmente. Esto es una inferencia operativa, no un requisito independiente de Google. Inferencia operativa
Esta es la pregunta más repetida en los hilos de la comunidad detrás de esta publicación, y el miedo que hay debajo es razonable: que elegir mal desperdicie otras dos semanas. Lo que no se sabe es qué haría Google si sí crearas un nuevo canal, porque nunca ha publicado nada al respecto en ningún sentido. Dada una recomendación documentada y un silencio, la ruta de menor riesgo es la documentada.
Sigue haciendo
- Mantén activo el canal existente que ya califica, con su versión en vivo y su inscripción de testers intacta.
- Confirma en Play Console quién ha aceptado participar realmente, no a quién invitaste.
- Mantén la compilación de prueba instalable y que valga la pena abrir.
- Sigue recopilando feedback por el canal que tus testers ya usan.
- Publica correcciones en el mismo canal cuando las pruebas lo justifiquen.
Deja de hacer
- Eliminar o vaciar el canal para marcar un nuevo comienzo.
- Crear un canal paralelo y repartir a tus testers entre los dos.
- Pedirles a los testers que salgan y vuelvan a unirse.
- Eliminar a los testers que estuvieron callados, cuando lo que necesitas de ellos es interacción, no ausencia.
- Pausar el lanzamiento mientras decides qué hacer a continuación.
La ruta de la consola para revisar cualquiera de estas cosas no ha cambiado: Testing Closed testing Manage track Testers
¿Los mismos testers siguen contando?
La regla estricta. Cada tester que cuenta para la elegibilidad necesita un historial de aceptación de participación continua que califique, actualmente al menos los últimos 14 días sin interrupción. Eso está publicado, y se mide por persona y no como un único temporizador global para la prueba.
La incertidumbre. Google no publica ninguna regla que diga que un desarrollador denegado deba sustituir a sus testers. Un comentarista de r/androiddev describe una aprobación en un cuarto intento sin añadir ningún tester nuevo, lo cual va en contra de presentar la sustitución como obligatoria. Es una sola anécdota y no puede demostrar que los mismos testers siempre funcionan, pero es más evidencia de la que existe del otro lado, donde no hay ninguna.
El replanteamiento útil
La pregunta no es si tus testers pueden quedarse. Es si esta vez van a hacer algo. Un grupo que se mantuvo aceptando participar y nunca abrió la app produjo exactamente el vacío de evidencia que Google señala cuando dice que los testers no mostraron interacción, y cambiar 12 personas silenciosas por otras 12 personas silenciosas no arregla nada.
¿Deberías pedirles a los testers que salgan y vuelvan a unirse?
No. Este es el error más concreto que esta publicación puede evitar, y es popular precisamente porque da la sensación de estar haciendo algo.
Salir de la prueba termina el período continuo de esa persona. No hay ningún reinicio documentado que salir y volver a unirse pueda activar, así que la táctica destruye historial real que ya calificaba a cambio de nada, y lo hace con cada tester que coopera al mismo tiempo. Un desarrollador que hace esto con todo el grupo convierte un grupo que calificaba ayer en un grupo que califica dentro de dos semanas.
El mismo razonamiento se aplica a la versión más suave de la idea, que es eliminar a los testers que parecen inactivos para que la lista "empiece limpia". Si te quedas por debajo de 12 después de eso, has empeorado el problema de elegibilidad en lugar de mejorarlo, y nuestra publicación sobre qué hacer cuando menos de 12 testers siguen calificando cubre a dónde ir desde ahí. Si necesitas reconstruir el grupo en lugar de repararlo, nuestra publicación sobre formas de reclutar a 12 testers fiables es el complemento práctico.
¿Qué debería cambiar antes de volver a solicitar?
Trabaja con las propias entradas de revisión de Google, no con una lista de suposiciones. Google publica un umbral de elegibilidad, y después pregunta sobre la interacción de los testers, el feedback que recopilaste, qué cambió a raíz de eso, y por qué consideras que la app está lista. Esas cinco cosas son toda la forma de la segunda solicitud.
Fíjate en lo que falta en esa lista: una causa de tu denegación. Google no publica un modelo de puntuación, y ninguna página puede decirte qué respuesta inclinó la decisión. Lo que sí puede decirte es qué temas está mirando realmente el revisor, lo cual es un mejor uso de una quincena que adivinar. Para la pregunta más amplia de por qué las apps fallan en esta etapa, nuestra publicación sobre por qué se rechaza la prueba cerrada cubre las causas; esta sección se centra en la recuperación.
Mantén al menos 12 testers aceptando participar de forma continua
Este es el único umbral estricto de todo el proceso, y vale la pena leerlo en las propias palabras de Google en lugar de en la paráfrasis de cualquiera.
Si tienes una cuenta personal de desarrollador recién creada, debes ejecutar una prueba cerrada para 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 Google Play Console, respuesta 14151465. Se aplica a las cuentas personales de desarrollador creadas después del 13 de noviembre de 2023. Google redujo el requisito de 20 testers a 12 el 11 de diciembre de 2024. Ver la página fuente
Tres cosas de esa frase se malinterpretan habitualmente. Es un mínimo, no una meta, y nada publicado dice que un número más alto funcione mejor. Es continuo, medido por cada tester, así que si una persona se va rompe su propia calificación, no la de todos los demás. Y especifica una prueba cerrada, por lo que las pruebas internas no lo cumplen sin importar cuántos de sus 100 cupos ocupes. Si estás decidiendo entre los canales, nuestra publicación sobre pruebas internas frente a cerradas frente a abiertas explica para qué sirve cada una.
Si tu grupo cayó por debajo del umbral desde la denegación, eso es lo primero que hay que corregir, y requiere tiempo de calendario: un tester de reemplazo necesita sus propios 14 días continuos antes de contar. Reclutar en el día 10 de un plan construido en torno al día 14 es cómo la gente termina denegada dos veces.
Dale a los testers cosas específicas que probar
La recomendación de Google es concreta: dale a los testers instrucciones claras, diles qué tipo de feedback quieres, y anímalos a usar tantas funciones de la app como sea posible. Eso es una instrucción muy distinta de "por favor, mantenla instalada", que es lo que en realidad se les pide a la mayoría de los grupos de 12 testers.
Es también la recomendación con la mayor brecha entre lo que dice Google y lo que dice internet. Lo que en realidad pregunta el formulario de acceso a producción es si los testers usaron las funciones de la app, y si ese uso se pareció a como esperas que se comporten los usuarios reales. Son preguntas que se pueden responder sobre cobertura, no sobre cadencia.
- Nombra las funciones. Dos o tres de las más importantes, por su nombre, para que una respuesta sobre cobertura más adelante sea una descripción y no una afirmación vacía.
- Nombra los flujos. Registrarse, crear algo, editarlo, compartirlo o exportarlo, volver al día siguiente y encontrarlo todavía ahí.
- Nombra qué quieres que te devuelvan. Dónde se atascaron, qué esperaban que pasara, qué no volverían a usar.
- Reparte los dispositivos que ya tienes. Se recomiendan dispositivos reales representativos; no se publica ningún umbral numérico de modelos de dispositivo.
Registra el feedback y haz mejoras justificadas
Google recomienda responder al feedback de los testers y corregir los errores que las pruebas revelan, y dice que hacerlo puede mejorar la probabilidad de que la solicitud de acceso a producción tenga éxito. Esa es una evidencia mucho más sólida que cualquier receta de la comunidad sobre cuántos lanzamientos publicar, y es el único lugar donde "hacer más" está genuinamente respaldado.
En la práctica, esto toma la forma de un registro. Te van a pedir que resumas qué feedback recibiste y qué cambió a raíz de eso, y reconstruir eso de memoria una quincena después es donde buenas pruebas terminan produciendo solicitudes débiles. Lleva algo como esto, una fila por cada elemento.
| Feedback recibido | Decisión | Cambio realizado | Validado por | Compilación |
|---|---|---|---|---|
| Qué dijo el tester, con sus propias palabras, además de cómo reproducirlo | Corregir ahora, corregir más adelante, o no cambiar nada y por qué | Qué cambiaste realmente | Quién lo confirmó, y cómo | Código de versión en el que se publicó |
Plantilla en blanco. La tabla se desplaza lateralmente en pantallas estrechas
La fila de "no cambiar nada y por qué" importa tanto como las correcciones. Una respuesta de preparación para producción que indica qué problemas conocidos quedan y por qué no impiden el lanzamiento es una respuesta más sólida que una que da a entender que todo fue perfecto. Y el canal por el que llegó el feedback es tu elección: correo, un sitio web o foro, o el feedback privado que los testers pueden enviar a través de Google Play, que aparece en Monitor and improve Ratings and reviews Testing feedback
Sobre las actualizaciones: publica una cuando las pruebas lo justifiquen. Google anima a corregir lo que las pruebas encuentran, y actualizar la compilación durante una prueba cerrada no rompe el requisito de testers, algo que nuestra publicación sobre si actualizar tu app reinicia la prueba cerrada cubre en detalle. Lo que no se publica en ningún lado es un número obligatorio de lanzamientos, así que publicar compilaciones solo para alcanzar una cifra es esfuerzo gastado en un número que nadie fijó.
Revisa el informe previo al lanzamiento
Google remite a los desarrolladores al informe previo al lanzamiento para investigar problemas, advertencias y errores antes de publicar. Léelo antes de la segunda solicitud, y trata lo que señala como trabajo pendiente y no como un diagnóstico: nada publicado dice que una advertencia concreta haya causado una denegación de acceso a producción, ni que haya que resolver todas las advertencias primero. Es una fuente de problemas reales que puedes corregir mientras ya estás corrigiendo otras cosas.
Revisa el cumplimiento de políticas, la fiabilidad de la app y las credenciales de revisor
La actividad de las pruebas no es todo lo que Google te pide confirmar antes de solicitar. Su guía actual nombra cuatro áreas de preparación además de la prueba cerrada, y una quincena dedicada únicamente a la interacción de los testers puede terminar topándose, en cambio, con una decisión sobre una de estas.
Las cuatro verificaciones oficiales de preparación
Cumplimiento de políticas. Confirma que la app cumple las políticas de Google Play, y que su contenido, funciones y monetización son lo que dice la ficha de la tienda. Público objetivo y clasificación de contenido. Confirma que el público declarado y el cuestionario de clasificación de contenido siguen coincidiendo con lo que la app realmente hace. Fiabilidad funcional. Confirma que la app funciona como se espera, sin los fallos y flujos rotos con los que un revisor se toparía primero. Credenciales de revisor. Si alguna parte de la app está detrás de un inicio de sesión, aporta credenciales de prueba que funcionen en App access, porque un revisor que no puede entrar no puede ver lo que probaste.
Esto queda fuera del enfoque de esta publicación, que es la mecánica de la recuperación, así que trata la lista como una lista de verificación y no como una guía. Lo que importa aquí es que una decisión de "se requieren más pruebas" es una decisión de preparación, y la preparación abarca más que el número de testers. Requisito oficial de Google
Cómo volver a solicitar el acceso a producción
La ruta no cambia respecto al primer intento: abre la app en Play Console, ve a Dashboard, y elige Apply for production en cuanto seas elegible. Google describe actualmente el formulario en tres secciones, que cubren tu prueba cerrada, tu app o juego, y la preparación para producción.
No hay ningún flujo de nueva solicitud documentado por separado, ni un formulario distinto, ni una cola publicada para los segundos intentos. Lo que cambia es lo que tú aportas.
| Sección | Qué pregunta Google | Qué tener preparado |
|---|---|---|
| Sobre tu prueba cerrada | Cuán difícil fue reclutar a los testers | Una descripción honesta de cómo conseguiste a tus testers |
| Sobre tu prueba cerrada | Interacción de los testers | Qué funciones importantes se usaron, y si ese uso se pareció al comportamiento esperado en producción |
| Sobre tu prueba cerrada | Feedback | Los temas principales que escuchaste, y el canal por el que los recopilaste |
| Sobre tu app o juego | Público al que va dirigido | Un grupo de usuarios específico, no todo el mundo |
| Sobre tu app o juego | Valor, o qué diferencia al juego | Una propuesta de valor concisa y real |
| Sobre tu app o juego | Instalaciones esperadas en el primer año | Tu mejor estimación aproximada. Google dice que una estimación es aceptable |
| Preparación para producción | Qué cambió gracias a la prueba cerrada | Ejemplos concretos de feedback y los cambios correspondientes, tomados de tu registro |
| Preparación para producción | Por qué la app está lista | Evidencia de las pruebas y de la resolución de errores, no el simple hecho de que pasaron 14 días |
La tabla se desplaza lateralmente en pantallas estrechas
No confíes en un número de preguntas
Las páginas que actualmente posicionan para este tema no coinciden entre sí sobre si se trata de un formulario de diez preguntas o de veinte, y algunas citan mínimos de caracteres. Google describe tres secciones y los temas anteriores. Trata cualquier cifra específica, incluida cualquiera que leas aquí, como algo que debes verificar en tu propia consola en lugar de algo sobre lo que planificar.
Qué decir sobre la interacción, el feedback y la preparación
Interacción. Google pregunta si los testers usaron las funciones de la app y si ese uso se pareció a lo que esperas en producción, así que la respuesta más sólida es descriptiva y específica: qué funciones, por su nombre, y qué hicieron realmente los testers con ellas. Si un uso entusiasta no es lo que ocurrió en tu prueba, di lo que sí ocurrió. Una respuesta que describa un uso modesto pero genuino es defendible; una que describa actividad que no puedes respaldar con evidencia es algo que después tendrás que mantener coherente en cada solicitud posterior.
Feedback. Resume los temas en lugar de transcribir los mensajes, y menciona el canal de recopilación. Un correo, un sitio web o foro, y el feedback privado de Play cuentan todos, así que no hay un canal equivocado que hayas usado, solo una pregunta sin respuesta si no recopilaste nada en absoluto.
Cambios y preparación. Vincula cada cambio significativo a un hallazgo concreto de las pruebas, y explica después por qué los problemas que quedan no impiden el lanzamiento. Esas son las dos respuestas donde una quincena bien documentada supera claramente a una sin documentar. Para el tratamiento completo de cómo redactar cada una, consulta nuestra publicación sobre respuestas del cuestionario de acceso a producción.
¿Qué pasa si Apply for production sigue deshabilitado?
Un botón Apply for production en gris o ausente normalmente significa que aún no se cumple alguna condición de elegibilidad o de configuración de la app. También son posibles los retrasos de la consola y los problemas específicos de la cuenta, así que revisa las condiciones documentadas a continuación antes de concluir que la interfaz está fallando.
- El número aún no se cumple. Es posible que la cuenta no tenga actualmente 12 testers con los 14 días previos requeridos de aceptación de participación continua, sea cual sea el total que muestre la lista de invitaciones.
- Invitado no es lo mismo que aceptado. Las personas que recibieron un enlace y nunca lo aceptaron no son testers a estos efectos. Revisa quién ha aceptado participar realmente, no a quién se le pidió.
- Los reemplazos todavía están acumulando tiempo. Alguien añadido después de la denegación empieza sus propios 14 días continuos desde el momento en que acepta participar, así que un grupo ya completado a doce personas puede seguir sin ser elegible durante otra quincena.
- La configuración de la app está incompleta. Una ficha de la tienda, una clasificación de contenido, un App access o unas declaraciones de políticas pendientes pueden bloquear la solicitud independientemente de tu número de testers.
- Debe ser una prueba cerrada la que cuenta. Las pruebas internas no cumplen este requisito, sin importar cuántos de sus cupos estén ocupados.
Si en tu propia consola todas esas condiciones parecen cumplirse y el botón sigue sin aparecer, esa es una de las situaciones que vale la pena llevar a soporte de Play Console en lugar de esperar, porque ya no estás solucionando algo que la documentación pública describe.
Guarda tu propia copia
No está documentado en el Centro de ayuda público de Google si las respuestas enviadas anteriormente siguen siendo visibles o editables en una solicitud posterior, y esta publicación no lo va a adivinar. Redacta tus respuestas en algún sitio que controles tú y pégalas después, para que un segundo intento nunca dependa de que la consola te muestre lo que escribiste la primera vez. No verificado: necesita una captura actual de la consola
Una línea sobre qué es exactamente lo que estás solicitando, porque es fácil perderlo de vista en un segundo intento: la aprobación desbloquea los lanzamientos de producción de la app, y también desbloquea las pruebas abiertas, así que el lector que quería una beta más amplia en lugar de un lanzamiento en la tienda está esperando la misma decisión. Todo lo que viene después de ese punto es gestión de lanzamientos habitual, no una continuación de este proceso.
¿Necesitas aperturas diarias, más testers o más actualizaciones?
Ninguna regla publicada exige nada de esto. Google publica un número de testers y un período de aceptación de participación continua. Recomienda interacción, feedback y actuar sobre ese feedback. No publica ninguna cifra para aperturas diarias, minutos por sesión, lanzamientos, mensajes de feedback o modelos de dispositivo, y las cifras seguras que circulan en foros y páginas de la competencia son tácticas, no requisitos.
Aquí es donde se produce la mayor parte del daño. Un desarrollador denegado busca qué salió mal, encuentra una página que dice que los testers deben abrir la app a diario y que hay que lanzar tres versiones, y pasa la quincena persiguiendo un objetivo que Google nunca fijó, mientras lo que Google realmente preguntó (si los testers usaron la app de forma significativa, y qué hiciste con lo que te dijeron) queda sin atender. Vale la pena decir la postura honesta con claridad: la guía pública de acceso a producción de Google no ofrece ningún umbral numérico de interacción ni ninguna rúbrica de puntuación publicada. Las preguntas del formulario son entradas de revisión, no una rúbrica con ponderaciones, y ningún panel publicado convierte tu actividad de testers en una calificación que puedas leer. Así que el movimiento útil no es adivinar el número, sino saber cuáles de las cosas que te han dicho están realmente publicadas.
| Lo que te dijeron | Estado | Qué puedes decir en su lugar |
|---|---|---|
| Los testers deben abrir la app todos los días | No documentado públicamente | Google no publica ningún requisito de una vez al día. Espera una interacción significativa y pregunta si los testers usaron tus funciones, pero ninguna cadencia diaria aparece en su guía pública. La regla publicada de 14 días se refiere al estado de aceptación de participación continua, no al uso diario. |
| Los testers deben usar la app durante un número determinado de minutos | Folclore de la comunidad | Ninguna fuente primaria indica una duración de sesión obligatoria. No diseñes una prueba alrededor de un número que nadie publicó. |
| Debes lanzar dos o tres actualizaciones | Folclore de la comunidad | No se publica ningún número obligatorio de lanzamientos. Actualiza cuando el feedback de los testers identifique una corrección justificada, no para alcanzar una cifra. Google sí recomienda corregir lo que las pruebas revelan, que es la parte que realmente vale la pena hacer. |
| Necesitas un número mínimo de mensajes de feedback | No documentado públicamente | No existe ningún umbral publicado. Reúne suficiente feedback real para entender y mejorar la app, y sé capaz de resumir lo que recibiste y qué cambió gracias a ello. |
| Las respuestas del cuestionario deben tener al menos 250 caracteres | Folclore de la comunidad | No se encontró ninguna longitud mínima de respuesta publicada. Sé específico, completo y honesto en lugar de rellenar para alcanzar un número de caracteres. |
| Debes sustituir a tus testers después de una denegación | No documentado públicamente | No se encontró ninguna regla de sustitución publicada. Mantén a los testers calificados aceptando participar en lugar de romper rachas que ya tienes. Lo que señala la denegación es la interacción, y cambiar 12 personas silenciosas por otras 12 personas silenciosas no arregla nada. |
| Debes crear un nuevo canal de pruebas cerradas después de una denegación | No documentado públicamente | No se encontró ninguna instrucción de Google que exija un nuevo canal, y su guía de buenas prácticas apunta en la dirección contraria: seguir usando las pruebas cerradas mientras corriges lo que reportaron los testers. Mantener el canal existente es la opción por defecto de menor riesgo, lo cual es una inferencia operativa y no una regla de Google. |
| Tener más de 12 testers mejora tus probabilidades | No documentado públicamente | Google no publica ningún beneficio en la tasa de aprobación por tener un número superior a 12, así que nadie puede venderte un grupo más grande como una mejor oportunidad. Un grupo más grande sí ofrece resiliencia operativa real: un colchón contra las bajas, mayor cobertura de dispositivos y más feedback. Trátalo como una decisión operativa, no como una palanca de aprobación. |
La tabla se desplaza lateralmente en pantallas estrechas
Dos de esos merecen una frase más, porque son los que cuestan dinero de verdad. Comprar un grupo de testers más grande es una decisión operativa razonable, ya que un grupo de 12 no tiene ningún margen si una persona se va, pero nadie puede venderte eso honestamente como una mayor probabilidad de aprobación, y los reportes de la comunidad incluyen denegaciones con más de 30 testers y con 19 testers más 17 actualizaciones. Y perseguir una cuota de modelos de dispositivo desvía el esfuerzo de lo que Google realmente pregunta en el formulario: no se publica ningún umbral numérico de dispositivos, y los testers representativos en dispositivos reales son una recomendación, no una fórmula. Si quieres el detalle de qué cuenta como un participante válido de una prueba cerrada, nuestra publicación sobre emuladores en las pruebas cerradas de Google Play cubre bien el lado de los dispositivos.
Qué no hacer con esta tabla
Un estado de "no documentado públicamente" no es un permiso para hacer lo contrario. Google no publica ningún número mínimo de feedback, y una prueba que no produjo ningún feedback en absoluto sigue siendo una solicitud débil, porque te van a preguntar qué feedback recibiste y qué cambiaste a raíz de eso. La ausencia de un número significa que no hay ninguna cifra que alcanzar, no que la expectativa de fondo sea ficticia.
¿Cuántas veces puedes volver a solicitar?
A fecha de 17 de agosto de 2026 no se encontró ningún máximo público de Google, ni hay documentada una espera fija aparte, al margen de la continuación de pruebas que indique tu denegación. Hay informes de la comunidad que llegan a una cuarta solicitud y a una sexta denegación, lo que hace poco fiable cualquier afirmación de un techo de dos o tres intentos. Que no haya un límite publicado no es una promesa de intentos ilimitados.
Eso es casi la totalidad de la base de evidencia pública, y vale la pena ver lo escasa que es antes de que alguien te dé una cifra. Desarrolladores individuales en foros públicos describen una aprobación en una cuarta solicitud sin añadir testers nuevos, un aproximadamente sexto rechazo tras 19 testers y 17 actualizaciones, una segunda denegación con un grupo muy por encima del mínimo, y otra segunda denegación después de una quincena adicional completa con los mismos testers y correcciones ya publicadas. Te cuentan que esos intentos ocurrieron. No pueden decirte por qué cada uno resultó como resultó. Reportado por la comunidad
De ahí se siguen dos conclusiones, y solo dos. Primero, no hay un techo bajo evidente: existen solicitudes demostrables más allá de una segunda y una tercera. Segundo, y más útil, hacer más de lo mismo no es una estrategia. La mayoría de esos reportes describen a desarrolladores que añadieron testers, añadieron actualizaciones o añadieron tiempo y aun así fueron denegados. Si tu segunda solicitud es la primera más una quincena, estás reproduciendo la última de ellas.
Sobre el miedo que hay detrás de la pregunta: la guía pública de Google no clasifica una decisión de preparación de "se requieren más pruebas" como una infracción de política, y no se encontró evidencia de que las decisiones de preparación repetidas, por sí solas, lleven a la suspensión de la cuenta. Aun así puede existir en paralelo un problema de políticas independiente (la aplicación de políticas es un proceso propio con sus propios avisos y sus propios remedios), así que trata cualquier mensaje que mencione una infracción de políticas como lo que realmente es, y no como otra ronda de esta misma decisión.
¿Cuánto tarda Google en revisar una nueva solicitud?
La única cifra publicada por Google es que una solicitud de acceso a producción normalmente tarda 7 días o menos, y dice explícitamente que algunas revisiones tardan más. No hay ningún calendario publicado por separado para una segunda solicitud o posteriores. Hilos de la comunidad en 2026 reportan esperas muy por encima de esa estimación, así que trata los siete días como un caso normal, no como un plazo límite.
Esta sección existe sobre todo para evitar un comportamiento: llega el día ocho, la estimación ya pasó, y el desarrollador empieza a cambiar cosas. Los dos reportes de la comunidad de abajo muestran cuánto puede alejarse una revisión de la estimación sin que nada vaya mal.
Esas dos esperas largas son reportes individuales y solo demuestran que las esperas largas ocurren. No son una distribución, y pasar del día siete no es, por sí solo, una señal de que algo haya salido mal. Para el panorama más amplio de los tipos de revisión, consulta nuestra publicación sobre los tiempos de revisión de Google Play.
¿Cuándo vale la pena contactar con soporte de Play Console?
No hay ninguna regla publicada de "contacta con soporte después de X días", e inventar una sería el mismo error que inventar un período de espera. Lo que sí se puede decir es en qué situaciones la documentación pública deja de explicar, que es donde soporte se convierte en la única fuente de respuesta que queda:
- La instrucción no está disponible o es contradictoria. No puedes recuperar el mensaje de la decisión, o lo que dice no coincide con lo que muestra la consola.
- La consola sigue bloqueada. Apply for production sigue sin estar disponible aunque los criterios publicados parecen cumplirse y todo lo de la lista del botón deshabilitado de arriba se verifica correctamente.
- La revisión está sustancialmente fuera de la estimación sin ninguna información de estado disponible en ningún lugar de la consola.
- El mensaje parece un proceso distinto. Cualquier cosa que mencione una infracción de políticas o una medida técnica de aplicación no es esta decisión, y preguntar por eso aquí desperdicia la quincena.
Fuera de esos casos, esperar es la acción correcta, no la pasiva. Volver a enviar, modificar el canal o retirar una solicitud para volver a presentarla son todos cambios hechos a un proceso que no puedes ver, y ninguno de ellos está indicado por nada que publique Google.
Mientras esperas
Mantén en marcha la prueba cerrada durante toda la revisión en lugar de desmontarla en el momento en que pulsas enviar. Si la respuesta es otra solicitud de más pruebas, un grupo intacto es la diferencia entre continuar y volver a empezar el problema del reclutamiento desde cero.
Tu lista de verificación para volver a solicitar
Once pasos, en orden. La mayoría se basan en la guía actual de acceso a producción de Google. La recomendación de mantener el mismo canal, la recuperación del mensaje perdido, y parte del consejo sobre el orden son recomendaciones operativas y no reglas publicadas de Google. Inferencia operativa
Los once pasos, en orden
- Lee la denegación exacta y anota si especifica 14 días adicionales. Si no la encuentras, recupérala antes de planificar en torno a una duración.
- Mantén en marcha la prueba cerrada que ya califica. No cierres, elimines ni sustituyas el canal a causa de la denegación, y publica en él correcciones justificadas cuando las pruebas lo justifiquen.
- Mantén al menos 12 testers que califiquen aceptando participar de forma continua. Cada uno que cuentes necesita su propio período sin interrupción.
- No les pidas a los testers que salgan y vuelvan a unirse. Google no documenta ningún reinicio que volver a unirse pudiera activar, y salir rompe un período continuo real que ya tienes.
- Dale a los testers instrucciones de prueba reales a nivel de funciones en lugar de pedirles solo que mantengan la app instalada.
- Registra el feedback significativo en un breve registro escrito, sea cual sea el canal por el que llegue.
- Corrige los errores justificados y los problemas de usabilidad, y después valida la corrección con el tester que la reportó.
- Revisa el informe previo al lanzamiento en busca de problemas, advertencias y errores antes de solicitar.
- Revisa las áreas de preparación fuera de las pruebas: cumplimiento de políticas, público objetivo y clasificación de contenido, fiabilidad funcional, y credenciales de revisor que funcionen en App access.
- Prepara respuestas específicas y veraces para el acceso a producción sobre interacción, feedback, cambios y preparación.
- Solicita desde Dashboard cuando seas elegible, y no le prometas a nadie una decisión en siete días.
Esa lista es el caso general. Tu caso tiene al menos tres variables que el caso general no puede ver: qué decía tu mensaje, en qué punto está realmente hoy tu grupo de testers, y cuántas veces has pasado ya por esto. El constructor de abajo convierte eso en una ruta ordenada que puedes seguir, y conserva tus marcas si cierras la pestaña.
Construye tu propia ruta
Herramienta 02
Constructor de la ruta de recuperación
01 ¿Qué dice tu mensaje de denegación?
02 ¿En qué punto está tu prueba cerrada ahora mismo?
03 ¿Alguien ha salido desde la denegación?
04 ¿Qué evidencia de pruebas puedes mostrar realmente?
05 ¿Qué número de solicitud será esta?
Responde las cinco y este panel construirá tu ruta ordenada, junto con la lista de qué no hacer correspondiente.
Haz esto, en este orden
No hagas esto
Tus respuestas y marcas se quedan solo en este navegador.
Una cosa que el constructor nunca va a mostrar, respondas lo que respondas, es una fecha en la que Google te va a aprobar. Nadie puede darte eso, y un reporte de la comunidad de un desarrollador aprobado en un cuarto intento convive con otro que describe una sexta denegación. Lo que sí puede hacer la ruta es asegurarse de que, cuando llegue la decisión, se esté tomando sobre una solicitud que puedes defender, y no sobre una quincena que simplemente transcurrió.
Si al seguir esa ruta descubres que el lado de los testers es el obstáculo (tu denegación exige explícitamente 14 días adicionales, o tu grupo ya no tiene 12 testers que califiquen), esa es la mitad que puedes delegar: PrimeTestLab se encarga de ella mientras tú mejoras la app, el registro de feedback y las respuestas de tu nueva solicitud. Eso se cubre en cómo ayudamos más abajo.
Cómo ayuda PrimeTestLab si necesitas otro grupo de testers
Solo si lo necesitas. Si tu denegación exige explícitamente 14 días adicionales, o tu grupo ya no tiene 12 testers que califiquen, PrimeTestLab puede encargarse del lado de los testers mientras tú mejoras la app, el registro de feedback y las respuestas de tu nueva solicitud. Si tu mensaje no mencionó ninguna duración y tus testers siguen aceptando participar y siguen usando la app, puede que ni siquiera necesites un segundo grupo, y esta publicación prefiere que te quedes con tu dinero.
Donde una ejecución gestionada se gana su lugar, la recuperación se divide en dos mitades. Una es el criterio: leer tu denegación, decidir qué cambiar, redactar respuestas que puedas defender. Esa mitad es tuya. La otra es la logística: mantener a 12 personas reales aceptando participar y usando la app durante toda una ventana de pruebas. No es el problema interesante, pero es el que consume el calendario.
PrimeTestLab aporta 12 testers reales en dispositivos reales que abarcan de Android 7 a 17, aceptando participar y mantenidos durante los 14 días completos, con las pruebas comenzando en 4-6 horas. Hemos hecho esto en 7,400+ apps en 120+ países con una tasa de finalización de pruebas gestionadas del 99.9%: finalización significa que la prueba mantuvo el número de testers requerido y un período de aceptación de participación sin interrupciones hasta su fecha de fin.
Lo que no hacemos, y lo que esta publicación ha argumentado que nadie puede hacer, es prometer la decisión: Google revisa el acceso a producción según sus propios criterios y no publica ninguna rúbrica. Nuestra garantía es una repetición gratis o reembolso completo: condiciones y plazo de reclamación en nuestra política de reembolso y repetición gratuita.
Reclutar otro grupo tú mismo frente a una ejecución gestionada
| Qué necesita otra ronda de pruebas | Reclutarlos tú mismo otra vez | Ejecución gestionada |
|---|---|---|
| Al menos 12 testers aceptando participar | La misma petición, a las mismas personas, después de que ya te dieron dos semanas | 12 aportados y mantenidos durante toda la ventana |
| 14 días continuos, sin interrupción | Si una persona sale se rompe su propio período de calificación, y puede que no te des cuenta en días | Supervisado para que la ventana se mantenga intacta, con las pruebas comenzando en 4-6 horas |
| Testers que realmente usan las funciones | Los amigos que la instalaron una vez son el grupo que ya tenías | Personas reales en dispositivos reales, de Android 7 a 17, usando la app durante la ejecución |
| Costo | Tu tiempo, durante la quincena en la que también estás reescribiendo tu solicitud | Desde $19.99 por 12 testers |
| Si no sale bien | Vuelves a empezar el problema del reclutamiento desde cero | Repetición gratis o reembolso completo |
La tabla se desplaza lateralmente en pantallas estrechas
Para ser directos sobre el límite: comprar testers no responde el cuestionario, no escribe tu registro de feedback, ni hace que Google apruebe nada. Todo lo que hay antes de esta sección está escrito para que puedas hacer bien esas partes. Lo que elimina una ejecución gestionada es la parte en la que una ventana de pruebas se derrumba por la misma razón que la primera.
Una advertencia que vale la pena repetir de la tabla de mitos de arriba: los grupos más grandes protegen contra las bajas, pero Google no publica ningún número por encima de 12 que aumente de forma medible la probabilidad de aprobación, así que nadie, nosotros incluidos, debería venderte testers adicionales como mejores probabilidades. Compra el colchón por el colchón. Desglose completo en la página de precios.
Consejo sobre el orden
Si tu denegación mencionó 14 días adicionales, empieza primero con el lado de los testers y haz tu propio trabajo dentro de esa ventana, no después de ella. Los plazos pueden solaparse: Google anima a actualizar la compilación durante una prueba, y publicar una actualización justificada en el mismo canal cerrado normalmente no exige que los testers salgan y vuelvan a unirse. Hacerlo todo en secuencia, en cambio, es cómo una recuperación de dos semanas se convierte en una de cinco.
Preguntas frecuentes
¿Necesito otros 14 días después de que me pidan más pruebas?
Cuando la propia denegación indica que pruebes 14 días adicionales con testers reales, completa ese período adicional antes de volver a solicitar. Cuando solo indica que continúes las pruebas, el Centro de ayuda público de Google no publica un período de espera numérico universal aparte, así que no asumas que se trata de otros 14 días a menos que eso sea justo lo que dice tu mensaje. Si no encuentras la decisión en absoluto, recupérala en lugar de dar por buena cualquiera de las dos respuestas. En cualquier caso, el umbral de elegibilidad sigue siendo el mismo: al menos 12 testers que hayan aceptado participar durante los 14 días anteriores de forma continua.
¿Debo continuar con el mismo canal de pruebas cerradas o crear uno nuevo?
Google no publica ninguna regla que exija crear un nuevo canal de pruebas cerradas después de una denegación de acceso a producción. Salvo que tu decisión o Play Console indiquen otra cosa, mantener activo el canal que ya cumple los requisitos es la opción por defecto de menor riesgo, porque conserva la configuración de pruebas y las relaciones con los testers que ya tienes. Google recomienda por separado seguir usando pruebas cerradas mientras corriges los problemas que reportan los testers. Crear un nuevo canal tampoco está documentado como algo prohibido, pero no es obligatorio, y mover a los testers pone en riesgo el historial de aceptación de participación que ya tienes acumulado. Esto es una inferencia operativa, no un requisito independiente de Google.
¿Necesito 12 testers nuevos después de un rechazo?
Google no publica ninguna regla que diga que el grupo deba sustituirse por 12 personas nuevas después de una denegación. Mantén a los testers ya calificados aceptando participar de forma continua en lugar de romper deliberadamente su racha. Un desarrollador en r/androiddev reporta haber obtenido la aprobación en un cuarto intento sin añadir testers nuevos, lo cual va en contra de tratar la sustitución como obligatoria, pero se trata de una sola anécdota de la comunidad, no de una garantía de Google.
¿Mis testers tienen que abrir la app todos los días durante 14 días?
El requisito publicado de 14 días se refiere al estado de aceptación de participación continua, no al uso diario. Google, por separado, espera una interacción significativa y pregunta en el formulario de acceso a producción si los testers usaron las funciones de la app y si su uso se pareció al comportamiento esperado en producción, pero su guía pública de acceso a producción no da ninguna cifra de una vez al día, minutos al día o sesiones al día. Apunta a una cobertura real de funciones y a feedback útil, en lugar de una cuota de actividad inventada.
¿Puedo cambiar las respuestas de mi cuestionario cuando vuelva a solicitar?
Esto es genuinamente algo no verificado. El Centro de ayuda público de Google explica qué pregunta el cuestionario de acceso a producción, pero no documenta si todos los campos de una solicitud rechazada anterior siguen siendo editables o siquiera visibles en una solicitud posterior. Guarda tu propia copia de lo que enviaste antes de enviarlo, para no depender de que la consola te lo muestre de nuevo.
¿El aviso de que se requieren más pruebas es una infracción de políticas contra mi cuenta?
La guía pública de Google no clasifica esta decisión de preparación como una infracción de política. Es una decisión sobre si la app está lista para producción, y la aplicación de políticas es un proceso independiente con sus propios avisos y remedios. Aun así, puede existir en paralelo un problema de políticas independiente, así que trata cualquier mensaje que mencione una infracción de políticas como lo que realmente es: algo distinto. No se encontró evidencia de que las decisiones repetidas de que se requieren más pruebas, por sí solas, lleven a la suspensión de la cuenta.
Conclusión
Resumen
La documentación pública actual de Google no describe un evento de reinicio universal que active toda denegación de "se requieren más pruebas". Su Centro de ayuda dice únicamente que a una app denegada se le puede exigir continuar con las pruebas, así que el propio mensaje de tu decisión es la instrucción más específica disponible: una variante reproducida ordena 14 días adicionales con testers reales, otra solo indica continuar las pruebas. Si no encuentras la tuya, recupérala en lugar de asumir cualquiera de las dos. Mantener en marcha la prueba cerrada existente es la opción por defecto de menor riesgo: una inferencia operativa, no una regla publicada de Google. Mantén al menos 12 testers aceptando participar durante 14 días continuos, nunca le pidas a nadie que salga y vuelva a unirse, y revisa las políticas, la clasificación, la fiabilidad y las credenciales de revisor junto con las pruebas en sí. La revisión normalmente tarda 7 días o menos, aunque en ocasiones tarda mucho más.
Si tu denegación sí mencionó otros 14 días, o tu grupo ya no tiene 12 testers que califiquen, esa parte de los testers es lo único de la recuperación que puedes delegar mientras te encargas del resto. Ver planes de precios →
Documentación oficial de Google
Mensajes de denegación reproducidos y evidencia de la comunidad
Estas son las dos reproducciones de la Comunidad de Desarrolladores de Google en las que se apoya este artículo. La redacción sin duración también se reportó de forma independiente en un foro turco de desarrolladores en abril de 2026. Ninguna de estas reproducciones es texto oficial de política, y esta página nunca las trata como algo más que eso.
Qué es lo primero de esta página que quedará desactualizado
- El texto de la denegación. Es el dato que más rápido caduca aquí, y sobre el que se construye toda la página. Ya difiere entre las reproducciones de 2024 y 2025. Si tu mensaje no coincide con ninguna de las dos variantes, tu mensaje gana.
- Las cifras de 12 testers y 14 días. Google ya cambió una vez el número de testers, de 20 a 12 el 11 de diciembre de 2024. Consulta la respuesta 14151465 antes de planear en torno a cualquiera de los dos números.
- Las secciones del cuestionario. Google puede cambiar lo que pregunta el formulario sin tocar la regla de elegibilidad, así que trata la lista de temas de aquí como vigente y no como permanente.
- El flujo de una nueva solicitud. No está documentado si las respuestas anteriores siguen siendo visibles o editables, lo que significa que también puede cambiar sin previo aviso.
- La estimación de siete días. Se publica como el caso habitual, no como un compromiso, y los casos atípicos de la comunidad en esta página muestran lo amplia que puede ser la espera.
Verificado con la documentación de Google Play el 17 de agosto de 2026. Se vuelve a comprobar cuando Google cambia la respuesta 14151465 o aparece una nueva variante de denegación.