Una solicitud de ubicación en la primera pantalla
Tu página de inicio llama a la API de geolocalización al cargar, así que Android pide la ubicación antes de que el usuario haya visto nada. Nada explica por qué. Es la infracción de manual.
Qué pide la política de datos de usuario
La política de datos de usuario (User Data) de Google tiene una regla específica para los usos de datos que un usuario no esperaría necesariamente. Cuando tu app accede a datos personales o sensibles, los recopila, los usa o los comparte de una forma que puede quedar fuera de lo que el usuario espera razonablemente de la función que tiene delante, primero debes mostrar una divulgación dentro de la app y después pedir su consentimiento.
La divulgación tiene que estar dentro de la app y formar parte del uso normal, no escondida en un menú de ajustes, en la descripción de la ficha ni en la política de privacidad. Debe decir qué datos están implicados y cómo se usan y se comparten, y no puede quedar enterrada entre textos que no tienen nada que ver, como tus condiciones. El consentimiento requiere una acción afirmativa, como tocar un botón con una etiqueta clara; tocar fuera, pulsar atrás o un mensaje que desaparece solo no cuentan. Cuando hay un permiso en tiempo de ejecución de por medio, la divulgación va antes de la solicitud del sistema. Las prácticas recomendadas de Google para la divulgación destacada añaden detalles prácticos: empieza por el porqué, enumera los datos, escribe con sencillez, ofrece una forma de rechazar y no imites los diálogos del sistema Android.
La divulgación no sustituye a tu política de privacidad ni al formulario Data safety. Los tres tienen que describir la misma realidad.
Cómo se redacta el rechazo
La entrada en Estado de las políticas (Policy status) menciona la política de datos de usuario y su requisito de divulgación destacada, a menudo con el tipo de dato que detectó el revisor: ubicación, contactos, imágenes, apps instaladas o un identificador del dispositivo. Entre los títulos que suelen citar los desarrolladores están Prominent disclosure not found y Missing information in prominent disclosure. El primero significa que el revisor vio una solicitud de permiso o un flujo de datos sin ninguna explicación previa. El segundo significa que la explicación existe pero le falta algo: normalmente la palabra "ubicación", la mención al segundo plano cuando se trata de acceso en segundo plano, o qué pasa con los datos. La captura suele mostrar el diálogo de permisos del sistema en la primerísima pantalla de la app.
Dónde lo provocan las apps web empaquetadas
Un montón de solicitudes al arrancar
WebViewGold pide por defecto el permiso de notificaciones en el primer inicio (requirePush). Eso no es en sí un problema de datos personales, pero una pila de solicitudes antes de cualquier contexto es exactamente lo que los revisores capturan. Lleva cada solicitud a su contexto.
Contactos enviados a tu servidor
La API de contactos (requestcontactpermission:// y después readcontacts://) entrega la libreta de direcciones a tu app web. Subirla para "encontrar amigos" requiere una divulgación que mencione los contactos y la subida.
Fotos que salen del dispositivo
Una subida que el usuario inicia desde un campo de archivo es esperable. Subir imágenes en segundo plano o usarlas para algo más allá de la función visible no lo es, y necesita una divulgación.
Scripts dentro de tu app web
La grabación de sesiones, el fingerprinting, los widgets de chat y las etiquetas de analítica se ejecutan dentro del WebView y cuentan como recopilación de datos de tu app. Si un script registra lo que se escribe o construye un perfil del dispositivo, divúlgalo o déjalo fuera de la app.
Con una buena versión optimizada de su aplicación web, puedes tener una impresionante aplicación móvil en un par de minutos. ¡Además del servicio al cliente es muy agradable y muy útil! ¡Puedo recomendar WebViewgold :-)
Qué tiene que decir cada divulgación
| Datos | Dónde mostrar la divulgación | Lo que debe decir |
|---|---|---|
| Ubicación mientras la app está abierta | En la pantalla de la función, justo antes de la llamada de geolocalización | Que la app recopila la ubicación, para qué función y si se envía a tu servidor o se comparte |
| Ubicación en segundo plano | Antes de la solicitud de ubicación, dentro de la función que la necesita | La palabra ubicación, una frase como "cuando la app está cerrada o no se está usando", cada función que la usa y si sirve para anuncios; consulta la guía de ubicación en segundo plano |
| Contactos | Antes de requestcontactpermission:// | Qué campos se suben (nombres, números, emails), por qué, cuánto tiempo los conservas y quién más los recibe |
| Fotos, cámara, micrófono | Antes de la primera captura o subida, siempre que el uso no sea obvio | Qué se captura o se sube y adónde va |
| Datos recopilados por scripts | Antes de que se inicie el script, normalmente en el primer arranque | Qué se recopila (por ejemplo grabaciones de pantalla o datos del dispositivo), quién lo recopila y por qué, con una opción real de rechazarlo |
Añade una divulgación conforme en tu app web
Casi todo es trabajo en la app web; solo necesitas recompilar la parte nativa si cambias Config.java.
Localiza cada solicitud y cada flujo de datos
Instala la compilación de prueba desde cero, anota cada solicitud del sistema y la pantalla en la que aparece, y haz una lista de lo que tu app web envía a tu backend o a terceros. Compara la lista con tus respuestas de Data safety.
Deja de preguntar al arrancar
Quita las llamadas de geolocalización de la carga de la página y lánzalas desde un botón en la pantalla de la función. Para las notificaciones push, pon
requirePushen false en Config.java y pide el permiso más tarde conregisterpush://, como describe la documentación de push para Android.Muestra primero tu propia explicación
Un modal en tu app web con un título claro, los datos, el motivo y lo que ocurre con los datos, más dos botones: Aceptar y Ahora no. Mantén tu propio diseño; no imites el diálogo de permisos de Android.
Lanza el paso nativo solo después de Aceptar
Entonces llama a la API de geolocalización, a
requestcontactpermission://o aregisterpush://. La solicitud del sistema que aparece a continuación es el segundo paso, el oficial.Gestiona bien el Ahora no
La función debería seguir funcionando de forma reducida, por ejemplo con la introducción manual de una dirección en lugar de la ubicación. Si más adelante el usuario quiere la función y el permiso se denegó de forma definitiva, abre la pantalla del sistema con
settingsapp://(API Open App Settings).Alinea la documentación y vuelve a enviar
Actualiza la política de privacidad y el formulario Data safety para que coincidan. Si solo cambió tu app web, la compilación existente ya muestra la corrección; si la Play Console necesita una versión nueva, sube el version code y carga un bundle nuevo. Describe en tu respuesta el camino hasta la divulgación.
Un helper de divulgación reutilizable
Un patrón para cualquier app web que se ejecute en WebViewGold. Sustituye showModal por tu propio componente de diálogo y adapta los textos a lo que tu app hace de verdad.
javascript
// Cada entrada: lo que le dices al usuario y el paso nativo que se ejecuta después de "Aceptar".
const DISCLOSURES = {
location: {
title: "¿Mostrar tiendas cerca de ti?",
body: "Para mostrarte los puntos de recogida más cercanos, esta app recopila tu ubicación precisa mientras usas el buscador de tiendas. Solo se envía a nuestro servidor para calcular distancias y nunca se comparte con anunciantes.",
run: () => navigator.geolocation.getCurrentPosition(showNearby, showManualSearch)
},
contacts: {
title: "¿Buscar amigos entre tus contactos?",
body: "Esta app sube a nuestro servidor los nombres y números de teléfono de tus contactos para mostrarte qué amigos ya la usan. Nunca escribimos a tus contactos y borramos en 24 horas los números sin coincidencia.",
// Después de conceder el permiso, navega a readcontacts:// para rellenar la variable contacts.
run: () => { window.location.href = "requestcontactpermission://"; }
},
notifications: {
title: "¿Recibir novedades de tus pedidos?",
body: "Te enviamos una notificación cuando tu pedido sale y cuando llega. Puedes desactivarlo cuando quieras.",
run: () => { window.location.href = "registerpush://"; }
}
};
function askWithDisclosure(kind) {
const d = DISCLOSURES[kind];
showModal({
title: d.title,
body: d.body,
primary: { label: "Aceptar", onClick: d.run },
secondary: { label: "Ahora no", onClick: () => {} } // la función sigue funcionando sin ello
});
}
// Lánzalo desde una acción del usuario en la pantalla de la función, nunca al cargar la página.
document.querySelector("#find-stores").addEventListener("click", () => askWithDisclosure("location"));Prompt: deja que tu agente de IA lo implemente
El agente encuentra cada flujo de datos, añade los diálogos y te entrega las frases para la política de privacidad y el formulario Data safety.
Pégalo en Claude Code, Cursor, Codex o el chat de tu builder
Mi app web se ejecuta dentro de una app Android creada con WebViewGold. Google Play la rechazó por falta de divulgación destacada (prominent disclosure). Encuentra cada lugar donde la app (a) llama a navigator.geolocation, (b) navega a requestcontactpermission://, readcontacts:// o registerpush://, (c) sube contactos, fotos o la ubicación a nuestro backend o a un tercero, (d) carga scripts de analítica, de grabación de sesiones o de chat. Para cada elemento: - Elimina cualquier llamada que se ejecute al cargar la página; lánzala en su lugar desde una acción del usuario en la pantalla de la función. - Antes de la llamada, muestra un modal de nuestro sistema de diseño con un título corto, qué datos se recopilan, por qué, adónde se envían y dos botones: Aceptar y Ahora no. - Ejecuta la llamada solo después de Aceptar. Con Ahora no, mantén la función utilizable de forma reducida. - No le des al modal el aspecto de un diálogo del sistema Android. Después escribe una tabla con cada tipo de dato, la pantalla donde se divulga y la frase exacta usada, para que pueda copiarla en la política de privacidad y en el formulario Data safety.
Divulgaciones que siguen siendo rechazadas
- Solo en la política de privacidad, en las condiciones o en la descripción de la ficha.
- Dentro de un onboarding de diapositivas que el usuario puede saltarse sin leer.
- Combinada con las condiciones del servicio detrás de un único botón Aceptar.
- Mostrada después de la solicitud de permiso del sistema en lugar de antes.
- Redacción vaga como "para mejorar tu experiencia" sin nombrar los datos.
- Un banner que desaparece solo, o un diálogo en el que tocar fuera cuenta como un sí.
Preguntas frecuentes
¿No basta con el diálogo de permisos de Android?
No. El diálogo del sistema pide el permiso, pero no dice nada de lo que haces con los datos. Google quiere tu propia explicación antes de él siempre que el uso pueda no ser obvio, y siempre en el caso de la ubicación en segundo plano.
¿Puede la divulgación formar parte de mi app web en lugar de ser código nativo?
Sí. Un diálogo que tu app web muestra dentro del WebView es interfaz de la app. Lo que importa es que aparezca durante el uso normal, justo antes de acceder a los datos, y no solo en una página de ajustes o de textos legales.
¿La divulgación necesita un botón Aceptar explícito?
Cuando la solicitud de permiso de Android aparece justo después, la guía de Google sobre ubicación en segundo plano considera esa solicitud como el paso de consentimiento. Para los datos que no protege ninguna solicitud del sistema, necesitas tu propio consentimiento afirmativo. Un par claro de Aceptar y Ahora no es el diseño más seguro en ambos casos y coincide con las prácticas recomendadas de Google.
¿Muestro la divulgación cada vez?
Muéstrala antes de la primera solicitud de cada tipo de dato y de nuevo cuando el usuario inicie la función después de haberla rechazado. Respeta el rechazo; las solicitudes repetidas molestan tanto a los usuarios como a los revisores.
Mi divulgación está en la política de privacidad y en la ficha de la tienda. ¿Por qué me rechazaron?
Porque la política la exige dentro de la app, antes de acceder a los datos. La política de privacidad y la ficha son requisitos adicionales, no sustitutos.
¿Se aplica lo mismo a mi app de iOS?
Apple lo gestiona de otra manera, con textos de finalidad en la solicitud del sistema y sus propias normas de privacidad. El mismo diálogo en contexto funciona bien en ambas plataformas, y la parte del App Store se explica en la guía de la Directriz 5.1.1.
Tres formas de llevar tu app a las tiendas
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
Hazlo tú mismo
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principalCloud Builder
$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuitaFull Service
$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.