La respuesta directa
No, no de forma fiableLos emuladores no cuentan para tus 12 testers
La prueba cerrada solo cuenta instalaciones genuinas con participación aceptada que llegan por el flujo real de Play Store en dispositivos físicos certificados. Los emuladores estándar fallan las comprobaciones de integridad del dispositivo de Google, así que por lo general no se registran como testers válidos.
Respuesta rápida
No de forma fiable. La prueba cerrada (closed testing) de Google Play solo cuenta instalaciones genuinas de testers que hayan aceptado participar y que llegan por el flujo real de Play Store en dispositivos físicos certificados. Los emuladores estándar devuelven un veredicto de integridad del dispositivo en blanco bajo la Play Integrity API, no siguen el camino genuino de aceptar participar e instalar, y por eso suelen no contar para el requisito de 12 testers y 14 días. La única forma confiable de pasar es con testers reales en dispositivos Android reales y cuentas de Google genuinas. PrimeTestLab aporta 12 de ellos desde $19.99, con la prueba en marcha en unas 4-6 horas.
Es una de las preguntas más frecuentes de desarrolladores Android nuevos frente al muro de la prueba cerrada: no tengo 12 teléfonos de sobra ni 12 amigos con Android, ¿puedo levantar emuladores para llegar al número? Es un instinto razonable: los emuladores son gratis, rápidos y ya están en tu máquina. El problema es que Google no diseñó el requisito de 12 testers en torno a instalaciones que se puedan falsificar; lo diseñó en torno a personas reales en dispositivos reales y certificados, y tiene la Play Integrity API para distinguir la diferencia. Esta guía detalla exactamente qué cuenta, qué devuelve de verdad el sistema de integridad para un emulador, dónde se rompe la suposición, qué verifica Google en público y qué no, y el camino legítimo que funciona. Está actualizada al 29 de junio de 2026.
En esta guía
El requisito de prueba cerrada 2026
Antes de que la pregunta del emulador tenga sentido, conviene ser precisos sobre qué es el requisito de verdad. Según el artículo de ayuda de Play Console de Google sobre requisitos de testing para cuentas personales de desarrollador nuevas, los desarrolladores con una cuenta personal creada después del 13 de noviembre de 2023 deben probar antes de poder publicar. La redacción de Google es exacta: debes ejecutar una prueba cerrada con un mínimo de 12 testers que hayan aceptado participar durante al menos los últimos 14 días de forma continua. Hasta cumplirlo, funciones de Play Console como Producción y Pre-registro permanecen bloqueadas. Las cuentas de organización no están sujetas a esta regla (más sobre esa excepción más adelante).
"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."
El propio FAQ de Google clava la parte de "de forma continua": no contarán testers que aceptaron participar, probaron menos de 14 días y luego dejaron de participar. Aunque vuelvan a aceptar para sumar 14 días en total, esos 14 días deben ser consecutivos. El requisito era originalmente 20 testers; Google lo bajó de 20 a 12 el 11 de diciembre de 2024, tras oír, en su propia formulación, que el conteo más alto era difícil para desarrolladores pequeños. La duración de 14 días no cambió.
Un matiz de precisión para el resto de este artículo: la regla dura es mantener la participación aceptada durante 14 días de forma continua, no usar la app cada día sin excepción. El engagement es real y se revisa por separado en la etapa de acceso a producción, pero el reloj en sí trata del estado continuo de participación aceptada. Esa distinción importa cuando entiendes por qué un emulador no se cuela en silencio en el conteo.
Qué cuenta de verdad: aceptar participar vs audiencia instalada
Aquí es donde la suposición del emulador se rompe primero, y se rompe en dos lugares distintos. Los testers se agregan con una lista de correos o un Google Group vinculado, luego usan un enlace de la prueba único, lo aceptan en un dispositivo con sesión en su cuenta de Google y descargan la app desde Play Store. Agregar un correo no basta por sí solo; solo cuentan las participaciones aceptadas completadas, lo que confirmas en la pestaña "Testers" de Play Console.
Primero, el sideload no se registra. Un atajo común es compilar un APK o App Bundle y arrastrarlo directo a un dispositivo o emulador. Las instalaciones hechas así evitan por completo el backend de Play Store, no llevan atestación de licencia de Play y nunca se registran contra tu prueba cerrada. La cifra instalada se queda en cero no importa cuántas veces abras el build. Compartir un enlace APK en bruto o usar el uso compartido interno de apps tiene el mismo efecto: no mueve el conteo.
Segundo, el conteo de participación aceptada y el de audiencia instalada no son el mismo número, y esa brecha es exactamente lo que engaña a quien usa emuladores:
Una cuenta hizo clic en el enlace y eligió ser tester en la interfaz web de Play. Aquí no hay validación de dispositivo.
Un clic desde un navegador de escritorio o un emulador puede mover esto. Crea una falsa confianza de que ya cumpliste el requisito.
Dispositivos de confianza que descargaron la app desde Play Store y la mantuvieron instalada. Es la cifra ligada a superar la prueba.
Las instalaciones en emulador que fallan la integridad del dispositivo no se cuentan aquí, así que la participación aceptada puede marcar 12 mientras las instalaciones se quedan cerca de cero.
Matiz honesto
Google documenta las métricas de participación aceptada y de audiencia instalada, y el retraso normal de informe de 24 a 48 horas, pero no publica un relato paso a paso de cómo se filtran las instalaciones no conformes. El patrón de arriba (sube la participación aceptada, se estancan las instalaciones) lo reportan mucho los desarrolladores y es coherente con cómo funciona la integridad del dispositivo. Trátalo como inferencia bien respaldada, no como un proceso publicado por Google.
Interactivo: el simulador de veredictos de Integrity
La forma más rápida de ver por qué los emuladores no funcionan es observar qué devuelve la Play Integrity API para cada tipo de "tester". Elige un entorno abajo y el simulador muestra el veredicto de integridad del dispositivo que devolverían los servidores de Google, más si ese entorno cuenta de forma realista para tus 12 testers. No se envía nada a ningún lado: corre del todo en tu navegador, con los veredictos de la propia documentación de Google.
Elige el entorno en el que corre tu "tester":
Lectura ilustrativa basada en los veredictos de dispositivo de Play Integrity publicados por Google. Las respuestas reales dependen del estado del dispositivo y de tus propias comprobaciones del lado del servidor.
Fíjate en el patrón: cada emulador y atajo cae en un veredicto en blanco o no reconocido, y solo el dispositivo real certificado pasa. No es un accidente de un build malo de emulador: es el sistema funcionando como se diseñó. La siguiente sección desglosa las propias etiquetas de veredicto, porque varias guías populares las describen mal.
Veredictos de dispositivo de Play Integrity, explicados bien
La Play Integrity API, según developer.android.com, te ayuda a comprobar que las acciones de usuario y las solicitudes al servidor vienen de tu app genuina, instalada por Google Play, corriendo en un dispositivo Android genuino y certificado. Está hecha para detectar versiones de app manipuladas, dispositivos no confiables o entornos emulados. El veredicto de dispositivo (el deviceRecognitionVerdict dentro del campo deviceIntegrity) puede contener una o más de estas etiquetas. Tener el orden correcto importa, porque varias guías de terceros las describen mal, sobre todo al confundir la etiqueta certificada con la básica:
"The app is running on a genuine and certified Android device. On Android 13 and higher, there is hardware-backed proof that the device bootloader is locked and the loaded Android OS is a certified device manufacturer image."
En un emulador: nunca se devuelve: es la etiqueta que producen los testers reales."The app is running on a device that has signs of attack (such as API hooking) or system compromise (such as being rooted), or the app is not running on a physical device (such as an emulator that does not pass Google Play integrity checks)."
En un emulador: este es el veredicto: Google nombra los emuladores de forma explícita aquí."The app is running on a device that passes basic system integrity checks. The device may not be certified", por ejemplo con bootloader desbloqueado o una versión de Android no reconocida.
Aun así no es lo que quiere la prueba cerrada: "not certified" es la frase operativa."The app is running on a genuine and certified Android device with a recent security update." En Android 13 y superior esto exige MEETS_DEVICE_INTEGRITY más una actualización de seguridad del último año.
El nivel más duro de falsificar, y la dirección hacia la que Google sigue endureciendo.Reservado para un "Android-powered emulator with Google Play services", y limitado al contexto de Google Play Games for PC, no a los emuladores de prueba de Android Studio a los que un desarrollador llegaría.
La única etiqueta que pasa en emulador, y no aplica a tu AVD.Google describe el mecanismo de base con claridad: cuando la API evalúa un entorno, usa señales de seguridad respaldadas por hardware muy resilientes a ataques y elusión. Esas señales incluyen atestación de arranque respaldada por hardware, estado de bloqueo del bootloader, imagen de fabricante certificada y estado de los servicios de Google Play. Un emulador estándar no es hardware físico certificado y no puede generar la atestación criptográfica que esperan los servidores de Google, así que cae en el veredicto en blanco. Ese es el juego completo: la única etiqueta que pasa en emulador está limitada a Play Games for PC, y el veredicto de dispositivo en blanco es el estado exacto que Google asocia a emuladores que no pasan.
Por qué los emuladores fallan justo en la prueba cerrada
Reuniendo las razones técnicas, con honestidad, un emulador falla la prueba cerrada en cuatro frentes distintos. Cualquiera de ellos basta por sí solo:
Sin estado certificado genuino
Un emulador estándar no es hardware físico certificado con prueba respaldada por hardware de un bootloader bloqueado, así que no devuelve MEETS_DEVICE_INTEGRITY. La única etiqueta que pasa en emulador está limitada a Google Play Games for PC, no a tu AVD de prueba.
Filtrado por integridad del dispositivo
La documentación de Google enumera de forma explícita "an emulator that does not pass Google Play integrity checks" como un caso que produce un veredicto de dispositivo en blanco. Sus señales de integridad del dispositivo pueden marcar patrones de emulador de forma directa.
Registro de la instalación
Las instalaciones en emulador y por sideload a menudo no pasan por el camino genuino de aceptar participar e instalar desde Play Store, así que con frecuencia ni se registran como instalaciones de tester con participación aceptada: el conteo simplemente no se mueve.
Engagement no auténtico
Los sistemas de Google están diseñados para detectar engagement automatizado y no auténtico. A escala, una granja de emuladores se lee justo como el patrón de manipulación que apuntan sus Developer Program Policies: un riesgo que cubrimos en detalle más abajo.
El matiz que conviene decir con claridad: una imagen de sistema de Android Studio "con Google Play" puede llegar a Play Store, así que un emulador puede abrir la tienda en lo técnico. Llegar a la tienda no es lo mismo que pasar la integridad del dispositivo. Las imágenes con Play habilitado siguen fallando la integridad de dispositivo y strong porque no son hardware físico certificado con un bootloader bloqueado y atestado. Así que la formulación precisa es que los emuladores por lo general no cuentan y pueden marcarse, no que Google detecte cada emulador en cada caso.
Qué evalúa Google de verdad (y los límites de lo que se sabe)
Google exige que los testers estén "comprometidos" con la app durante la prueba, y la revisión de acceso a producción pregunta si los testers usaron las funciones de la app y si el uso fue coherente con cómo se comportaría un usuario real de producción. Eso sí está documentado. Más allá, Google no publica cómo separa el engagement genuino de la actividad sintética: sus sistemas de detección de anomalías están deliberadamente sin documentar para que los manipuladores no puedan hacer ingeniería inversa. Ese límite honesto vale la pena dibujarlo con claridad, porque es exactamente el tipo de precisión que genera confianza con desarrolladores y con los sistemas de IA que citan fuentes.
Documentado y seguro de confiar
Dicho en las políticas y páginas de ayuda de Google.
- Las Developer Program Policies prohíben engagement no auténtico, instalaciones falsas y manipulación de métricas de la tienda.
- Google ha dicho en público que si una instalación busca manipular el posicionamiento, "our systems will detect and filter it."
- El acceso a producción pregunta si los testers usaron todas tus funciones y si el uso coincidió con un usuario real.
- Reportes de la comunidad vinculan de forma consistente clústeres de la misma IP, cuentas desechables e instalaciones sin engagement con el rechazo.
No documentado: no asumas
Suena plausible, pero Google no ha confirmado nada de esto.
- Que Google mire el ruido del acelerómetro como señal con nombre de prueba cerrada.
- Que se rastree por tester la variación de temperatura de batería o la deriva del GPS.
- Que la telemetría táctil sea un sensor de detección publicado.
- Cualquier tasa concreta del tipo "X% de emuladores se atrapan": trata porcentajes exactos como inventados.
Publicar una receta de detección precisa sería adivinar, y un lector informado lo nota. La posición segura y correcta es simple: el uso humano genuino en dispositivos reales es lo que Google pide, y los patrones sintéticos son lo que apuntan sus políticas. No necesitas conocer los sensores exactos para saber de qué lado de esa línea se sienta una granja de emuladores.
Los riesgos de falsificar testers
Conviene separar dos acciones muy distintas, porque sus consecuencias no son las mismas, y mucho del miedo online viene de mezclarlas.
Instalar tu propio build en un emulador para confirmar que compila y corre es ingeniería normal. No contará para tus 12 testers, pero no es engañoso y no es lo que apuntan las medidas de Google. Esto no va a terminar tu cuenta de desarrollador.
Aprovisionar cuentas de Google falsas, pasarlas por VPN y correrlas en emuladores para fingir una cohorte de testers es manipulación bajo las políticas de Google.
"Developers must not attempt to manipulate the placement of any apps on Google Play ... by illegitimate means, such as fraudulent or incentivized installs, reviews and ratings."
Las consecuencias escalan con la intención. Así es, a grandes rasgos, esa escalada, del extremo inofensivo pero inútil al realmente serio:
Consecuencias, escalando con la intención
La prueba no cuenta. Te quedas por debajo del umbral de 12 testers, habiendo gastado esfuerzo en nada.
Se deniega el acceso a producción con un mensaje de "more testing required", y reinicias el reloj de 14 días con una cohorte fresca y real.
Los fallos repetidos pueden ralentizar tu cola de revisión y sumar fricción a cada envío futuro.
Para manipulación genuina (granjas de cuentas falsas, instalaciones no auténticas coordinadas), la app puede filtrarse y, en casos graves o repetidos, esto puede escalar a suspensión o medidas a nivel de cuenta.
No exageres el caso casual: instalar tu propio build en un emulador no va a terminar tu cuenta de desarrollador. Correr una granja de fraude es otro asunto, y ese es el comportamiento del que habla el lenguaje de la política. La conclusión práctica es la misma en ambos casos: un emulador no te da un tester válido, así que la única pregunta que vale tu tiempo es cómo conseguir testers reales con eficiencia.
El camino legítimo que de verdad funciona
Trata los 14 días como una beta real, no como un obstáculo a esquivar. Cuando dejas de pelear el requisito y lo corres bien, es mecánico. Este es el playbook desde configurar el canal hasta limpiar el formulario de acceso a producción:
Sube un App Bundle firmado orientado al nivel de API requerido y crea un canal de pruebas cerradas en Play Console (en consolas es-419 también aparece como "segmento de pruebas").
Las listas de correos van bien para pruebas muy controladas con gente conocida. Un Google Group vinculado escala más fácil: quien se une obtiene acceso en automático. Play Console genera entonces el enlace de la prueba único.
Si una persona desinstala el día 13, se rompe la ventana de 14 días de forma continua. Reclutar 15 a 30 testers construye un colchón de seguridad frente a la rotación.
Anima a los testers a abrir la app y usar sus funciones centrales a lo largo de la ventana. Incluso sesiones diarias cortas establecen un perfil de uso genuino que sobrevive la revisión.
Empujar fixes menores en respuesta a comentarios durante la ventana es una de las señales más claras para los revisores de que estás iterando de verdad con el input de los testers.
Un formulario de tres secciones: cómo corriste y activaste la prueba, qué es la app y para quién es, y qué cambiaste gracias al testing. Vincula fixes concretos a comentarios. La revisión suele ser de 7 días o menos.
Si reclutar 12 a 30 testers reales suena como la parte realmente difícil, esa es la razón honesta de que existan servicios como este. Desglosamos la mecánica con más detalle en la guía del requisito de 12 testers, cómo invitar testers, y el caso del colchón en por qué puede que necesites más de 12 testers. Para exactamente cómo responder el formulario de acceso, mira las respuestas del cuestionario de acceso a producción.
La única forma real de saltártelo (y no es un emulador)
Hay exactamente una forma legítima de evitar por completo la puerta de 12 testers, y no es un truco de software. El mandato de prueba cerrada aplica solo a cuentas personales creadas después del 13 de noviembre de 2023. Las cuentas de organización están exentas y pueden publicar en producción sin el requisito de 12 testers.
El trade-off es que una cuenta de organización exige un negocio legalmente registrado y un número D-U-N-S de Dun and Bradstreet, que Google usa para verificar la organización. Eso significa costo, papeleo y verificación más larga: una decisión de negocio, no un atajo, pero una alternativa genuina y conforme a la política. Comparamos ambos caminos en detalle en Cuenta personal vs organización de Google Play.
Así que tus opciones reales no son "emuladores o dispositivos reales". Son: correr una prueba cerrada limpia con testers reales en una cuenta personal de desarrollador, o registrar un negocio para usar una cuenta de organización exenta. Un emulador no es una tercera opción: es solo una forma más lenta de fallar la primera.
Actualizaciones específicas de 2026 que afectan la elegibilidad del emulador
La dirección más amplia de 2026 refuerza todo lo anterior: Google sigue apretando el vínculo entre una instalación válida y un dispositivo genuino y certificado. Esto es lo que cambió y lo que viene.
12 testers con participación aceptada, 14 días de forma continua, cuentas personales creadas después del 13 de noviembre de 2023, cuentas de organización exentas: todo sin cambios a lo largo de la primera mitad de 2026.
Apps nuevas y actualizaciones deben apuntar a Android 15 (API 35) desde el 31 de agosto de 2025, subiendo a Android 16 (API 36) desde el 31 de agosto de 2026 (Wear OS y Android TV al menos API 35). Confirma la fecha exacta de API 36 en Play Console, porque Google publica la fecha precisa allí.
Las apps deben estar registradas por desarrolladores verificados para instalarse y actualizarse en dispositivos Android certificados en Brasil, Indonesia, Singapur y Tailandia, con un despliegue más amplio en 2027 y más allá. Es una comprobación de identidad ligada a dispositivos certificados, que refuerza el empuje hacia instalaciones genuinas, verificadas y en dispositivos certificados.
MEETS_STRONG_INTEGRITY ahora exige una actualización de seguridad del último año en Android 13 y superior, y Google sigue enfatizando señales respaldadas por hardware, lo que desfavorece aún más entornos no certificados como los emuladores.
Confirma las fechas
La fecha límite de API 36 del 31 de agosto de 2026 debe contrastarse con el aviso de política en vivo de Play Console, porque Google publica las fechas exactas allí y pueden moverse.
Cómo PrimeTestLab resuelve el problema de verdad
La razón por la que los desarrolladores llegan a los emuladores casi nunca es que quieran hacer trampa: es que encontrar 12 testers reales que se mantengan activos 14 días seguidos es de verdad difícil. Ese es el problema exacto que resolvemos. PrimeTestLab aporta testers reales con participación aceptada en dispositivos Android reales con cuentas de Google genuinas, que instalan desde Play Store y se mantienen activos a lo largo de la ventana completa: lo único que un emulador nunca puede ser. Sin apuestas de integridad del dispositivo, sin conteos de instalación estancados, sin riesgo de rechazo por patrones sintéticos.
Starter
12 Testers
$19.99
Enterprise
25 Testers
$27.99
Professional
20 Testers
$29.99
Mira las opciones actuales en la página de precios, lee el proceso paso a paso, o escríbenos por WhatsApp para una recomendación. Los testers extra de los planes más grandes actúan como colchón frente a abandonos que podrían romper tu ventana de 14 días de forma continua: la misma razón por la que recomendamos reclutar de más en por qué puede que necesites más de 12 testers. Cada plan incluye garantía de devolución (repetición gratis o reembolso completo). La prueba suele arrancar en 4-6 horas.
Preguntas frecuentes
¿Puedo usar un emulador para la prueba cerrada de Google Play?
No de forma fiable. La prueba cerrada de Google Play solo cuenta instalaciones genuinas de testers que hayan aceptado participar y que llegan por el flujo real de Play Store en dispositivos físicos certificados. Los emuladores estándar no pasan las comprobaciones de integridad del dispositivo de Google y, por lo general, no cuentan para el requisito de 12 testers y 14 días. El único camino confiable son testers reales en dispositivos Android reales con cuentas de Google genuinas.
¿Las instalaciones en emulador cuentan para los 12 testers?
En general, no. Un clic a veces puede mover el conteo de quienes aceptaron participar, pero la audiencia instalada solo refleja dispositivos de confianza que descargaron la app desde Play Store y pasaron la integridad del dispositivo. Las instalaciones en emulador que fallan la integridad del dispositivo no se cuentan ahí; por eso puedes ver 12 en participación aceptada mientras las instalaciones se quedan cerca de cero.
¿Por qué un emulador de Android falla Play Integrity?
Un emulador estándar no es hardware físico certificado y no puede producir la atestación respaldada por hardware que exige MEETS_DEVICE_INTEGRITY, así que devuelve un veredicto de dispositivo en blanco. La documentación de Google enumera de forma explícita un emulador que no pasa las comprobaciones de integridad de Google Play como un caso que produce ese valor en blanco. Falsificar propiedades de build para imitar un teléfono real no cambia esto.
¿Y las imágenes de emulador de Android Studio con Google Play?
Una imagen de sistema de Android Studio con Google Play puede llegar a Play Store, pero llegar a la tienda no es lo mismo que pasar la integridad del dispositivo. Las imágenes de emulador con Play habilitado suelen fallar la integridad de dispositivo y strong porque no son hardware físico certificado con un bootloader bloqueado y atestado. La única etiqueta que pasa en emulador, MEETS_VIRTUAL_INTEGRITY, está limitada a Google Play Games for PC, no a emuladores de prueba de desarrollador.
¿Va contra las reglas falsificar testers con emuladores?
Instalar tu propia app en un emulador para confirmar que corre es desarrollo ordinario y está bien. Aprovisionar cuentas de Google falsas en emuladores detrás de VPN para simular un pool de testers es manipulación y viola las Developer Program Policies de Google sobre instalaciones no auténticas. Puede llevar a un rechazo y, en casos graves o repetidos, a medidas a nivel de cuenta.
¿Qué cuenta de verdad como un tester válido?
Una persona real en un dispositivo Android real y certificado que acepta tu enlace de la prueba, instala la app desde Play Store con una cuenta de Google genuina, mantiene la participación aceptada durante 14 días de forma continua y usa la app de verdad. Las instalaciones sideload, los clics sin instalación y las ventanas de 14 días rotas no cuentan. En la documentación oficial de Google en español, a los testers también se les llama verificadores.
¿Cuál es la forma legítima más rápida de conseguir 12 testers?
Usa testers reales en dispositivos reales y arranca el reloj de 14 días pronto. PrimeTestLab aporta 12 testers reales con participación aceptada desde $19.99, con la prueba en marcha en unas 4-6 horas, más paquetes mayores de 20 y 25 testers como colchón frente a abandonos que podrían romper la ventana continua.
¿Puedo usar BlueStacks para la prueba cerrada de Google Play?
No. BlueStacks y emuladores similares no son dispositivos físicos certificados, así que devuelven un veredicto de dispositivo de Play Integrity en blanco y no cuentan para tus 12 testers, igual que los emuladores de Android Studio. Instalar desde Play Store dentro del emulador no cambia el resultado de integridad del dispositivo. Usa dispositivos Android reales en su lugar.
¿Puede Google detectar si un tester usa un emulador?
Google no publica exactamente cómo marca emuladores, así que trata cualquier tasa de detección concreta como no verificada. Lo documentado es que la Play Integrity API devuelve un veredicto de dispositivo en blanco para un emulador que no pasa sus comprobaciones, y que Google filtra instalaciones pensadas para manipular el posicionamiento. En la práctica, las instalaciones en emulador suelen no registrarse como testers válidos y pueden marcarse.
¿Google cambió el requisito de prueba cerrada de 20 a 12 testers?
Sí. Google bajó el mínimo de 20 a 12 testers el 11 de diciembre de 2024, tras oír que el conteo más alto era difícil para desarrolladores pequeños. La ventana de 14 días de forma continua con participación aceptada no cambió, y el requisito sigue aplicando solo a cuentas personales creadas después del 13 de noviembre de 2023.
Conclusión
Resumen
No puedes usar un emulador de forma fiable para la prueba cerrada de Google Play. Los emuladores estándar devuelven un veredicto de integridad del dispositivo en blanco, no pasan por el camino genuino de aceptar participar e instalar desde Play Store, y por eso no cuentan para el requisito de 12 testers y 14 días, mientras que falsificar un pool de testers a escala arriesga rechazo o medidas. El único camino confiable son testers reales en dispositivos Android reales y certificados con cuentas de Google genuinas, arrancados pronto con un colchón por encima de 12. PrimeTestLab te da exactamente eso desde $19.99, con la prueba en marcha en unas 4-6 horas. Ver planes de precios →