No: nunca se reinicia
Actualiza con libertad; un build nuevo deja tu reloj de 14 días corriendoNo hay ninguna regla que diga que crear un release nuevo reinicia el reloj de la prueba cerrada. El requisito de 14 días se mide manteniendo al menos 12 testers con participación aceptada de forma continua: no tiene nada que ver con la versión de tu app, el versionCode ni cuántos builds subes.
Que tu conteo de testers con participación aceptada baje de 12.
Si los testers dejan de participar de forma formal y caes bajo el mínimo, la racha continua se rompe: no porque actualizaste, sino porque bajaste de 12.
Respuesta rápida
No: actualizar tu app durante la prueba cerrada (closed testing) de 14 días no reinicia el reloj, así que puedes enviar builds nuevos tantas veces como necesites. Subir un build nuevo (AAB) a tu canal de prueba cerrada existente no reinicia los 14 días. El reloj depende de mantener al menos 12 testers con participación aceptada de forma continua, no de la versión de tu app, el versionCode ni la clave de firma. Lo único que rompe la ventana continua es que tu conteo de testers con participación aceptada baje de 12 o que los testers dejen de participar de forma formal. Enviar updates es seguro, y Google de hecho lo fomenta. PrimeTestLab mantiene al menos 12 testers reales con participación aceptada de forma continua, para que tu reloj siga corriendo mientras envías correcciones.
Es uno de los miedos más comunes de la prueba cerrada: vas a mitad de tu ventana de 14 días, detectas un bug y te congelas, aterrado de que subir el arreglo borre tu progreso y te obligue a empezar las dos semanas de nuevo. No lo hará. El reloj de 14 días mira a tus testers, no a tus builds. Esta guía separa exactamente qué reinicia el timer de la prueba cerrada de qué no, te da dos herramientas interactivas para probar cualquier acción tú mismo y explica por qué enviar actualizaciones es algo que Google quiere ver de forma activa. Está actualizada al 30 de junio de 2026.
En esta guía
¿Actualizar mi app reinicia el reloj de 14 días de la prueba cerrada?
No. Es el miedo más común entre desarrolladores en su ventana de testing, y la respuesta tranquiliza: subir un app bundle nuevo a tu canal de prueba cerrada existente no reinicia el requisito de testing de 14 días de forma continua.
El reloj de 14 días está atado a tus testers, no a tu build. El requisito de Google se mide por si mantuviste al menos 12 testers con participación aceptada durante los últimos 14 días de forma continua. El número de versión de tu app, cuántas veces subes un AAB nuevo y qué cambias en las notas de la release simplemente no forman parte de ese timer.
Esta misma pregunta aparece una y otra vez en la comunidad de desarrolladores de Google Play: si crear un release nuevo para la prueba cerrada reinicia los 14 días, o si el contador se reinicia al actualizar la app. En lugar de citar respuestas de foros palabra por palabra que no pudimos verificar de forma independiente, esta guía se apoya en la documentación de ayuda de Play Console de Google, que define el requisito solo en términos de testers con participación aceptada y tiempo, nunca en términos de subidas de builds.
En las 7,400+ apps que hemos acompañado en este proceso, una actualización de build rutinaria al mismo canal cerrado, por sí sola, nunca reinició un reloj. ¿Dudas de una acción concreta? Usa el verificador de abajo: elige lo que estás a punto de hacer y te dice al instante si toca tu timer de 14 días.
¿Qué acción te preocupa?
Basado en el requisito publicado de Play Console de Google (testers con participación aceptada × días de forma continua) más experiencia amplía de desarrolladores. Los dos riesgos señalados por la comunidad están marcados como tales.
¿Qué reinicia de verdad el timer de 14 días?
La ventana de 14 días de forma continua se entiende mejor como un control de consistencia, no como una cuenta atrás pasiva del calendario. Google quiere ver que mantuviste al menos 12 testers con participación aceptada sin interrupción. Solo hay dos disparadores confirmados que rompen esa continuidad:
El conteo con participación aceptada baja de 12
Si aunque sea un tester deja de participar y caes a 11, la racha continua puede romperse y empiezas las dos semanas completas de nuevo. Esta es la razón número uno por la que fallan los desarrolladores DIY.
Los testers dejan de participar de forma formal
Un tester deja de participar abriendo el enlace web de la prueba y eligiendo salir. Eso es distinto de desinstalar, y solo daña el reloj si te deja bajo 12.
Subir un build nuevo no está en esa lista. Tampoco corregir un typo en la ficha, que un tester envíe feedback ni que tu app crashee en el dispositivo de un tester: eso último es justo el punto del testing. El simulador de abajo deja la diferencia en claro: pulsa el botón de update y no se mueve nada, pero si pierdes testers y bajas de 12 la racha se derrumba.
Qué NO reinicia el reloj
Subir un AAB nuevo al mismo canal
Editar notas de release o ficha de la tienda
Que un tester envíe feedback
Que tu app crashee en el dispositivo de un tester
Subir el versionCode o el nombre de versión
Que un tester desinstale sin dejar de participar
¿Cómo envío una actualización a una prueba cerrada?
Enviar un update es el mismo flujo que tu primer release, con una diferencia importante: creas el release nuevo en el mismo canal de prueba cerrada en el que tus testers ya aceptaron participar. No estás empezando una prueba nueva: estás sumando un build a la prueba que ya corre, y por eso el reloj de 14 días sigue ticando. Estos son los dos pasos en Play Console.
Crea un release nuevo en tu canal cerrado Testing > Closed testing > Manage track
Abre el canal de prueba cerrada que ya estabas corriendo, haz clic en Create new release y sube tu app bundle actualizado (AAB). Agrega notas de release cortas describiendo qué cambió y guarda. Quédate en el mismo canal: eso es lo que preserva tu ventana de 14 días de forma continua.
Revisa y lanza el update Review release > Start roll-out
Avanza con Next y Review release, luego inicia el roll-out a tu canal cerrado (y haz clic en Send changes for review en Publishing overview si te lo pide). Cuando el release nuevo esté en vivo (Google indica que un cambio publicado puede tardar varias horas en llegar a los testers), sus dispositivos se actualizan solos al build nuevo: sin reinstalar y sin aceptar participar de nuevo.
Esto nunca reinicia tu reloj. Como publicas en el mismo canal cerrado en el que tus testers ya aceptaron participar, la ventana de 14 días de forma continua sigue corriendo bajo el build nuevo. Estás sumando un build, no empezando una prueba nueva: esa es toda la respuesta a la pregunta en la que se basa esta guía.
¿Cuál es la diferencia entre testers invitados y con participación aceptada?
Esta distinción tropieza a más publicadores primerizos que cualquier otra, y es la clave para entender por qué los builds no importan al reloj. El sistema de Google mueve a los testers por un embudo, y solo las etapas posteriores pesan.
Invitado
Agregaste un correo a tu lista de testers o a un Google Group. Aún no pasó nada más.
Con participación aceptada
Hicieron clic en tu enlace de la prueba, iniciaron sesión con su cuenta de Google y eligieron Become a tester. Ese es el estado que mide el reloj de 14 días.
Instalado y activo
Descargaron la app y la siguen usando. Eso no cambia el conteo bruto, pero es lo que Google pesa para engagement al momento del acceso a producción.
Como deja claro la documentación de Google, agregar un correo no basta. Cada tester debe abrir el enlace de la prueba, autenticarse y aceptar participar de forma explícita antes de contar. Eso también explica por qué una actualización de la app nunca reinicia tu progreso: tus testers nunca salen del estado de participación aceptada, así que el reloj sigue corriendo en cada build nuevo. Para el recorrido completo, ve nuestra guía sobre cómo invitar testers de forma correcta.
Tip de gestionar miles de pruebas: corre tus testers con un Google Group en lugar de una lista de correos estática. Con un Group conectado a Play Console, metes o sacas un tester editando el Group: el enlace de la prueba se mantiene igual y el canal sigue corriendo. Eso elimina el riesgo de borrar por accidente testers activos al ajustar la lista, una de las pocas cosas que de verdad pueden romper tu racha.
¿Cuál es la redacción exacta del requisito de Google?
La página oficial de ayuda de Play Console de Google, "App testing requirements for new personal developer accounts", lo dice con precisión:
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Google Play Console Help · answer 14151465Y por separado, en el momento en que solicitas acceso a producción:
"At least 12 testers must be opted-in to your closed test when you apply for production access. They must have been opted-in for the last 14 days continuously."
Google Play Console Help · answer 14151465Google también deja en claro, con sus propias palabras, que los días deben ser consecutivos: no contará a testers que aceptaron participar, probaron menos de 14 días y luego dejaron de participar, y aunque vuelvan a aceptar, los 14 días consecutivos son los que cuentan. Esa sola cláusula mata por sí sola el mito de que "los 14 días son acumulativos" y, igual de importante, no dice nada sobre tus builds.
Tres hechos para fijar
¿Enviar actualizaciones durante el testing es bueno o malo?
Aquí la ansiedad del desarrollador se vuelve oportunidad. Enviar updates durante tu prueba cerrada se ve de forma amplia como una señal positiva de engagement. Conviene separar lo que Google dice de forma oficial de lo que concluyó la comunidad de desarrolladores, porque se solapan sin ser idénticos:
Sigue iterando y corrigiendo
La ayuda de Play Console fomenta la iteración continua: sigue usando la prueba cerrada mientras corriges problemas y bugs reportados por usuarios, y actualizar tu app en la prueba cerrada antes de ir a producción es "una gran forma de minimizar reseñas y valoraciones de baja calidad".
Cuando solicitas acceso a producción, el cuestionario te pide describir el engagement que recibiste y qué hiciste con el feedback de los testers.
Activo gana a congelado
Los practicantes van más lejos: una app congelada en la versión 1.0 durante 14 días con cero actividad parece testing de marcar casilla, mientras que una que envía updates en respuesta al feedback parece desarrollo genuino. Algunos desarrolladores empujan a propósito dos o tres updates pequeños para mostrar capacidad de respuesta.
Esto es consenso de la comunidad e inferencia razonable, no una regla publicada de Google. Google no fijó un requisito numérico de "envía X updates".
La conclusión: actualizar es seguro y se fomenta, y la historia de engagement que construyes con eso puede ayudarte a responder el cuestionario de acceso a producción. El único riesgo real viene de lo que envías, no del acto de enviar, y eso lleva a la única salvedad genuina.
¿Puede un update malo reiniciar mi reloj de forma indirecta?
Sí, y esta es la única salvedad que importa. Aunque el acto de actualizar nunca reinicia el timer de forma directa, las consecuencias de un update roto sí pueden. Sigue la cadena:
Así que la regla es simple: actualiza con libertad, pero revisa la estabilidad base de cada build antes de enviarlo a tu canal cerrado. Y nunca corras con exactamente 12 testers, porque un solo abandono por un build malo puede hundirte. Un colchón de testers por encima de 12 absorbe ese riesgo.
Lee la cadena con cuidado: el reinicio nunca lo causa el update. Lo causa bajar de 12 testers con participación aceptada. El build roto es solo lo que disparó los abandonos. Mantén tus builds estables y un colchón, y el riesgo indirecto también desaparece.
¿Los testers necesitan reinstalar o aceptar participar de nuevo tras un update?
No. Una vez que un tester aceptó participar e instaló tu app, Google maneja las actualizaciones de forma automática. No hay nada que deban clicar ni nada que tú debas reenviar.
Los updates se despliegan de forma automática
La ayuda de Play Console de Google, en Set up an open, closed, or internal test (answer 9845334), lo dice con claridad: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." Los testers siguen con la participación aceptada en cada build: sin reinstalar, sin un segundo clic para aceptar participar.
Un matiz de timing de esa misma página de Google: cuando publicas cambios adicionales, "pueden no estar disponibles para los testers durante varias horas" antes de que arranque la actualización automática en el dispositivo. Pero el estado de participación aceptada de los testers, que es lo que mide el reloj de 14 días, se mantiene en cada AAB nuevo. Justo por eso una actualización de build no reinicia el reloj: los testers nunca se fueron.
Excepción importante Los permisos nuevos pueden interrumpir el update silencioso
Hay un tipo de build que no siempre se despliega en silencio: un update que agrega un permiso peligroso (sensible) nuevo como ACCESS_FINE_LOCATION, cámara o micrófono. Según el permiso y tu target API level, Google Play puede mostrar un botón Update que el tester tiene que tocar y aprobar a mano en lugar de instalarlo en segundo plano, y quien lo ignore se queda en el build viejo. Incluso cuando se instala en silencio, el permiso nuevo solo se concede en runtime, así que una función condicionada al permiso puede verse rota hasta que el tester lo permita.
En una prueba cerrada eso es una trampa silenciosa: envía un update cargado de permisos el día 5 y tus números de testers activos pueden caer, la señal de engagement exacta que Google pesa al acceso a producción, porque la mitad de tus testers nunca vio el prompt. Un permiso de alto riesgo nuevo también puede disparar una revisión de declaración de permisos que retrasa la publicación del build por completo.
Antes de lanzar a mitad de prueba: compara los permisos del manifest nuevo con el build en vivo. Si el set de permisos cambió, avisa a tus testers para que abran Play Store y actualicen a mano (y concedan el prompt nuevo), y reserva margen por si hay revisión de declaración.
Mitos comunes de la prueba cerrada, desmentidos
La mayor parte del pánico alrededor de actualizar se reduce a un puñado de mitos. Estos son los cinco que más quitan el sueño a los desarrolladores, con lo que es verdad de verdad:
Mito 1"Crear un release nuevo reinicia el reloj."
Mito 2"Desinstalar es lo mismo que dejar de participar."
Mito 3"Los 14 días son acumulativos."
Mito 4"Exactamente 12 testers bastan."
Mito 5"Los testers deben usar la app todos los días."
Qué reinicia el reloj y qué no
Aquí está toda la pregunta en una sola pantalla. Guárdala, haz captura o envíasela a quien en tu equipo sigue preguntando. Todo lo atado a tu build es seguro; solo lo atado a tu conteo de testers no lo es.
| Acción | ¿Reinicia el reloj de 14 días? |
|---|---|
| Subir un AAB nuevo al mismo canal cerrado | No |
| Editar notas de release o metadatos de la ficha | No |
| Que un tester envíe feedback | No |
| Que tu app crashee en el dispositivo de un tester | No |
| Que un tester desinstale (sin dejar de participar) | No* |
| Que el conteo con participación aceptada baje de 12 | Sí |
| Que un tester deje de participar de forma formal por el enlace web | Sí** |
| Enviar un build roto que provoca abandonos bajo 12 | De forma indirecta |
| Pausar el canal de prueba cerrada | Riesgo reportado |
| Sobrescribir la lista de testers y omitir testers activos | Riesgo reportado |
* El timer técnicamente sigue, pero quien desinstala casi nunca vuelve a engancharse. ** Solo si te deja bajo 12. Las dos últimas filas son precaución reportada por la comunidad, no documentación confirmada de Google, así que trátelas como "no lo arriesgues" más que como reglas declaradas. Usar un Google Group evita por completo el riesgo de sobrescribir la lista.
Cómo cambió el requisito con el tiempo
Si estás leyendo tutoriales viejos, por eso los números no coinciden. La duración siempre fue 14 días de forma continua; solo se movió el conteo de testers.
Antes de noviembre de 2023 no había una prueba cerrada obligatoria para llegar a producción. Podías publicar sin reclutar testers.
Las cuentas personales creadas después del 13 de noviembre de 2023 debían correr una prueba cerrada con 20 testers con participación aceptada durante 14 días de forma continua. Las cuentas de organización estaban exentas.
El 11 de diciembre de 2024 el mínimo bajó de 20 a 12, con la duración de 14 días sin cambios. Las cuentas de organización siguen exentas.
Cualquier guía que todavía te diga que reclutes 20 testers está desactualizada. Cubrimos el cambio a fondo en qué cambió de 20 a 12 testers.
Cambios de política de 2026 que conviene conocer
La prueba cerrada no existe en el vacío. Unas pocas fechas de 2026 pueden cruzarse con tu timeline de lanzamiento: ninguna cambia cómo funciona el reloj de 14 días, pero pueden chocar con tu ventana si no miras el calendario:
Fechas 2026 que se cruzan con tu timeline
Fechas según la ayuda de Google Play Console (target API level) y el Android Developers Blog (verificación de desarrollador). El timing de la verificación es por fases y puede ampliarse en 2026-2027, así que confirma contra las páginas oficiales antes de planificar en torno a eso. Nuestra guía de requisitos de publicación 2026 sigue la lista completa.
Cómo PrimeTestLab mantiene tu reloj en marcha
Lo más difícil de la prueba cerrada no es entender las reglas: es mantener a 12 o más personas reales con participación aceptada y engagement durante 14 días seguidos mientras iteras. Eso es exactamente para lo que está construido PrimeTestLab. Aportamos testers en dispositivos reales, con participación aceptada, y te guiamos en el setup de Play Console para que el reloj arranque limpio y siga corriendo mientras envías correcciones. Ve nuestro servicio de prueba cerrada de Google Play para lo que incluye. Mantenemos una tasa de éxito de 99.9% en 7,400+ apps, con la prueba en línea en 4-6 horas.
Agregas a nuestros testers en Play Console, compartes la URL de la prueba y arranca tu reloj. Desde ahí puedes actualizar el build tantas veces como quieras: los testers siguen con la participación aceptada, así que la racha sigue corriendo por debajo. Si gestionas varios canales de pruebas (también llamados segmento de pruebas en la documentación de Google en español de LatAm), quédate en el mismo canal cerrado durante la racha.
+5% de tarifa de servicio · Repetición gratis o reembolso completo
La mayoría de desarrolladores elige más del mínimo de 12 testers justo para que un solo abandono, incluso uno causado por un build malo, no los baje de 12 y reinicie el reloj. Un colchón es el seguro más barato contra lo único que de verdad rompe tu racha.
Preguntas frecuentes
¿Puedo actualizar mi app en la prueba cerrada sin reiniciar los 14 días?
Sí. Subir un build nuevo a tu canal de prueba cerrada existente no reinicia la ventana de 14 días de forma continua. El reloj depende de mantener al menos 12 testers que hayan aceptado participar de forma continua, no de la versión de tu app. Los testers se actualizan solos y siguen con la participación aceptada, así que tu progreso se mantiene entre builds.
¿Qué es lo único que reinicia el reloj de la prueba cerrada?
La ventana de 14 días de forma continua se rompe cuando tu conteo de testers con participación aceptada baja de 12, o cuando los testers dejan de participar de forma formal y te dejan bajo el mínimo. Las actualizaciones de build, los cambios en la ficha y los crashes no lo reinician. Mantener un colchón de testers por encima de 12 es la forma más fiable de proteger la racha. En la documentación oficial de Google en español, a los testers también se les llama verificadores.
¿Cuál es la diferencia entre testers invitados y con participación aceptada?
Invitado significa que agregaste un correo a tu lista, y eso no cuenta para nada. Con participación aceptada significa que abrieron tu enlace, iniciaron sesión y eligieron "Become a tester": ese es el estado que mide el reloj de 14 días. Solo cuentan los testers que aceptaron participar, así que confirma siempre que completaron ese paso.
¿Los testers tienen que aceptar participar de nuevo después de una actualización?
No. Una vez que un tester acepta participar e instala, Google entrega tus updates de forma automática en minutos. No reinstalan ni vuelven a hacer clic en el enlace. Su estado de participación aceptada, que es lo que mide el requisito de 14 días, sigue sin cortes en cada build nuevo que envías al mismo canal cerrado.
¿Desinstalar es lo mismo que dejar de participar?
No. Un tester solo deja de participar de forma formal al abrir el enlace web de la prueba y elegir salir. Si solo desinstala, el timer técnicamente sigue corriendo. En la práctica, quien desinstala casi nunca vuelve, y eso puede debilitar el engagement que presentas al solicitar acceso a producción, así que igual conviene mantener a los testers activos.
¿Google quiere que envíe actualizaciones durante la prueba?
La documentación de Google recomienda seguir corrigiendo problemas en la prueba cerrada antes de producción y probar de forma habitual las actualizaciones futuras. El consenso de la comunidad va más lejos: trata las actualizaciones activas como una señal positiva de engagement frente a una app congelada que parece solo marcar la casilla. Google no publicó un número obligatorio de updates, así que itera de forma genuina, no por relleno.
¿Cuántos testers necesito de verdad para la prueba cerrada?
El mínimo de Google es 12 testers con participación aceptada durante 14 días de forma continua para cuentas personales creadas después del 13 de noviembre de 2023. Como un solo abandono puede bajarte de 12 y romper la racha, muchos desarrolladores corren con 20 a 25 testers de colchón. PrimeTestLab ofrece planes de 12, 20 y 25 testers desde $19.99.
Conclusión
Resumen
Actualizar tu app durante la prueba cerrada de 14 días es seguro, normal y se fomenta. El reloj se mide manteniendo al menos 12 testers con participación aceptada de forma continua, así que un build nuevo nunca lo reinicia por sí solo. Los riesgos reales son bajar de 12 testers con participación aceptada, que los testers dejen de participar de forma formal o enviar un build tan roto que los testers se vayan. Envía tus correcciones, itera con el feedback y protege tu conteo de testers con un colchón por encima del mínimo. Si quieres un reloj que simplemente no se rompa, PrimeTestLab mantiene de 12 a 25 testers reales con participación aceptada desde $19.99, con la prueba en línea en 4-6 horas. Ver planes de precios →