Respuesta rápida
Un rechazo por Broken Functionality significa que el revisor de Google comprobó que la versión que enviaste se cerró, forzó el cierre, se congeló o funcionó de forma anormal de alguna otra manera; los propios ejemplos de Google son apps que no se instalan, que se instalan pero no cargan, o que cargan pero no responden. Es una decisión de política sobre una versión, no una denegación del acceso a producción, y Google dice que un rechazo por sí solo no afecta a la reputación de tu cuenta de desarrollador. Reproduce el problema en la compilación que distribuye Play, confirma que los revisores pueden iniciar sesión mediante Sign-in details (antes App access), corrige todos los canales afectados y luego envía la versión corregida a revisión. Apela solo cuando puedas demostrar que la conclusión fue un error.
Vigente a fecha de 16 de octubre de 2026. Cada regla de esta página se comprobó ese día en las páginas de políticas de Google Play y en la Ayuda de Play Console, y cada una lleva su enlace donde se usa. Los informes de desarrolladores citados abajo son evidencia de lo que vieron los desarrolladores en 2026, no el diagnóstico de Google sobre sus apps, y no se ofrece ninguna clasificación de causas porque ningún conjunto de datos público la respalda.
Este artículo trata los rechazos de versiones por la política Broken Functionality. Si Google denegó el acceso a producción tras tu prueba cerrada, o te dijo que se requieren más pruebas, es una decisión distinta con una solución distinta: lee mejor qué hacer cuando Google Play dice que se requieren más pruebas y por qué se rechazan las solicitudes tras las pruebas cerradas.
Qué cubre este artículo
¿Qué significa Broken Functionality en Google Play?
Es una de las dos secciones de la política de Funcionalidad, contenido y experiencia del usuario de Google. La otra sección, Limited Functionality and Content (funcionalidad y contenido limitados), trata de apps con muy poco propósito. Broken Functionality trata de una app que no funciona tal como se envió.
No permitimos apps que se bloqueen, fuercen el cierre, se congelen o funcionen de forma anormal de cualquier otra manera.
Google enumera tres ejemplos de infracciones habituales bajo esa frase: apps que no se instalan, apps que se instalan pero no cargan, y apps que cargan pero no responden. Léelos como tres lugares donde buscar. Un revisor que no puede instalar la compilación, que ve una pantalla en blanco o de carga infinita, o que toca un control y no pasa nada puede generar el mismo aviso.
Puede que todavía encuentres el nombre Minimum Functionality en enlaces antiguos de la Ayuda y en hilos de foros. La sección actual de la política se llama Limited Functionality and Content, y cubre apps de texto estático o PDF, apps con muy poco contenido y apps diseñadas para no hacer nada. Un aviso puede citar cualquiera de las dos secciones, y las soluciones son distintas, así que lee cuál nombra tu aviso antes de cambiar nada.
Cuatro decisiones que se confunden entre sí
| Decisión | De qué trata | Por dónde empezar |
|---|---|---|
| Broken Functionality | De qué trataLa versión enviada se cerró, se congeló, no cargó o no respondió para el revisor. | Por dónde empezarReprodúcelo en la compilación que distribuye Play, corrígelo en todos los canales afectados y vuelve a enviarla. |
| Limited Functionality and Content | De qué trataLa app funciona, pero ofrece muy poco propósito o contenido propio. | Por dónde empezarAñade funcionalidad real. Corregir un error no basta para responder a esta decisión. |
| Sign-in details faltantes o que no funcionan | De qué trataLos revisores no pudieron pasar un inicio de sesión, una membresía, un muro de pago, un código de un solo uso o una comprobación de región. | Por dónde empezarActualiza Sign-in details en Contenido de la app y luego envía el cambio a revisión. |
| Acceso a producción no concedido | De qué trataTras la prueba cerrada, Google decidió que la app necesita más pruebas o que no está lista para producción. | Por dónde empezarUn proceso aparte, sin aviso que apunte al código. Consulta se requieren más pruebas. |
¿Dónde muestra Google qué estaba fallando?
Empieza por el correo de la medida de cumplimiento y la página Policy status de Play Console. Juntos nombran la política y la versión afectada, y Google dice que Policy status también muestra cualquier información adicional disponible. Las capturas de pantalla, los datos del dispositivo y los registros de errores no están garantizados, así que no los esperes.
Abre Play Console, selecciona la app y abre su página Policy status. Anota cuatro cosas antes de tocar el código: la sección de la política nombrada, el código de versión y el canal que se revisaron, la fecha y cualquier evidencia adjunta. Revisa también el correo y tus notificaciones de Play Console, porque ahí es donde Google indica qué política infringió la versión.
Cómo son de verdad los avisos de 2026
No existe un único correo de Broken Functionality que reciba todo el mundo, y cualquier página que publique uno como la plantilla exacta está adivinando. Los desarrolladores que publicaron sus avisos en 2026 describen niveles de detalle muy distintos:
- Una etiqueta de aviso que decía "Broken Functionality: Unresponsive UI elements" (elementos de la interfaz que no responden), publicada el 2 de septiembre de 2026 por un desarrollador cuya app mostraba una pantalla de reintento sin conexión durante su primera sincronización de datos (Comunidad de Ayuda de Play Console).
- Un ejemplo del revisor que decía "For example, your app does not open or load." (por ejemplo, tu app no se abre ni carga), citado en junio de 2026 por un desarrollador de juegos cuya pantalla de título sí cargaba. El autor contó después que el juego se publicó tras cambiar cómo salía de él el botón Atrás de Android.
- Un aviso que un desarrollador describió en agosto de 2026 como solo dos palabras, "Broken functionality", sin nada más.
Son fragmentos reproducidos por desarrolladores, no correos de Google autenticados, y cada uno es un caso aislado. Muestran el rango de detalle que podrías recibir, no lo que dirá tu aviso ni por qué falló tu app.
Si tu aviso es impreciso
Trata la política citada como un síntoma que reproducir, no como un diagnóstico. Las cinco comprobaciones de la siguiente sección están ordenadas para que cada una descarte un lugar distinto donde puede esconderse el fallo.
¿Qué deberías comprobar primero tras un rechazo por Broken Functionality?
Haz cinco comprobaciones sobre la versión exacta que revisó Google. Están ordenadas de la más barata de descartar a la más difícil, no por la frecuencia de cada causa, porque ningún dato público muestra con qué frecuencia ocurre cada una.
Cinco comprobaciones, en orden
Instala la compilación que distribuye Play, no tu compilación de depuración
Instala desde tu canal de pruebas (segmento de pruebas en la documentación de Google para Latinoamérica) en un dispositivo limpio, con una cuenta de Google que nunca haya ejecutado la app, y ábrela como lo haría un revisor. Google Play firma las compilaciones que distribuye con tu clave de firma de apps (Usar la firma de apps de Play), así que cualquier servicio que compruebe la huella digital de un certificado, como Google Sign-In, Maps o una clave de API restringida por nombre de paquete y SHA-1, puede funcionar en tu compilación de depuración y fallar en la de la tienda. Un desarrollador en 2025 rastreó un fallo que solo ocurría en la versión publicada hasta un permiso de internet que faltaba en el manifiesto de producción.
Confirma que el revisor puede entrar
Si alguna parte de la app está detrás de un inicio de sesión, una membresía, una ubicación u otra restricción, Google exige que proporciones los datos de acceso. Comprueba que Sign-in details (antes App access) contenga credenciales que funcionen hoy, desde cualquier país, sin un código de un solo uso. La siguiente sección lo explica paso a paso.
Prueba el backend desde fuera de tu propia red
Las pantallas de inicio de sesión y de datos fallan cuando el servidor no es accesible desde la red del revisor. En 2026, algunos desarrolladores rastrearon fallos hasta una regla de firewall accidental que bloqueaba la solicitud de un código de inicio de sesión, e informaron de un error de confianza del certificado que aparecía en una pantalla de inicio de sesión. Prueba con datos móviles y con otra red, y desde otro país si tu servidor filtra el tráfico por región.
Toca cada control visible y abre cada pantalla vacía
Cada botón y cada enlace deberían responder con contenido adecuado. La propia lista de comprobación de Broken Functionality de Google en la Comunidad de Ayuda de Play Console dice: "Asegúrate de que tu app no tenga páginas vacías o en blanco que carezcan de avisos o mensajes de error adecuados". Elimina las funciones sin terminar en lugar de publicar un botón que no hace nada, y comprueba que cada función que promete tu ficha de Play Store funcione de verdad en la compilación. A una lista legítimamente vacía, como cuando aún no hay elementos guardados, dale una frase que lo explique y una acción siguiente. Si tu navegación es poco habitual, como tocar en cualquier lugar para continuar, añade una indicación visible que un usuario nuevo no pueda pasar por alto.
Revisa el inicio, el botón Atrás y los informes que Play ya tiene
Abre la app en frío, gírala, envíala a segundo plano y tráela de vuelta, y pulsa Atrás en cada pantalla. Después lee el informe previo al lanzamiento y Android vitals de la versión revisada. Un fallo registrado ahí es la evidencia más sólida que vas a conseguir, y un informe limpio tiene límites que explica la sección posterior a la siguiente.
¿Cómo das a los revisores de Google los datos de inicio de sesión?
En Play Console, ve a Policy and programs, luego a Contenido de la app y luego a Sign-in details (datos de inicio de sesión). La sección se llamaba antes App access, por eso los artículos antiguos y algunas páginas traducidas de la Ayuda todavía usan ese nombre.
Si toda tu app o partes de ella están restringidas mediante credenciales de inicio de sesión, datos de acceso, membresías, ubicación u otras formas de autenticación, debes proporcionar todos los datos necesarios para permitir el acceso a tu app.
Añade o actualiza las instrucciones
- Abre Play Console y ve a la página Contenido de la app (Policy and programs > Contenido de la app).
- En Sign-in details, selecciona Start, o Manage si ya añadiste instrucciones antes.
- Selecciona + Add new instructions e introduce los datos de acceso. Usa el campo Any other instructions para cualquier cosa poco habitual, como una contraseña de un solo uso, la autenticación multifactor o un inicio de sesión con más de dos campos.
- Guarda los cambios. Puedes añadir hasta cinco conjuntos de instrucciones.
- Ve a Resumen de publicación, busca el cambio en Changes ready to send for review y selecciona Send for review. Guardar por sí solo no envía nada.
Qué cuenta como acceso que funciona
Los Requisitos de Play Console de Google te piden "proporcionar una cuenta de demostración activa, la información de inicio de sesión y todos los demás recursos necesarios para que Google Play revise tu app". Los requisitos de Google para los datos de inicio de sesión detallan qué significa eso:
- Una cuenta activa y reutilizable, no una invitación de un solo uso ni una prueba gratuita que caduque durante la revisión.
- Credenciales que pasen los códigos de un solo uso y la verificación en dos pasos, porque el revisor no puede recibir el código que envías a un teléfono o a un buzón de correo.
- Acceso que funcione desde cualquier ubicación si la app restringe por región, y acceso completo, sin cobro, a las funciones de pago o restringidas que el revisor necesite ver.
- Datos escritos en inglés y mantenidos al día. Si cambias la contraseña o eliminas la cuenta de prueba, actualiza Sign-in details ese mismo día.
- Si el inicio de sesión necesita algo que no es texto, como un código QR o un código de barras, genera una URL estática para ello y añádela a Sign-in details. Si la app pide a los usuarios que configuren su propio PIN o usa un inicio de sesión con redes sociales, explica en las instrucciones cómo puede pasar un revisor.
Que falte el acceso no es lo mismo que un inicio de sesión roto
Si el aviso cita Sign-in details, ningún cambio de código sirve hasta que los datos de acceso se corrijan y se envíen a revisión. Si las credenciales estaban bien y lo que falló fue el propio inicio de sesión, es un problema de Broken Functionality, y la comprobación del backend de arriba es donde debes buscar.
¿Y si la app funciona en tu teléfono y Google no envió ninguna captura?
Entonces tu teléfono no es el entorno que falló. Reprodúcelo en la compilación de la tienda, en un dispositivo limpio y en otra red, y lee los dos informes que Play Console ya tiene de esa versión antes de decidir nada.
El informe previo al lanzamiento
Lo encontrarás en Prueba y lanzamiento > Pruebas > Informe previo al lanzamiento. Google lo genera automáticamente cuando subes un app bundle o un APK, según la capacidad disponible, ejecutando la app en dispositivos de prueba. Comprueba a qué pantallas llegó realmente el rastreo: si se detuvo en tu pantalla de inicio de sesión, nunca vio el resto de la app. Google añade un límite que conviene conocer: "Las credenciales solo se pueden insertar automáticamente en apps de Android que usen widgets estándar de Android." (Usar un informe previo al lanzamiento para identificar problemas). Un informe limpio es evidencia, no un aprobado. Google dice lo mismo de sus comprobaciones previas a la revisión: "Superar todas las comprobaciones previas a la revisión no garantiza superar el proceso formal de revisión de la app".
Android vitals
Lo encontrarás en Supervisar y mejorar > Android vitals > Fallos y ANR. Google recopila estos datos solo de los usuarios que aceptaron compartir datos de uso y diagnóstico (Supervisar la calidad técnica con Android vitals), así que una app nueva en una prueba pequeña puede no mostrar nada en absoluto. Una página de vitals vacía no demuestra que la app nunca se haya cerrado inesperadamente.
Personas reales en dispositivos reales
Una prueba cerrada existe para encontrar este tipo de problema antes de un lanzamiento público. Los testers con distintos teléfonos, versiones de Android y redes llegan a las pantallas a las que llega un revisor, y sus comentarios te dicen dónde fallan las cosas. Eso te ayuda a encontrar y corregir defectos; no cambia cómo revisa Google la app. Si necesitas lo básico del canal en sí, consulta cómo funcionan las pruebas cerradas de Google Play.
¿Deberías corregir y volver a enviar, o apelar?
Corrige y vuelve a enviar cuando puedas reproducir un fallo o encuentres una causa plausible. Apela cuando tengas pruebas de que la conclusión citada es un error. Nunca vuelvas a enviar la misma compilación sin cambios: Google indica a los desarrolladores que no vuelvan a publicar una app rechazada hasta que se corrija la infracción.
¿Corregir, aclarar o apelar?
Responde tres preguntas sobre tu aviso y tus propias pruebas. Nada de lo que elijas sale de esta página.
Responde las preguntas para ver una recomendación. Si no puedes reproducir un fallo, la tercera pregunta decide.
Corrígelo y vuelve a enviarlo en todos los canales
Corregir y reenviarTienes un fallo reproducible, que es la mejor posición posible. Corrígelo, prueba la corrección en la compilación de la tienda y luego sigue los pasos de reenvío de abajo para que no quede ningún bundle no conforme activo en ningún canal.
Prueba la compilación de la tienda antes de decidir
Primero, probarUna compilación de depuración no es lo que ejecutó el revisor. Instala desde tu canal de pruebas en un dispositivo limpio con una cuenta nueva, en una red que no controles, y haz las cinco comprobaciones. Decide solo después.
Corrige Sign-in details y envía a revisión
Corregir el accesoActualiza las instrucciones con credenciales reutilizables que eviten los códigos de un solo uso, guarda y luego envía el cambio a revisión desde Resumen de publicación. Google dice que puedes hacerlo sin contactar con el equipo de asistencia de políticas ni esperar su respuesta.
Añade propósito, no solo correcciones
RehacerLimited Functionality and Content trata de cuánto hace la app. Añade funciones o contenido reales y propios de la app antes de volver a enviarla; una corrección de estabilidad no responde a esta conclusión.
Haz evidente el diseño y luego decide
AclararSi una pantalla sin conexión, un estado vacío o un gesto poco habitual es intencionado, un revisor aún puede interpretarlo como un fallo. Añade una indicación visible, una explicación y una acción siguiente. Puedes apelar con pruebas, pero una pantalla más clara también elimina la duda para el siguiente revisor.
Apela con pruebas
ApelarProbaste la compilación de la tienda en un dispositivo limpio y en otra red y no encontraste nada mal. Apela una sola vez, con el código de versión, el dispositivo y la versión de Android, los pasos exactos y una grabación de pantalla del flujo que nombra el aviso.
Volver a enviar una versión corregida
Los pasos de reenvío de Google son más que subir un nuevo código de versión:
- Lee la política nombrada en el correo y en tus notificaciones, y revisa la app también frente a las demás políticas; Google advierte que otras infracciones pueden dar lugar a nuevas medidas de cumplimiento.
- Actualiza cada tipo de versión que contenga la versión afectada, no solo producción: incluidos los canales de pruebas abiertas, cerradas e internas.
- Sube el app bundle corregido y desactiva los que no cumplen. Google advierte que, si no los desactivas, el reenvío fallará y es posible que se retiren las versiones publicadas.
- En cada canal afectado, selecciona Manage track y Create new release, añade el bundle corregido (o descarta un borrador que contenga el infractor) y asegúrate de que la versión no conforme aparezca en Not included.
- Guarda, selecciona Review release y lánzala.
Después, el cambio queda a la espera de procesarse. Google dice: "El procesamiento puede tardar unas horas o hasta siete días (o más en casos excepcionales)" (Controlar cuándo se revisan y publican los cambios de la app).
Corregido, pero la advertencia sigue ahí
Si hay una versión corregida publicada y Policy status sigue mostrando el problema, compara los códigos de versión y los canales que nombra la advertencia con lo que está activo ahora: un bundle no conforme que quedó en un canal de pruebas es lo primero que debes descartar. Una versión más reciente no elimina automáticamente cada entrada de una medida de cumplimiento. Si todo coincide, contacta con el equipo de asistencia de Play Console con los códigos de versión, los canales afectados y cualquier referencia de caso anterior.
Apelar la decisión
Google restablece las apps cuando cometió un error y comprueba que la app no infringe sus políticas. Para apelar, sigue las instrucciones del correo de la medida de cumplimiento o usa el formulario de apelación de Google. Puedes presentar una apelación por cada medida de cumplimiento (Gestionar infracciones de políticas y apelaciones), y Google responde a las apelaciones en chino, inglés, japonés y coreano. Google no publica ningún plazo de respuesta para las apelaciones, y los informes de desarrolladores mezclan respuestas a apelaciones con revisiones posteriores de versiones, así que planifica sin contar con una fecha.
Redacta la apelación como evidencia, no como frustración: el código de versión que se revisó, el dispositivo y la versión de Android con los que probaste, los pasos exactos, una grabación de pantalla del flujo que nombra el aviso y lo que cambiaste, si cambiaste algo.
¿Un rechazo por Broken Functionality perjudica a tu cuenta o a tu prueba cerrada?
Un rechazo por sí solo no afecta a la reputación de tu cuenta de desarrollador. Los rechazos repetidos pueden dar lugar a una suspensión, y las suspensiones cuentan como faltas, así que corrige antes de volver a enviar. Lo que un rechazo le hace a una prueba cerrada en curso no está documentado.
La página Proceso de aplicación de políticas de Google explica la diferencia:
- "Los rechazos no afectan a la reputación de tu cuenta de desarrollador de Google Play."
- "Si se rechazó una actualización de una app existente, la versión de la app publicada antes de la actualización seguirá disponible en Google Play."
- "La suspensión puede producirse como resultado de infracciones de políticas graves o múltiples, así como de rechazos o retiradas repetidos de apps."
Google no publica ningún número de rechazos que sea seguro. Volver a enviar el mismo fallo es exactamente el patrón que describe la tercera frase.
¿Y la prueba cerrada de 14 días?
El requisito de pruebas de Google pide a las cuentas personales creadas después del 13 de noviembre de 2023 un mínimo de 12 testers (12 verificadores en la documentación oficial de Google en español) que hayan aceptado participar de forma continua durante al menos 14 días antes de solicitar acceso a producción. No dice si el rechazo por política de una versión del canal cerrado reinicia, pausa o conserva ese periodo, y lo que se afirma en los foros en un sentido u otro son suposiciones. Lo que sí puedes comprobar: si tus testers siguen teniendo una versión aprobada en el canal, y qué muestra el Panel sobre el acceso a producción. Mantén a los testers participando mientras corriges, y pregunta al equipo de asistencia de Play Console por tu caso si el Panel cambia. La regla en sí se explica en qué significan 14 días consecutivos.
¿Rechazará Google una app WebView o TWA por estar defectuosa?
No por la tecnología. Google documenta tanto las Trusted Web Activities como WebView para apps de Android, y ninguna política prohíbe esa arquitectura. Las preguntas son si la app funciona, si tiene suficiente propósito y si tienes derecho a envolver el sitio web.
No permitimos apps cuyo propósito principal sea dirigir tráfico de afiliados a un sitio web o proporcionar una vista web de un sitio web sin el permiso de su propietario o administrador.
Para una app basada en web, las comprobaciones de Broken Functionality son las mismas que para cualquier otra app: el sitio debe cargar dentro de la app desde una instalación limpia, los estados sin conexión y de error deben explicarse por sí mismos, y cada enlace debe llevar a algún sitio. Si la app es sobre todo una vista ligera de un sitio web, la sección Limited Functionality and Content es el riesgo mayor. No se ha demostrado que cambiar de una TWA a un WebView, o al revés, solucione un rechazo por sí solo.
¿Cómo te ayuda PrimeTestLab antes de la próxima revisión?
No podemos corregir tu código ni cambiar la decisión de Google. Lo que aportamos es la parte de las pruebas: personas reales en dispositivos reales que usan tu app a través de tu prueba cerrada, para que problemas como los de arriba aparezcan en sus comentarios antes de que los encuentre un revisor.
PrimeTestLab aporta 12 o más testers reales en dispositivos reales que abarcan Android 7 a 17, participando durante los 14 días completos, y las pruebas empiezan en 4-6 horas. Hemos gestionado pruebas para 12,100+ apps con testers en 120+ países.
Pruebas por tu cuenta o pruebas gestionadas
| Tarea | Por tu cuenta | Con PrimeTestLab |
|---|---|---|
| Encontrar testers | Por tu cuentaAmigos, grupos y foros, normalmente con teléfonos parecidos | Con PrimeTestLabTesters reales en dispositivos reales, asignados a tu app |
| Variedad de dispositivos y versiones de Android | Por tu cuentaLo que tengan tus voluntarios | Con PrimeTestLabDispositivos de Android 7 a 17 |
| Uso diario y comentarios | Por tu cuentaDepende de la buena voluntad | Con PrimeTestLabLos testers usan la app e informan de lo que falla |
| Mantener a 12 participando durante 14 días | Por tu cuentaPersigues tú mismo a los que abandonan | Con PrimeTestLabLas bajas se reemplazan para mantener el número |
| Corregir el código y responder al aviso | Por tu cuentaTú | Con PrimeTestLabSigues siendo tú; nosotros informamos de lo que encontraron los testers |
| La decisión de Google | Por tu cuentaGoogle | Con PrimeTestLabSigue siendo Google; nadie puede prometer la aprobación |
Si Google no ha concedido el acceso a producción tras tu prueba completa con PrimeTestLab, tú eliges entre repetición gratis o reembolso completo; consulta la política de reembolso y repetición gratis. Eso cubre el requisito de pruebas, no un rechazo de tu código por política. Los planes empiezan en $19.99 más 5% de tarifa de servicio al pagar (mínimo $1.50), y la tarifa de registro única de $25 de Google es aparte. Compara los planes en la página de precios.
Preguntas frecuentes
¿Qué es la política Broken Functionality de Google Play?
Es una sección de la política de Funcionalidad, contenido y experiencia del usuario de Google Play. Google no permite apps que se bloqueen, fuercen el cierre, se congelen o funcionen de forma anormal de cualquier otra manera, y enumera como infracciones habituales las apps que no se instalan, las que se instalan pero no cargan y las que cargan pero no responden.
¿Broken Functionality es lo mismo que Minimum Functionality?
No. Minimum Functionality es el nombre antiguo de lo que Google llama ahora Limited Functionality and Content, que cubre apps con muy poco propósito o contenido. Broken Functionality cubre apps que no funcionan tal como se enviaron. Las dos están en la misma política, pero necesitan soluciones distintas.
¿Dónde añado las credenciales de demostración para la revisión de Google Play?
En Play Console, ve a Policy and programs, luego a Contenido de la app y luego a Sign-in details (antes App access). Selecciona Start o Manage, añade las instrucciones y guarda, y después envía el cambio a revisión desde la página Resumen de publicación. Las credenciales deben ser reutilizables y no pueden depender de un código de un solo uso enviado a tu teléfono.
¿Un rechazo cuenta como falta en mi cuenta de desarrollador?
Google dice que los rechazos no afectan a la reputación de tu cuenta de desarrollador. Las suspensiones cuentan como faltas, y Google incluye los rechazos o retiradas repetidos de apps entre los motivos de suspensión, así que corrige el problema citado antes de volver a enviar.
¿Cuánto tarda la revisión después de volver a enviar una app corregida?
Google dice que los cambios de una app pueden tardar unas horas o hasta siete días en procesarse, o más en casos excepcionales. Eso es la revisión de la versión corregida. Google no publica ningún plazo de respuesta para las apelaciones.
¿Puedo apelar un rechazo por Broken Functionality?
Sí, si crees que la conclusión es errónea. Sigue las instrucciones del correo de la medida de cumplimiento o usa el formulario de apelación de Google. Puedes presentar una apelación por cada medida de cumplimiento, así que incluye el código de versión revisado, el dispositivo y los pasos con los que probaste, y una grabación del flujo que nombra el aviso.
¿Un rechazo por Broken Functionality reinicia mi prueba cerrada de 14 días?
Google no lo documenta. Su requisito es un mínimo de 12 testers que hayan aceptado participar de forma continua durante al menos 14 días antes de solicitar acceso a producción. Mantén a los testers participando mientras corriges la versión, vigila el Panel y pregunta al equipo de asistencia de Play Console si cambia tu elegibilidad.
¿Por qué rechazaron mi app si funciona en mi teléfono?
Tu teléfono cubre una compilación, una cuenta, un conjunto de datos y una red. Instala la versión que distribuye Play en un dispositivo limpio con una cuenta nueva y luego prueba con contenido vacío y con solicitudes de red fallidas. Una compilación de la tienda firmada con la clave de firma de apps puede fallar donde tu compilación de depuración funciona, así que prueba la compilación que instaló el revisor.
Mi app usa Google Sign-In o un código de un solo uso. ¿Qué debo dar a los revisores?
Google exige datos de inicio de sesión reutilizables, que funcionen desde cualquier ubicación y que eviten las contraseñas de un solo uso o la verificación en dos pasos. Da a los revisores una cuenta de prueba e instrucciones que lleguen a cada función restringida, incluidas las de pago. Después prueba tú mismo exactamente los datos que proporcionaste; explicar cómo recibe un código un usuario normal no es un acceso que funcione.
Google no envió ninguna captura ni registro de fallos. ¿Y ahora qué?
Revisa Policy status y el correo de la medida de cumplimiento para ver la versión afectada y cualquier detalle que haya añadido Google. Después reproduce el recorrido principal en la versión enviada y graba tu propio video y tus registros. Una página de Android vitals limpia o un informe previo al lanzamiento sin problemas no demuestra que cada pantalla y cada solicitud al backend funcionaran para el revisor.
¿Las apps TWA y WebView se rechazan automáticamente?
No. Google documenta ambas tecnologías y ninguna política las prohíbe. Lo que Google sí restringe son las apps que envuelven un sitio web sin el permiso de su propietario y las apps con muy poca funcionalidad o contenido. Diagnostica el fallo real, como errores de inicio de sesión, de navegación o de red; cambiar de un tipo de contenedor al otro no es una solución documentada.
En resumen
En resumen
Un rechazo por Broken Functionality dice que la versión que revisó Google no funcionó: se cerró, se congeló, no cargó o no respondió. Lee qué política cita el aviso, reprodúcelo en la compilación que distribuye Play, confirma que los revisores pueden iniciar sesión mediante Sign-in details, prueba el backend desde fuera de tu red y haz que cada control y cada pantalla vacía se expliquen por sí mismos. Corrige todos los canales afectados y envía la versión corregida a revisión. Apela solo con pruebas de que la conclusión fue errónea. Un rechazo por sí solo no es una falta, pero los reenvíos repetidos sin corregir pueden acabar en una.
Si quieres que personas reales en dispositivos reales encuentren la pantalla rota antes que el próximo revisor, PrimeTestLab se encarga de la parte de la prueba cerrada mientras tú corriges la app.
Documentación oficial de Google
Qué puede cambiar en esta página
- Las etiquetas de Play Console cambian. Sign-in details se llamaba App access hasta hace poco, y algunas páginas traducidas de la Ayuda todavía usan el nombre antiguo.
- La redacción de los avisos no se publica como plantilla y cambia de un caso a otro; fíate de tu propio correo y de tu página Policy status antes que de cualquier ejemplo de esta página.
- Google no documenta qué le hace un rechazo por política a una prueba cerrada en curso. Si publica una regla, esta página la seguirá.
Fuentes comprobadas el 16 de octubre de 2026.