Políticas de Google Play en 2026: lista antes de publicar

Antes de nada, confirma que la cuenta puede publicar

Los problemas más incómodos de Google Play no siempre empiezan con una infracción evidente. A veces la versión está lista y las capturas aprobadas, pero Seguridad de los datos no coincide con un SDK, el enlace de baja exige iniciar sesión o la cuenta de prueba recibe un código que nadie de Google puede consultar. Un detalle pequeño termina reabriendo varias partes del lanzamiento.

Por eso publicar no consiste únicamente en subir un archivo y completar casillas. Las políticas pueden cambiar funciones reales: cómo se elimina una cuenta, cuándo se solicita la ubicación, cómo se venden prestaciones digitales o qué herramientas permiten denunciar contenido. Si esas preguntas aparecen al final, ya no son un trámite; afectan al desarrollo y a la fecha prevista.

Esta guía se revisó el 8 de septiembre de 2026. Google modifica políticas y fechas durante el año, por lo que conviene abrir las fuentes enlazadas antes de cada versión. El método de trabajo, en cambio, es duradero: documentar el comportamiento de la compilación que se va a enviar y hacer que todos los textos y formularios coincidan con ella.

Las cuentas personales nuevas tienen un recorrido distinto. Para las creadas después del 13 de noviembre de 2023, Google exige normalmente una prueba cerrada con al menos 12 personas inscritas durante 14 días consecutivos antes de solicitar el acceso a producción. No se trata de reunir instalaciones el último día. Prepara tareas concretas, recoge comentarios y registra las correcciones; después tendrás que explicar cómo se probó el producto y por qué está listo.

El 31 de agosto de 2026 entra en juego otro requisito. Las aplicaciones nuevas y las actualizaciones para móviles y tabletas deben apuntar, con carácter general, a Android 16, nivel de API 36 o superior. Wear OS y Android Automotive requieren API 35; Android TV y Android XR, API 34. Las aplicaciones antiguas también tienen condiciones de visibilidad. Consulta siempre la página actual de la API de destino antes de cerrar el calendario.

La próxima fase de verificación de desarrolladores de Android comienza el 30 de septiembre de 2026, pero no es un plazo universal para todos los mercados. El despliegue regional empieza en Brasil, Indonesia, Singapur y Tailandia, para tiendas participantes en dispositivos certificados con Android 7 o posterior. La ampliación global está prevista para 2027. Comprueba el estado del paquete en Play Console, sin dar por hecho que el registro automático resolvió todo.

Una sola versión de la verdad para todo el lanzamiento

El origen habitual de los errores no es una mala intención, sino que cada persona recuerda una versión distinta del producto. Desarrollo conoce los permisos, marketing prepara la ficha, otra persona redacta la política y el propietario responde a Seguridad de los datos. Cada pieza parece razonable por separado y, aun así, el conjunto se contradice.

Nos funciona mejor una única ficha de control asociada a la versión candidata, con una persona responsable de cerrarla. No hace falta convertirla en un proceso pesado; basta con reunir estas comprobaciones:

Si se añade una herramienta de analítica o publicidad después de completar la ficha, hay que reabrir la declaración. Si se aplaza una función, también debe desaparecer de la descripción y de las imágenes.

Seguridad de los datos se rellena desde el producto real

La política de privacidad y Seguridad de los datos están relacionadas, pero no son el mismo documento. La primera ofrece una explicación pública y amplia. La segunda resume de forma estructurada qué recopila y comparte la aplicación. Ambas deben partir del código y de la configuración de los servicios externos.

Haz una lista de los datos de alta y acceso, eventos de analítica, informes de fallos, identificadores, ubicación, archivos, conversaciones de soporte y estado de los pagos. Incluye Firebase, atribución, publicidad, chat, mapas y cualquier otro SDK. Google responsabiliza al desarrollador de lo que hacen esas bibliotecas dentro de su aplicación.

