Google Play rechaza tu app Flutter por seguridad de los datos: qué declaran tus SDK y cómo reenviar

Imagen ilustrativa: Unsplash

Si Google Play te rechazó la app por la sección de seguridad de los datos, el fallo casi nunca está en lo que escribiste tú. Está en lo que recogen los SDK que instalaste. Una app Flutter con Firebase arrastra el SDK de Firebase Installations de forma transitiva, y eso genera un identificador de instalación. Declarar que tu app no recopila ningún dato es, en ese caso, una declaración falsa, y es la discrepancia número uno entre lo declarado y el comportamiento real. Antes de volver a enviar, abre la guía de divulgación de datos de Firebase y mapea SDK por SDK.

Dos fechas que conviene mirar antes que el rechazo

Hay dos plazos activos que pueden estar bloqueándote por motivos que no tienen nada que ver con el formulario, y merece la pena descartarlos primero.

El primero ya venció. Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones para móvil deben apuntar a Android 16, nivel de API 36 o superior. Si no cumples, la subida queda bloqueada en Play Console. Hay una prórroga solicitable que llega hasta el 1 de noviembre de 2026.

El segundo está a la vuelta de la esquina: el 30 de septiembre de 2026 vence el registro obligatorio de los nombres de paquete en Play Console. Las apps no registradas se retiran de Google Play. Es un requisito independiente del formulario de datos, pero si coincide en el tiempo con tu reenvío, vas a creer que el rechazo es por otra cosa. Compruébalo en tu consola antes de seguir.

Qué pregunta realmente el formulario

La sección de seguridad de los datos vive en la página de contenido de la app y se muestra en tu ficha antes de que el usuario instale. Pregunta cuatro cosas:

1. Si la app recopila datos, entendiendo recopilar como transmitirlos fuera del dispositivo del usuario.
2. Si la app comparte datos, entendiendo compartir como transferirlos a un tercero.
3. Por cada tipo de dato, si la recopilación es obligatoria u opcional y con qué propósito: funcionalidad, analíticas, comunicaciones del desarrollador, publicidad, prevención de fraude, personalización o gestión de cuentas.
4. Dos prácticas de seguridad: si todos los datos van cifrados en tránsito y si ofreces una vía para que el usuario solicite su eliminación.

Hay excepciones que no hay que declarar y conviene conocerlas para no inflar el formulario: datos procesados solo en el dispositivo, datos cifrados de extremo a extremo que tú no puedes leer, transferencias a proveedores que procesan por tu cuenta, peticiones legales, compartición iniciada por el usuario con divulgación destacada y datos completamente anonimizados. Ojo con el matiz: los datos seudónimos que puedan reasociarse razonablemente con un usuario sí hay que declararlos.

Y sobre la frecuencia de revisión, hay un malentendido extendido. Google no impone una revisión anual. Lo que exige es que las respuestas sean exactas y completas en todo momento, y que actualices cuando cambien tus prácticas de datos. Es una obligación continua, no periódica.

Qué declara cada SDK que ya tienes instalado

Esta es la tabla que resuelve la mayoría de los rechazos. Todos estos datos salen de las guías oficiales de divulgación que publican Firebase y Google para la sección de seguridad de datos:

SDK	Qué recoge sin que escribas código	Tipos a declarar	Comparte con terceros
Firebase Analytics	ID de instancia, ID de publicidad, IP enmascarada, compras dentro de la app, vistas de pantalla y sesiones	Identificadores, actividad en la app, ubicación aproximada, información financiera si hay compras	No
Crashlytics	Trazas de pila, estado de la app al fallar, metadatos del dispositivo, UUID de instalación	Información y rendimiento de la app, identificadores	No
Cloud Messaging	Versión de la app, agente de usuario de Firebase y, por dependencia, el ID de instalación	Identificadores	No
Firebase Auth	Dirección IP, agente de usuario, ID de app y de usuario. Según configuración, nombre, correo y teléfono	Información personal, ubicación aproximada, identificadores	No
Google Mobile Ads	Dirección IP, interacciones con el producto, diagnósticos, ID de publicidad e identificadores de cuenta	Identificadores, actividad en la app, ubicación aproximada, rendimiento	Sí. Hay que marcar Shared con propósito publicitario
In-App Messaging	Impresiones, clics y descartes, más propiedades de segmentación	Actividad en la app, y todo lo de Analytics porque lo arrastra como dependencia obligatoria	No

La diferencia que más rechazos causa está en la última columna. Firebase recopila pero no comparte con terceros, salvo subprocesadores. Google Mobile Ads sí comparte. Si tienes AdMob y solo marcaste Collected, tu declaración está incompleta. Para todos los SDK de Firebase, además, el cifrado en tránsito se declara como sí, porque usan HTTPS, y la eliminación de datos también, porque Firebase permite borrar datos del usuario final.

Un aviso de la propia documentación de Firebase que se pasa por alto: la guía cubre solo la última versión de cada SDK. Cuando actualices versiones, toca revisar la declaración.

El permiso AD_ID que entra sin que lo declares

Las apps que apuntan a Android 13 o superior deben declarar el permiso de identificador de publicidad en el manifiesto. En Flutter esto se complica porque, según la propia documentación de Google, algunos SDK incluyen ese permiso automáticamente por fusión de manifiestos, aunque tú no lo escribas. Los candidatos habituales son los paquetes de anuncios y de analíticas.

El resultado es un desajuste: el permiso está en el manifiesto final del bundle, pero tu declaración en Play Console dice que la app no usa identificador de publicidad. Play Console avisa y la revisión falla. La comprobación correcta es abrir el manifiesto fusionado del build de release, no el del proyecto.

