La versión corta
¿Puede un emulador contar para los 12 testers?El requisito habla de testers y de participación continua, no de un tipo de dispositivo
Usa un emulador para probar tu app. No uses emuladores para fabricar a los participantes de tu prueba cerrada. El requisito publicado por Google es de 12 testers con participación aceptada durante 14 días continuos, y ni los requisitos ni la documentación técnica revisados para esta guía especifican si la participación desde un emulador cuenta para ese mínimo. Nuestra propia recomendación, tras ejecutar estas pruebas para desarrolladores, es más firme de lo que la documentación necesita ser: ejecutar tu compilación en un emulador es desarrollo habitual y está perfectamente bien; poner instancias de emulador en lugar de las doce personas no es un atajo que nosotros tomaríamos; y crear cuentas de Google falsas para aceptar participar desde ellas es manipulación y, según nuestra experiencia, el tipo de prueba que se devuelve o se rechaza. Revisa tu progreso en Play Console y recluta personas que usen la app y te cuenten qué encontraron.
| La pregunta | Qué lo decide | Dónde se responde |
|---|---|---|
| ¿Puede un emulador ejecutar mi app y ayudarme a probarla? | La imagen del sistema que elijas y la propia app. | La documentación del emulador de Android Studio. Para eso existe la herramienta. |
| ¿Puede un tester abrir mi compilación de prueba cerrada en uno? | La cuenta de Google, si se aceptó la participación, la versión publicada y las restricciones que hayas configurado. | La configuración de la prueba en Play Console: elegibilidad de la cuenta, disponibilidad de la versión, compatibilidad y las comprobaciones de dispositivo que hayas configurado. |
| ¿Qué informa Play Integrity sobre él? | El estado del dispositivo, la versión de Android y los campos que leen tu propia app o tu backend. | La documentación de Play Integrity. Responde a tu propia app y a tu backend; Play Console lo informa por separado. |
| ¿Esa persona cuenta para los 12? | Si un tester tiene la participación aceptada en tu prueba cerrada, de forma continua, durante 14 días. | El requisito de pruebas, que no dice nada sobre el tipo de dispositivo ni sobre la integridad. |
En esta guía
Qué exige Google y a quién se aplica
Requisito de GoogleLa ayuda de Play Console indica que un desarrollador con una cuenta personal creada después del 13 de noviembre de 2023 debe realizar una prueba cerrada antes de publicar en producción, con un mínimo de 12 testers con participación aceptada de forma continua durante al menos 14 días (requisitos de pruebas para apps). Hasta que se cumpla, Producción y Registro previo permanecen bloqueados. Cumplirlo te habilita para solicitar el acceso; la aprobación es una revisión aparte. Las cuentas de organización no están sujetas a la regla. El requisito en sí se desglosa en el requisito de 12 testers explicado.
Para una cuenta personal de desarrollador creada después del 13 de noviembre de 2023, la app necesita una prueba cerrada con al menos 12 testers con participación aceptada de forma continua durante 14 días antes de que el desarrollador pueda solicitar acceso a producción.
Google también explica qué significa de forma continua. Los testers que aceptan participar, prueban durante menos de 14 días y luego dejan de participar no cuentan para el requisito, y si alguien vuelve a participar más adelante, los 14 días siguen teniendo que ser consecutivos. El mínimo era de 20 hasta que Google lo redujo a 12 el 11 de diciembre de 2024, un cambio que añadió a su anuncio de 2023. La duración de 14 días no cambió.
Lee el requisito tal como está escrito: se trata del estado de participación
Fíjate en qué sustantivos usa el requisito y cuáles no. Habla de testers y de participación continua, no de un modelo de dispositivo, un estado de certificación ni un veredicto de integridad. De ahí salen dos malentendidos. Desinstalar no es la misma acción que dejar de participar, así que una desinstalación no rompe automáticamente la ventana. Y que una persona se vaya no reinicia a las demás: la continuidad se registra por cada inscripción.
La verificación del dispositivo del desarrollador es otra tarea distinta
Google sí exige un dispositivo Android físico en un punto concreto, y es fácil confundirlo con una regla sobre testers. Las cuentas personales de desarrollador nuevas deben completar la verificación del dispositivo en un dispositivo Android físico sin root, con Android 10 o superior, con la sesión iniciada como titular de la cuenta (requisitos de verificación del dispositivo). Google indica que es posible que te pidan verificar de nuevo más adelante, aunque no necesariamente en el mismo dispositivo. En cualquier caso, es el titular de la cuenta demostrando que tiene acceso a un dispositivo, y no dice nada sobre lo que usan tus testers.
¿El requisito se aplica en tu caso?
Se aplica a las cuentas personales creadas después del 13 de noviembre de 2023. Las cuentas personales más antiguas y las cuentas de organización quedan fuera, así que «consigue una cuenta de organización» es una diferencia de elegibilidad, no un truco ingenioso. Una cuenta de organización necesita una organización registrada que Google verifica, normalmente con un número D-U-N-S, que puede solicitarse sin costo. Comparamos ambas en cuenta personal vs. cuenta de organización en Google Play.
¿Los emuladores cuentan para los 12 testers?
Nada en la documentación revisada aquí responde eso con un sí o un no, y por eso el resto de esta guía separa lo que está establecido de lo que se infiere. Las afirmaciones caen en una de cuatro categorías, y el error habitual es ascender discretamente una afirmación de una categoría inferior a otra superior.
Una regla que debes cumplir: 12 testers, 14 días continuos, el corte del 13 de noviembre de 2023 y que cumplirla te permite solicitar el acceso.
Descripciones precisas del comportamiento: veredictos de integridad, imágenes del sistema, configuración de la prueba. Escritas con un propósito distinto al de decidir quién cuenta.
Hilos en la Comunidad de desarrolladores de Google Play y en Reddit. La respuesta recomendada en el hilo que citamos aconseja usar a otras personas en dispositivos Android físicos en lugar de emuladores. Vale la pena leerla, pero la página advierte que el contenido puede no estar verificado, y un nombre de host de Google no es política.
Nuestro propio criterio: recluta por encima del mínimo y no fabriques participación con emuladores ni cuentas falsas. Un consejo que nace de hacer este trabajo, no una regla, y vendemos ayuda con las pruebas.
Documentado y seguro de citar
Establecido en las políticas, las páginas de ayuda o la documentación para desarrolladores de Google.
- El requisito en sí: 12 testers con participación aceptada durante 14 días continuos, para cuentas personales creadas después del 13 de noviembre de 2023.
- La solicitud de acceso a producción pregunta cómo se desarrolló la prueba, qué es la app y qué cambiaste a raíz de las pruebas.
- Las Políticas del Programa para Desarrolladores prohíben manipular el posicionamiento, las calificaciones, las reseñas o las cifras de instalaciones por medios ilegítimos.
- Google recomienda probar en hardware físico antes del lanzamiento, y documenta las pruebas en emulador en distintas versiones y tamaños de pantalla.
No especificado: no lo des por sentado
Suena plausible, y está ausente de la documentación revisada aquí.
- Que un veredicto de Play Integrity decida si un tester cuenta para los 12.
- Cualquier señal de detección con nombre propio: ruido del acelerómetro, variación de la temperatura de la batería, deriva del GPS, telemetría táctil, agrupación de IP o antigüedad de la cuenta.
- Cualquier cifra concreta del tipo «se detecta el X % de los emuladores». Trata los porcentajes exactos como afirmaciones sin sustento, no como mediciones.
- Un retraso universal en los informes, un número obligatorio de sesiones diarias o un número obligatorio de actualizaciones durante la ventana.
Testers con participación aceptada, audiencia instalada y acceso a producción
Gran parte de esta discusión gira en realidad en torno a tres números de Play Console que se tratan como si fueran intercambiables. No lo son.
| Qué estás viendo | Qué significa | Qué no te dice |
|---|---|---|
| Testers con participación aceptada | Cuentas que aceptaron el vínculo de participación de este segmento. Es el sustantivo en torno al cual está escrito el requisito, junto con cuánto tiempo se mantienen participando. | Si alguien instaló la app, la abrió o te dio comentarios útiles. |
| Audiencia instalada | Google la define como los usuarios que tienen tu app instalada en al menos un dispositivo que usaron en los últimos 30 días. El dispositivo tiene que haberse usado; la app, no necesariamente. | Es una métrica de audiencia, no el contador del acceso a producción ni un recuento de dispositivos que pasaron una comprobación de seguridad. |
| La lista de verificación del acceso a producción | El elemento del Panel que indica cuántos testers han aceptado participar y durante cuántos días continuos. Sobre esto se mide el requisito. | Por qué una persona concreta está o no está incluida. Para eso, revisa la inscripción. |
Cumplir el mínimo no es lo mismo que una prueba convincente. Google puede pedir más pruebas cuando la participación de los testers no es suficiente, incluso después de que 12 testers hayan aceptado participar durante 14 días continuos. No publica ninguna cuota de sesiones diarias, así que la meta es una prueba que produjo uso real y comentarios reales, no actividad fabricada para aparentar movimiento.
Instalar fuera de Play es un camino aparte, y no inscribe a nadie. Un Android App Bundle es un formato de publicación, no un archivo instalable, así que lo que se instala de esa manera es un APK generado a partir de él. Y sin importar cómo llegue el archivo (una instalación manual, un enlace compartido, el uso compartido interno de apps), no acepta tu vínculo de participación en nombre de nadie.
Una brecha entre dos de estos números es un síntoma, no un diagnóstico. Doce participaciones aceptadas con una audiencia instalada baja tienen explicaciones corrientes: la gente aceptó participar y nunca instaló, instaló en un dispositivo que no ha usado últimamente, los informes van con retraso o la versión no está disponible para ellos.
Qué podemos decirte aquí y qué no
Google publica el requisito de pruebas y las definiciones de estas métricas, pero no una explicación de cada resultado individual del conteo ni un retraso universal en los informes. Lee la documentación de la métrica concreta, mantén separado un retraso observado de una garantía publicada y recorre la lista de comprobaciones de más abajo.
Si un tester no encuentra o no puede instalar tu compilación de prueba cerrada
Revisa estos problemas de configuración antes de atribuir el problema al entorno. Se aplican por igual a dispositivos físicos y emuladores.
-
01
La cuenta de Google equivocada
La cuenta que aceptó el vínculo de participación debe ser la que tiene la sesión iniciada en el dispositivo y la seleccionada en la Play Store. En un teléfono con varias cuentas de Google, revisa eso primero cuando alguien reporte «la app no está disponible».
-
02
La participación nunca se completó
Tu lista de correos o el Grupo de Google vinculado hacen que alguien sea elegible; no lo inscriben. Esa persona todavía tiene que abrir el vínculo de participación y aceptarlo, y la pertenencia al grupo puede tardar un poco en hacerse efectiva. Una compilación de prueba cerrada tampoco aparece en la búsqueda de la Play Store, así que los testers llegan a ella por el vínculo de participación y el enlace a la tienda que les das.
-
03
Un segmento en conflicto
Si la cuenta también está en tu prueba interna, pídele a esa persona que abandone esa prueba antes de aceptar participar en la cerrada. Cuando los segmentos se superponen, un usuario elegible recibe el código de versión compatible más alto que tenga disponible, que puede no ser la versión que estás observando (configuración de la prueba).
-
04
No hay una versión activa en ese segmento
Un segmento cerrado necesita una versión publicada que realmente se haya desplegado, con la versión y el porcentaje que crees que tiene. Un borrador no se distribuye a nadie. Un lanzamiento detenido frena la distribución posterior, pero los testers que ya recibieron esa versión pueden seguir teniéndola instalada, así que revisa qué versión se está entregando. Google también señala que un vínculo de prueba nuevo, y los cambios posteriores que le hagas, pueden tardar unas horas en estar disponibles.
-
05
Tus propios ajustes de disponibilidad
La disponibilidad por país y las restricciones de dispositivo las configuras tú. Para los países, Google lee el país de la cuenta de Google Play del tester, que no siempre es el lugar donde está sentado. Y si activaste las comprobaciones de dispositivo basadas en integridad de la ficha de Play Store, pueden impedir que algunos dispositivos vean o instalen la app: una restricción de acceso que configuraste tú, no una prueba de qué testers cuentan.
-
06
El entorno o la propia compilación
Solo después de los cinco anteriores. Un emulador con la imagen del sistema equivocada no puede iniciar sesión en la Play Store en absoluto, y Android Studio publica problemas conocidos de imágenes concretas.
-
07
Es tu app la que lo bloquea, no la Store
Si la descarga funciona y luego la app se niega a ejecutarse, eso es una restricción tuya, no de la disponibilidad en Play. Revisa qué hacen tu app o tu backend con la respuesta de Play Integrity antes de concluir que el tester no puede obtener tu compilación.
Si el conteo sigue pareciendo incorrecto, tenemos guías dedicadas: testers añadidos pero cero con participación aceptada, la app no está disponible para un tester y acceso de testers mediante Grupos de Google. Cada una cubre las causas de configuración más comunes y las comprobaciones adicionales que conviene hacer.
Cuándo ayudan las pruebas en emulador
Los emuladores son buenos, y Google construye uno. Viene incluido en Android Studio, y Google recomienda probar en distintas versiones de Android y tamaños de pantalla. El error no es usar un emulador; es esperar que haga un trabajo para el que nunca fue pensado.
Recomendación de PrimeTestLabIteración rápida mientras desarrollas. Versiones de Android y tamaños de pantalla que no tienes. Tablets, configuraciones regionales, modo oscuro, diseños de derecha a izquierda. Reproducir un fallo a voluntad.
Criterio independiente. Una máquina con cinco dispositivos virtuales sigue siendo la opinión de una sola persona.
Cómo se comporta la app en el hardware que la gente tiene: rendimiento, batería, cámara, notificaciones, cambios de red, la versión de Android del propio fabricante. Google recomienda probar en hardware antes del lanzamiento.
Una garantía de elegibilidad. Los buenos teléfonos no satisfacen un requisito escrito sobre testers.
La parte que las herramientas no pueden aportar: alguien que acepta participar, mantiene la app instalada, prueba los flujos que no se te ocurrieron y te cuenta qué le confundió.
Cobertura de dispositivos. Doce testers pueden tener teléfonos parecidos, y por eso las comprobaciones en emulador siguen ganándose su lugar.
Imágenes de Android Studio, imágenes con Play y BlueStacks
No todos los emuladores son iguales, y la diferencia está en la imagen del sistema. Una imagen AOSP no tiene apps de Google. Una imagen Google APIs añade los servicios de Google, pero no la Play Store. Una imagen Google Play incluye la Store, y Android Studio marca con el logotipo de Play los perfiles de dispositivo que la admiten, y documenta esos perfiles de teléfono como compatibles con CTS. El perfil y la imagen del sistema son elecciones separadas al crear el dispositivo virtual, y necesitas la imagen con Play para iniciar sesión e instalar dentro de él. BlueStacks también documenta el inicio de sesión en la Play Store. Nada de eso resuelve la elegibilidad: llegar a la Store y ser contado como tester son resultados distintos.
Si no tienes un teléfono Android pero quieres ayudar a alguien a probar
Es una situación distinta de la de un desarrollador que fabrica una cohorte, y merece una respuesta directa en lugar de una acusación. Ayudar a un amigo a probar en la máquina que tienes no es un engaño. Lo que nadie puede prometerte es el resultado, porque Google no publica cómo se cuenta a cada participante. Si importa, pide prestado un teléfono Android o usa uno antiguo que sea compatible. Si en cambio usas un emulador, díselo al desarrollador para que pueda planificar su prueba en consecuencia.
Laboratorios de dispositivos en la nube e informes previos al lanzamiento
Firebase Test Lab ejecuta tu app en dispositivos de la infraestructura de Google, y el informe previo al lanzamiento de Play Console recorre tu compilación automáticamente. Ambos son QA automatizado legítimo. Ninguno es un participante: una ejecución automatizada no acepta participar, no se mantiene participando durante 14 días y no te dice que la pantalla de bienvenida no tenía sentido.
Qué establece Play Integrity y qué no
Documentación técnica de GooglePlay Integrity es la tecnología sobre la que descansa la mayor parte de esta discusión, así que vale la pena saber para qué sirve. Según developer.android.com, la API «helps you check that user actions and server requests are coming from your genuine app, installed by Google Play, running on a genuine and certified Android device» (veredictos de integridad). El destinatario de esa respuesta es tu app y tu propio backend. Play Console también te informa de las respuestas de integridad, y un ajuste aparte de la ficha de Play Store puede restringir qué dispositivos pueden instalar. Nada de eso es el requisito de la prueba cerrada, y nada de eso debe leerse como tal.
«The app is running on a genuine and certified Android device.» En Android 13 y superior, eso viene con una prueba respaldada por hardware de que el bootloader está bloqueado y el sistema es una imagen certificada del fabricante; las versiones anteriores pueden basarse en una evaluación respaldada por software.
Cómo ve la API al dispositivo. No es una afirmación sobre la inscripción.Documentado como un dispositivo con «signs of attack (such as API hooking) or system compromise (such as being rooted)», o una app «not running on a physical device (such as an emulator that does not pass Google Play integrity checks)». El campo puede llevar varias etiquetas, así que esto es una etiqueta ausente, no un valor llamado «en blanco».
Abarca varias situaciones distintas, así que no se puede leer hacia atrás hasta una única causa.«The app is running on a device that passes basic system integrity checks. The device may not be certified.» Opcional aquí significa que el desarrollador elige si recibe la etiqueta, lo que no tiene nada que ver con que un tester acepte participar.
Un ajuste de la respuesta, no una inscripción.«The app is running on a genuine and certified Android device with a recent security update.» En Android 13 y superior, eso significa integridad del dispositivo más actualizaciones de seguridad recientes en las particiones relevantes; Android 12 e inferior se evalúa por la integridad de arranque respaldada por hardware, sin la misma prueba de actualización reciente.
Un listón alto para tu propio backend. No es un umbral de la prueba cerrada.Documentado para un «Android-powered emulator with Google Play services», en el contexto de Google Play Games en PC, que es una superficie de distribución con sus propios requisitos.
No es un veredicto sobre los emuladores de prueba de Android Studio, en ningún sentido.Dispositivo, reconocimiento de la app y licencia son campos separados
Tres campos se citan como si fueran uno, y mezclarlos es donde empieza la mayor parte de la confusión. El campo de dispositivo describe el entorno. El campo de reconocimiento de la app describe si el binario en ejecución coincide con lo que distribuyó Google Play. El campo de licencia describe el derecho de uso, y puede informar «sin licencia» cuando la cuenta no tiene derecho de uso de la app en Play. Una compilación instalada fuera de Play es una cuestión de licencia y distribución, no un veredicto sobre el hardware.
Estos ejemplos explican terminología. Nada de esto contacta con Google, mide tu dispositivo, verifica la participación ni predice el acceso a producción. Las respuestas reales dependen de la app, de su configuración y del entorno.
| Entorno | Qué puede mostrar una respuesta | Qué te dice eso y qué no |
|---|---|---|
| Teléfono certificado, bootloader bloqueado | El campo de dispositivo puede incluir MEETS_DEVICE_INTEGRITY, y MEETS_STRONG_INTEGRITY con una actualización de seguridad reciente. | Que el dispositivo satisface a la API. No si esa persona aceptó tu vínculo de participación. |
| Emulador estándar de Android Studio | Google documenta un emulador que no pasa las comprobaciones de Play como uno de los motivos por los que no se devuelve ninguna etiqueta de reconocimiento de dispositivo. | Que tu propio backend puede reaccionar al resultado. Una etiqueta ausente no identifica por sí sola un emulador, y no dice nada sobre la inscripción de nadie. |
| Compilación instalada fuera de Play | Responden otros campos: el reconocimiento de la app, para la coincidencia de paquete y certificado, y la licencia, que puede informar «sin licencia» cuando la cuenta no tiene derecho de uso en Play. | Estos campos describen el reconocimiento de la app y el derecho de uso de la cuenta. Léelos por separado: no son un registro completo de cómo se instaló la copia actual, y no inscriben a nadie. |
Así que el resumen es limitado: Play Integrity le dice mucho a tu propio backend sobre el entorno en el que se ejecuta tu app, y nada en esta documentación dice que esos veredictos decidan qué testers cuentan.
Un camino práctico, y cómo recuperarse tras usar emuladores
Trata los 14 días como una beta real y no como un trámite. Los pasos siguientes combinan el proceso publicado por Google con nuestras propias recomendaciones: reclutar por encima del mínimo y organizar los comentarios de esta manera son sugerencias, no cuotas adicionales de Google. La meta es una prueba genuina, no esperar a que avance el calendario.
Recomendación de PrimeTestLabSube un App Bundle firmado, crea un segmento de pruebas cerradas y publica una versión en él. Nada más funciona hasta que haya una versión activa en ese segmento.
Una lista de correos sirve para un grupo pequeño y conocido; un Grupo de Google vinculado escala con más facilidad. En cualquier caso, cada persona sigue teniendo que aceptar el vínculo de participación por sí misma.
Un consejo, no una regla. La gente pierde interés, cambia de teléfono o deja de participar, y un reemplazo no hereda el historial de nadie: sus 14 días empiezan cuando se inscribe. Reclutar entre 15 y 30 te da margen.
Dales a los testers algo concreto que probar y un lugar fácil donde reportar. No se publica ninguna cuota de sesiones diarias ni de capturas de pantalla, así que no fabriques actividad.
Lanza los cambios que las pruebas justificaron y lleva un registro breve de lo que se reportó y de lo que hiciste. No se publica ningún número obligatorio de actualizaciones, así que no publiques cambios solo para cumplir una supuesta cuota de actualizaciones.
El formulario pregunta cómo ejecutaste la prueba y cómo involucraste a los testers, qué es la app y para quién es, y qué cambiaste como resultado. Respóndelo a partir de tus notas. La revisión suele tardar siete días o menos, y puede tardar más.
Si ya ejecutaste tu prueba en emuladores
-
Abre la lista de verificación del acceso a producción en tu Panel y lee lo que dice: cuántos testers, cuántos días continuos. Ese es el estado real de tu prueba.
-
Recorre la lista de diagnóstico de arriba para cualquier persona inscrita que no muestre lo que esperas. Corrige la configuración antes de concluir nada sobre los dispositivos.
-
Conserva el progreso que tienes legítimamente. Nada de lo que Google publica dice que una prueba se reinicie por el entorno que usó un tester.
-
Añade participantes genuinos y deja que cada tester nuevo complete sus propios 14 días consecutivos de participación. Su tiempo no hereda el de nadie más, así que puede que la prueba tenga que extenderse más allá de la fecha de fin que tenías en mente. Si tu app tiene problemas genuinos, esta es también la parte que los encuentra.
Si reclutar gente es la parte difícil, empieza por las opciones gratuitas de siete formas legítimas de encontrar 12 testers. A partir de ahí: cómo invitar testers, la regla de los 14 días consecutivos, actualizar tu app durante las pruebas y el cuestionario de acceso a producción.
Participación genuina y qué rompe las reglas
Gran parte del miedo aquí viene de mezclar tres acciones muy distintas. No son lo mismo, y sus consecuencias tampoco.
Instalar tu propia compilación en un emulador para comprobar que compila, se ejecuta y se ve bien es ingeniería normal, en la herramienta que Google distribuye para eso. No es un engaño, y no es a lo que apunta la aplicación de las normas.
Este es el caso que los desarrolladores nos piden rescatar después de que salió mal. Google no publica ninguna regla sobre el conteo de emuladores, así que no podemos decirte que va contra las reglas. Lo que sí podemos decirte es lo que hacemos nosotros: no construimos una prueba de esta manera, y recomendamos no hacerlo. El acceso a producción se juzga sobre la evidencia de una prueba real, y según nuestra experiencia, una cohorte armada con dispositivos virtuales es del tipo que se devuelve para más pruebas, o se rechaza.
Crear cuentas de Google falsas y aceptar participar desde ellas, en emuladores o en cualquier otra cosa, es un acto completamente distinto. La política de Google sobre calificaciones, reseñas e instalaciones prohíbe intentar manipular el posicionamiento, las calificaciones, las reseñas o las cifras de instalaciones por medios ilegítimos.
Así que la línea práctica tiene que ver con el engaño, no con la virtualización: no crees cuentas ni automatices actividad para tergiversar quién está participando. Google prohíbe la manipulación ilegítima de las instalaciones y de otras métricas de la tienda. Esa política, por sí sola, no establece una regla de conteo específica para emuladores.
Una corrección que vale la pena hacer: una respuesta de «more testing required» (se requieren más pruebas) no establece por sí sola una medida de aplicación de normas contra tu cuenta. Lee el mensaje concreto y sigue probando como indica, en lugar de inferir sanciones automáticas para revisiones futuras. Qué hacer después de esa denegación lo analiza en detalle.
La conclusión práctica es la misma en los tres casos. Un emulador no te da una persona adicional, así que la única pregunta que merece tu tiempo es cómo encontrar personas reales de forma eficiente.
Dónde encaja PrimeTestLab
Aviso comercialVendemos ayuda con las pruebas cerradas, así que lee esta sección sabiéndolo. Los desarrolladores recurren a los emuladores porque encontrar a una docena de personas que se mantengan participando durante dos semanas es realmente difícil, no porque quieran hacer trampa. Esa es la parte que hacemos nosotros.
Qué hacemos
Reclutar y coordinar a 12 o más testers reales, mantenerlos inscritos durante los 14 días completos y reemplazar a quien abandone. Las pruebas arrancan en unas 4-6 horas.
Qué no vamos a afirmar
Que algún servicio pueda garantizar la decisión de Google, o que contratar testers elimine la revisión. El acceso a producción se juzga según tu prueba y tu app.
Si prefieres no pagar
Es una decisión totalmente razonable, y las vías gratuitas de siete formas legítimas de conseguir 12 testers funcionan. Cuestan tiempo en lugar de dinero.
Todos los planes incluyen garantía de devolución. También puedes leer el proceso paso a paso antes de decidir.
Preguntas frecuentes
¿Puedo usar un emulador para la prueba cerrada de Google Play?
Úsalo para probar tu app: para eso lo construye Google. El requisito publicado es de 12 testers con participación aceptada durante 14 días continuos, y ninguna documentación revisada aquí dice si un participante que usa un emulador cuenta para él. Nuestra propia recomendación va más allá de la documentación: probar tu compilación en un emulador está bien, usar instancias de emulador como testers sustitutos no es algo que nosotros haríamos, y aceptar participar desde cuentas de Google falsas es manipulación y puede hacer que se rechace el acceso a producción.
¿Un fallo de Play Integrity significa que un tester no cuenta?
La documentación revisada para esta guía no lo dice. Play Integrity responde a tu propia app y a tu backend sobre el entorno en el que se ejecuta la app, y Google la documenta por separado del requisito de la prueba cerrada. Trata la cadena que va del veredicto de integridad al conteo de testers como una inferencia, no como un proceso publicado.
¿Necesito 12 personas, 12 cuentas o 12 teléfonos?
El requisito está escrito sobre testers con participación aceptada de forma continua durante 14 días, lo que en la práctica significa 12 personas con sus propias cuentas de Google que aceptan tu vínculo de participación. No necesitas tener doce teléfonos, y ninguna documentación de Google exige hardware de gama alta ni una variedad de fabricantes. Si tú mismo puedes ser uno de los doce se explica en usar tus propias cuentas como testers.
No tengo un teléfono Android. ¿Puedo ayudar a alguien a probar su app de todos modos?
Querer ayudar no es un engaño, y es distinto de que un desarrollador fabrique una cohorte. Nadie puede prometerte con honestidad cómo se contará tu participación. Pedir prestado un dispositivo Android es la vía de menor riesgo; si en cambio usas un emulador, díselo al desarrollador para que pueda planificar en consecuencia.
¿Puedo usar BlueStacks para la prueba cerrada de Google Play?
BlueStacks documenta el inicio de sesión en la Play Store, y una imagen de Android Studio con Play también puede llegar a la Store. Eso confirma que el acceso a la Play Store es posible, no que tu compilación de prueba cerrada en particular vaya a estar disponible: eso sigue dependiendo de la cuenta, del segmento y de la versión. Tampoco resuelve nada sobre la elegibilidad, porque ninguna documentación de Google establece si ese participante cuenta. Trata la página de un proveedor como autoridad sobre ese producto y nada más, en ningún sentido.
¿La verificación del dispositivo del desarrollador es lo mismo que la prueba cerrada?
No. La verificación del dispositivo es el titular de la cuenta demostrando que tiene acceso a un dispositivo Android físico sin root con Android 10 o superior, al configurar la cuenta, y Google puede volver a pedirla más adelante. La prueba cerrada trata de personas que aceptan participar en un segmento de pruebas. Distinto actor, distinto propósito, distinta página de ayuda.
¿Desinstalar la app significa que un tester abandonó la prueba?
Desinstalar y dejar de participar son acciones distintas. El requisito está escrito sobre el estado de participación continua, así que no asumas que una desinstalación rompe la ventana ni que una persona que se va reinicia a las demás. Si el progreso parece incorrecto, revisa primero la lista de verificación del acceso a producción y la inscripción.
Conclusión
Resumen
Los emuladores son una herramienta de prueba legítima y un mal sustituto de los participantes. El requisito es de 12 testers con participación aceptada durante 14 días continuos, y la documentación revisada aquí no especifica si un participante que usa un emulador cuenta. Así que abre tu lista de verificación del acceso a producción, recorre las comprobaciones de configuración antes de culpar al hardware y dedica el resto de la ventana a reclutar personas que de verdad usen la app. Nuestra propia recomendación, que la documentación no tiene por qué decir por nosotros: fabricar participación con emuladores o cuentas falsas no vale el riesgo de rechazo. Empieza por las formas gratuitas de encontrar 12 testers →
Documentación oficial de Google
Debate en la comunidad, no documentación
La respuesta recomendada allí aconseja usar a otras personas en dispositivos Android físicos en lugar de emuladores, y un Experto de producto la respaldó, lo cual vale la pena saber. Sigue siendo debate en la comunidad: no se cita ninguna política, y la página advierte que el contenido puede no estar verificado.