Describe también el uso. Un correo empleado únicamente para acceder a la cuenta no equivale a enviarlo a una plataforma comercial. Anota si el dato sale del dispositivo, si es opcional, cómo viaja y cómo se elimina. Guarda el inventario junto a cada versión para no reconstruirlo a partir de recuerdos meses después.

Nuestra guía sobre la política de privacidad de una app explica cómo convertir ese inventario en un documento claro. En salud, finanzas, menores o identificación regulada, debe añadirse una revisión jurídica del mercado concreto.

El borrado de cuenta debe llegar hasta el backend

Si una persona puede crear una cuenta dentro de la aplicación, Google Play pide un camino para solicitar su eliminación desde la propia app y otro mediante una página web indicada en Play Console. Un correo genérico de soporte, difícil de localizar, no sustituye a ese recorrido.

Pruébalo de principio a fin. ¿Se encuentra sin ayuda? ¿La página identifica la aplicación y la empresa? ¿Explica qué se borra y qué puede conservarse durante un plazo determinado? ¿Se eliminan o anonimizan datos en autenticación, almacenamiento, CRM, soporte y herramientas de marketing?

Una compra abierta, una factura o una disputa de marketplace pueden exigir conservar parte de la información. Eso no debe improvisarlo el programador: producto y asesoría determinan el resultado correcto y el equipo técnico lo aplica en todos los sistemas.

Reduce los permisos y solicita cada uno en contexto

Compara el manifiesto, los avisos que ve el usuario y las declaraciones de Play Console. Elimina permisos heredados de bibliotecas o funciones que ya no existen. Para cada permiso sensible, pide al equipo una frase sencilla: «sin este acceso, el usuario no puede hacer X».

Elige la opción de menor alcance. Para adjuntar una imagen suele ser preferible el selector de fotos a un acceso general a la galería. Para invitar a una persona no siempre hace falta leer toda la agenda. El seguimiento continuo de un repartidor puede justificar ubicación persistente; buscar una tienda cercana una sola vez, no.

Google ha anunciado cambios de contactos y ubicación precisa para finales de octubre de 2026, junto con nuevas comprobaciones previas. Los proyectos que apuntan a Android 17 deben revisar con tiempo Contact Picker y el botón de ubicación. Para la protección del almacenamiento, los secretos y los permisos del servidor, consulta el checklist de seguridad Android.

Prepara un acceso que Google pueda reutilizar

Las funciones protegidas por inicio de sesión, suscripción, ubicación o rol deben ser accesibles durante la revisión. Las credenciales han de funcionar desde cualquier país, poder reutilizarse y mantenerse activas. Un código de un solo uso, una prueba caducada o un servidor restringido a la oficina pueden impedir que el equipo de Google compruebe el producto.

No entregues solo usuario y contraseña. Escribe un recorrido corto: cómo entrar, seleccionar el perfil correcto, abrir la función principal, acceder al contenido de pago y realizar una operación de prueba. Google pide las instrucciones en inglés; si la interfaz está en español, añade entre paréntesis el texto exacto de los botones.

Haz que una persona ajena al proyecto siga esas instrucciones en un dispositivo limpio. Si necesita preguntar al desarrollador, todavía no son suficientes.

La ficha debe representar la versión disponible

Las normas de metadatos se aplican a todas las traducciones. El nombre, las descripciones, el icono, el gráfico destacado, las capturas y el vídeo deben mostrar funciones reales. Evita premios sin prueba, afirmaciones imposibles de verificar y repeticiones forzadas de palabras clave.

Las capturas pueden tener un diseño promocional, pero la pantalla y el resultado mostrados deben existir. Localiza el texto de las imágenes y revisa divisa, fechas y condiciones de compra. La guía de capturas para Google Play cubre los formatos; el checklist de localización ayuda a preparar cada mercado.