Tres cosas tienen que coincidir o hay rechazo: el manifiesto final, la declaración de publicidad y de identificador en contenido de la app, y la sección de seguridad de los datos con identificadores marcados como recopilados y compartidos.

La política de privacidad, que suspende por detalles tontos

Los requisitos son más estrictos de lo que parece. La URL tiene que estar activa, ser públicamente accesible, no tener geobloqueo y no ser un PDF. Tiene que ser no editable por terceros, lo que descarta un documento compartido con permisos abiertos. Debe incluir el nombre de la app o de la empresa tal como figuran, información de contacto de privacidad, los tipos de datos tratados, los terceros que los reciben y las políticas de retención y eliminación. Y tiene que estar enlazada tanto en Play Console como dentro de la propia app.

El requisito que más gente descubre tarde es el de eliminación de cuenta. Si tu app permite crear una cuenta desde dentro, necesitas dos vías: una ruta dentro de la app para borrarla, y un enlace web accesible sin necesidad de reinstalar la app. Ese enlace debe referenciar el nombre del desarrollador o de la app tal como aparecen en Play Store, e indicar cancelaciones previas necesarias y políticas de retención. Congelar o desactivar la cuenta no cumple: hay que borrar los datos asociados. Las prórrogas de este requisito terminaron el 31 de mayo de 2024, así que hoy se aplica sin margen.

Cómo corregir y reenviar sin empeorarlo

1. Lee en la notificación qué política concreta se cita. No asumas: el mensaje nombra la política exacta.
2. Audita el manifiesto fusionado del build de release y quita los permisos que no uses. En Flutter entran solos por los plugins.
3. Mapea cada SDK con su guía oficial de divulgación y rehaz el formulario completo, no solo la parte señalada.
4. Verifica la política de privacidad desde una ventana de incógnito y desde otro país si puedes, para descartar geobloqueo.
5. Sube el bundle corregido y, esto es importante, desactiva los bundles no conformes antes de reenviar. La versión infractora tiene que aparecer como no incluida en la nueva versión.
6. Actualiza todos los canales de publicación, producción y pruebas, no solo producción.
7. Envía y no toques nada más.

El último punto no es una recomendación de estilo. El plazo de revisión se cuenta desde el último cambio enviado, así que cada retoque que hagas mientras esperas reinicia el contador. El procesamiento puede tardar desde unas horas hasta siete días, o más en casos excepcionales, y Google recomienda dejar al menos una semana de colchón. Si tu rechazo implica un permiso de alto riesgo con formulario de declaración, el plazo se mide en semanas, no en días.

Una buena noticia que casi nadie sabe: un rechazo no es un strike. En la escala oficial, el rechazo significa que esa versión no se publica, la anterior sigue en la tienda y el estado de tu cuenta no se ve afectado. Los strikes vienen de las suspensiones, que llegan tras infracciones graves o rechazos y retiradas repetidos. Un rechazo aislado y corregido no te pone en riesgo.

Veredicto crítico

La sección de seguridad de los datos es una buena idea mal repartida. La intención, que el usuario sepa qué recoge una app antes de instalarla, es correcta y hacía falta. El problema es a quién se le pasa la factura: Google exige al desarrollador que declare con exactitud el comportamiento de SDK que no escribió, cuyo código no ve y cuyo comportamiento cambia entre versiones. Y luego publica las guías de divulgación en siete páginas distintas, una por producto.

Para un estudio pequeño esto es una carga real. Cada actualización de una dependencia es, técnicamente, un motivo para revisar el formulario. En la práctica nadie lo hace hasta que llega el rechazo, y el rechazo llega en el peor momento posible, con la versión lista y una fecha comprometida.

Cuándo esto es manejable: si usas pocos SDK y los documentas una vez, el formulario se rellena en una tarde y se mantiene solo. Cuándo se vuelve un problema: apps con monetización publicitaria, varios proveedores de analíticas y plugins de terceros que no publican guía de divulgación. Ahí lo que toca es reducir dependencias, no rellenar mejor el formulario. La mejor defensa contra un rechazo por datos es no tener SDK que no puedas explicar.

Y un consejo operativo que vale más que todo lo anterior: usa las comprobaciones previas a la revisión de Play Console antes de enviar. Detectan declaraciones obligatorias que faltan y te obligan a corregir los problemas críticos antes de que un revisor los vea. Es gratis y te ahorra el ciclo completo de rechazo y reenvío.

Sigue leyendo

• Firebase App Check bloquea tus peticiones, la otra cara del mismo stack: qué pasa cuando la atestación rechaza tus builds.
• Error 429 en la API de Gemini, si la app depende de una API con cuotas y se apaga a media jornada.
• Servidor MCP configurado pero no aparece en el cliente, diagnóstico paso a paso de una herramienta que no carga.
• El resto está en el índice de guías prácticas.

Fuentes

Sección de seguridad de los datos de Google Play: support.google.com. Declaración del uso de datos y categorías: developer.android.com. Guía oficial de divulgación de datos de Firebase, SDK por SDK: firebase.google.com. Divulgación de datos de Google Mobile Ads: developers.google.com. Requisitos de eliminación de cuenta: eliminación de cuenta. Política de datos del usuario y requisitos de la política de privacidad: política de datos. Identificador de publicidad y fusión de manifiestos: advertising ID. Requisitos de nivel de API objetivo y fechas: target API. Proceso de aplicación de políticas y escala de sanciones: enforcement. Plazos de revisión y publicación: plazos de revisión.