Google cambia la forma de pedir ubicación precisa en Android, y el cambio tiene fecha. Desde el 27 de enero de 2027, el acceso puntual a ubicación precisa deja de pasar por el diálogo de permiso clásico y pasa por el nuevo botón de ubicación. Si tu app necesita ubicación de forma continua (navegación paso a paso, fitness, reparto, flota), puedes seguir pidiéndola, pero tendrás que justificarlo con una declaración en Play Console. Y si la pedías para alimentar publicidad o analítica, esa puerta se cierra.
La parte incómoda para quien trabaja con Flutter: el botón es una pieza nativa de Android, no un cambio de una línea en permission_handler. Repasemos qué entra en vigor, a quién afecta de verdad y qué revisar en tu AndroidManifest.xml esta semana en lugar de en enero.
Qué cambia, con fechas
En abril de 2026, Google publicó una tanda de cambios en permisos sensibles. El de contactos ya lo cubrimos; este es el gemelo de ubicación, de la misma actualización y con el mismo plazo.
El texto oficial es escueto: "the location button is now the recommended minimum scope for apps requiring precise location. This update aligns with our sensitive permissions requirements and data minimization standards." Traducido: para la ubicación precisa, el mínimo que Google espera es el botón, y lo encuadra en minimización de datos.
Las fechas que importan:
- 15 de abril de 2026: Google anuncia el cambio.
- 27 de octubre de 2026: empiezan las comprobaciones previas a la revisión en Play Console. Avisos, todavía no bloqueos.
- 27 de enero de 2027: el plazo que figura en la página de Policy Deadlines de Google.
La palabra "recommended" del texto oficial se queda corta respecto a la letra pequeña. Para el acceso puntual, el blog de Android habla de requerir el botón salvo que la app necesite ubicación persistente. Para el caso de uso de una sola vez, el botón no es una sugerencia.
Qué es el botón de ubicación
Es un control nativo que sustituye el diálogo de permiso por un único toque, pensado para acciones de una sola vez: encontrar la tienda más cercana, etiquetar una foto, autocompletar una dirección. El usuario decide cuánta ubicación comparte y durante cuánto tiempo, sin pasar por la pantalla de permisos de siempre. En apps que apuntan a Android 17 o superior y usan ubicación precisa para acciones puntuales, Google indica declararlo con un flag específico (onlyForLocationButton) en el manifest.
La idea de fondo lleva años en Android: que una app que solo necesita saber dónde estás una vez no acabe con permiso para seguirte todo el día.
La pregunta que decide tu trabajo: puntual o continua
Casi todo depende de una distinción. Clasifica cada punto de tu app donde pides ubicación en una de dos cajas.
Ubicación puntual. La pides, la usas una vez y no la necesitas más: el "usar mi ubicación" de un buscador de tiendas, rellenar una dirección, un check-in. Aquí el camino es el botón. No pidas ACCESS_FINE_LOCATION de forma persistente para esto.
Ubicación continua. La necesitas mientras el usuario usa la función: navegación, registro de una ruta de running, seguimiento de un reparto. Aquí mantienes el permiso de ubicación precisa, pero tienes que enviar la Play Developer Declaration en Play Console justificando el caso de uso. El formulario lleva disponible desde antes de octubre.
| Caso de uso | Qué hacer |
|---|---|
| Ubicación una sola vez (tienda cercana, autocompletar dirección) | Migrar al botón de ubicación |
| Ubicación precisa continua (navegación, fitness, reparto) | Mantener el permiso y enviar la declaración |
Ubicación en segundo plano (ACCESS_BACKGROUND_LOCATION) | Declaración propia, ya obligatoria desde antes |
| Ubicación solo para publicidad o analítica | Quitarla |
Hay una tercera pregunta que mucha gente se salta: ¿necesitas precisa o te vale aproximada? Si con ACCESS_COARSE_LOCATION resuelves el caso (una ciudad, un radio amplio), pide aproximada y te ahorras medio problema. La minimización de datos no es un eslogan de la política; es la forma más barata de pasar la revisión.
Qué significa esto para una app Flutter
Aquí está el detalle que no verás en la nota de Google. El botón de ubicación es nativo de Android. Los paquetes que usas casi seguro (geolocator, permission_handler) piden el permiso directamente contra el sistema; no envuelven el botón. Integrarlo es trabajo de platform channel y vista nativa, o esperar a que alguien lo empaquete en pub.dev. Antes de prometerle a nadie que esto es un cambio de una tarde, comprueba el soporte real en la versión de los plugins que uses.
La buena noticia: lo que tienes que hacer ya mismo no depende del botón. El inventario, la reclasificación de cada permiso y la declaración para los usos continuos los puedes hacer hoy, con tu stack actual. El botón es el último paso, y solo para los flujos puntuales.
Checklist antes de enero
- Inventaria. Busca
ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATIONyACCESS_BACKGROUND_LOCATIONen tuAndroidManifest.xml, y cada llamada a ubicación en tu código Dart. Apunta en qué pantalla y para qué. - Clasifica cada uso: puntual o continuo, preciso o aproximado, función real o publicidad/analítica.
- Para los puntuales, planifica la migración al botón o la bajada a aproximada. Si era una dirección, mira si el autocompletado te sirve sin pedir ubicación.
- Para los continuos legítimos, redacta y envía la Play Developer Declaration. No lo dejes para la cola de enero.
- Borra cualquier permiso de ubicación que solo alimente publicidad o analítica. Ese es el que te tumba la revisión y no te aporta función.
- Revisa la divulgación destacada antes del prompt. Sigue siendo requisito y es de lo que más rechazos genera.
- Pásalo por las comprobaciones previas de Play Console desde finales de octubre. Un aviso en octubre es gratis; un rechazo en enero te para una release.
Cuándo no tienes que preocuparte
Si tu app no toca ubicación, esto no va contigo. Si solo usas aproximada, ya estás en el lado bueno de la minimización y te queda confirmar que el caso es legítimo. Y si tienes un uso continuo de verdad (una app de reparto no puede funcionar sin seguir al repartidor), no hay nada que arreglar en el producto: toca declararlo bien y defender el caso. La política no te prohíbe la ubicación precisa; te pide que no la pidas por defecto cuando no la necesitas.
Donde sí conviene mirar con calma es en las apps que arrastran un ACCESS_FINE_LOCATION de hace años "por si acaso", o para un SDK de terceros que ya nadie recuerda por qué está. Ese es el patrón que esta política persigue, y el más barato de limpiar ahora.
En Dribba mantenemos apps Flutter en producción y pasamos revisiones de store cada semana; somos Flutter Partner oficial de Google desde 2017. Si quieres que revisemos qué permisos pide tu app y qué toca antes de enero, hablamos.