Una buena revisión editorial intenta demostrar cada frase dentro de la aplicación. Si la ficha dice que un proceso es automático, ¿lo es realmente? Si promete acceso sin límites, ¿hay una restricción posterior? Si existe una suscripción, ¿se entiende precio, periodo y renovación antes de comprar?

Declara la categoría que corresponde a las funciones

Play Console adapta sus preguntas al producto: anuncios, público objetivo, clasificación por edades, noticias, salud, servicios financieros, relación con organismos públicos y otras áreas sensibles. Elegir una etiqueta más cómoda no elimina la obligación; puede crear una declaración falsa.

Las aplicaciones con contenido de usuarios necesitan condiciones, denuncia, bloqueo y una operación real de moderación. Si se incluyen menores, entran las políticas para familias. Salud y finanzas requieren especial cuidado con las afirmaciones. Si se venden bienes o funciones digitales, revisa la política de pagos y las excepciones aplicables antes de decidir un cobro externo.

Estas obligaciones forman parte del alcance. Un chat privado necesita denuncia, bloqueo, visibilidad para soporte y una regla de conservación. Una suscripción requiere restauración, cancelación, estados de acceso y pruebas de compra. El cuestionario de estimación de Appfyl ayuda a descubrir estas dependencias antes de presupuestar.

Prueba el paquete firmado, no solo la versión de desarrollo

Instala exactamente la versión firmada que se va a enviar y con un backend similar al de producción. Comprueba instalación limpia, actualización, alta, recuperación, borrado, permisos rechazados, mala conexión, compra o reserva principal, enlaces profundos y todos los roles proporcionados a Google. Evita que un pago de prueba pueda convertirse por error en un cargo real.

Las comprobaciones previas de Play Console son útiles, pero no cubren toda la política. Para fallos, bloqueos, dispositivos y experiencia, completa esta revisión con el checklist de calidad de Google Play y el plan de pruebas móviles.

Qué hacer durante las 48 horas anteriores

Dos días antes, congela SDK opcionales y nuevas promesas de marketing. El primer día, desarrollo valida paquete, firma, API de destino, permisos, bibliotecas, borrado y cuenta de prueba. Producto revisa compras, roles, moderación y declaraciones especiales. Marketing compara textos e imágenes con la versión instalada.

El segundo día, una persona externa al equipo recorre la aplicación con las instrucciones destinadas a Google. El responsable abre todos los enlaces públicos, vuelve a comparar Seguridad de los datos con los SDK y guarda una copia de las declaraciones. También confirma que la empresa controla la cuenta de publicación y sus accesos.

Reserva margen para la revisión: Google no garantiza una fecha exacta. El checklist de lanzamiento añade analítica, soporte y seguimiento de los primeros días. Si la aplicación ya ha sido rechazada, utiliza la guía para corregir rechazos y responde a la política concreta antes de reenviar.

Un registro de lanzamiento con un ejemplo concreto

Para una app ficticia de reservas, anota compilación, nombre del paquete y fecha de prueba. Escribe un hallazgo verificable: “La eliminación de cuenta funciona en Ajustes, pero el enlace público lleva al inicio de sesión”. Asigna la corrección al responsable web y mantén el punto abierto hasta que la información necesaria sea accesible sin cuenta. Una casilla genérica de “privacidad lista” escondería el fallo.

Haz lo mismo con el acceso del revisor. Registra que una instalación limpia permite abrir una clase de prueba de pago con la cuenta de demostración, sin código de un solo uso ni cobro real. Si un cambio del servidor invalida esa cuenta, la evidencia deja de estar actualizada. Repite la prueba afectada y guarda el nuevo resultado.

La lista ayuda a decidir si enviar la app, pero no garantiza aprobación. Conserva el identificador de la compilación y las incidencias abiertas. Al hablar del proyecto con Appfyl, aclara quién mantendrá estas comprobaciones después de cada cambio.

Preguntas frecuentes