La respuesta corta

Una app de seguro telemático mide cómo conduce el asegurado para ajustar la prima. Suena a problema de sensores y es, sobre todo, un problema de sistema operativo: Android e iOS están diseñados precisamente para impedir que una app recoja ubicación en segundo plano de forma continua.

El dato que decide la arquitectura entera: en Android 8.0 (API 26) y superior, una app en segundo plano recibe actualizaciones de ubicación solo unas pocas veces por hora. No es un problema de permisos ni algo que se arregle con una librería: es una limitación del sistema operativo para preservar batería.

Cualquier diseño que asuma un flujo continuo de posiciones desde segundo plano está mal desde el primer día.

Permisos: el orden importa, y no es negociable

Para apps que apuntan a Android 10 (API 29) o superior, la ubicación en segundo plano exige el permiso ACCESS_BACKGROUND_LOCATION, que es distinto de ACCESS_FINE_LOCATION y ACCESS_COARSE_LOCATION.

Y hay que pedirlo de forma incremental:

  1. Primero ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION.
  2. Solo después de que el usuario conceda la de primer plano, se pide ACCESS_BACKGROUND_LOCATION por separado.

Nunca las dos a la vez. La documentación es explícita: el permiso de segundo plano tiene que ser una petición distinta, para que el usuario entienda la diferencia entre un permiso y el otro.

En producto eso significa dos momentos separados, cada uno con su explicación, y una pantalla intermedia que justifique por qué hace falta el segundo. Es donde se pierde buena parte de los usuarios, y por eso el argumento de valor —lo que gana el asegurado— tiene que estar delante, no en la letra pequeña.

La política de Play: pedirlo no basta

Google restringe el acceso a ubicación en segundo plano a las apps que cumplen tres condiciones:

  • Es crítico para la funcionalidad principal de la app.
  • Ofrece un beneficio claro para el usuario.
  • El uso es evidente para el usuario.

Y un aviso literal que conviene llevar a la reunión de kick-off: seguir estas buenas prácticas no garantiza que Google Play apruebe el uso de ubicación en segundo plano.

Traducción de riesgo: el modelo de negocio de un seguro telemático depende de una aprobación que no controlas. Eso se planifica —con la declaración de uso preparada, el vídeo de demostración y una alternativa si la respuesta es no—, no se descubre en la primera publicación.

Cómo se diseña con esa limitación

El patrón que funciona no es «recoger todo el rato», sino detectar viajes y grabar durante el viaje:

  • Detección de actividad para saber cuándo el usuario probablemente va en coche, en lugar de sondear ubicación permanentemente.
  • Al detectar un viaje, elevar el muestreo con la app en un estado que el sistema permita mantener —con su notificación visible al usuario, que además es lo honesto.
  • Al terminar el viaje, volver al estado de bajo consumo.
  • Procesar y agregar en el dispositivo, y subir el resumen del viaje. Subir cada punto crudo es caro en batería, en datos y en cumplimiento.

Y una decisión de producto que hay que tomar pronto: qué se mide. Frenadas bruscas, aceleraciones, velocidad relativa al límite, uso del teléfono durante la conducción, horario y tipo de vía. Cada métrica añade sensores, consumo y una conversación de privacidad distinta.

Batería: el criterio de aceptación que nadie escribe

En este tipo de producto, el consumo es un requisito funcional, no una optimización posterior. Si la app aparece en la lista de las que más batería gastan, el usuario la desinstala y el modelo de negocio se cae, por muy bien calculada que esté la prima.

Debería estar en el contrato como criterio de aceptación medible, con un objetivo por hora de conducción y una medición reproducible en dispositivos reales de gama media, que es donde duele.

Privacidad: no es un anexo

Los datos de conducción son datos personales, y de los sensibles en la práctica: dicen dónde vive el asegurado, dónde trabaja, a qué hora vuelve a casa y con qué frecuencia sale de noche.

Lo mínimo, y hay que decidirlo antes de escribir código:

  • Base legal del tratamiento y qué pasa si el asegurado la retira.
  • Minimización: si el modelo de prima funciona con agregados por viaje, no se guardan trayectorias completas.
  • Retención: cuánto tiempo, y borrado efectivo al terminar la póliza.
  • Transparencia: que el asegurado pueda ver exactamente lo que se ha recogido de él. Es requisito y además es lo que sostiene la confianza en un producto que, mal explicado, se percibe como vigilancia.

Cuándo no hacerlo

  • Si el modelo actuarial no está listo. Recoger datos «para después decidir qué hacer con ellos» es acumular riesgo de privacidad sin contrapartida.
  • Si no hay un beneficio claro y explicable para el asegurado. Sin eso no pasa la política de Play y, más importante, no pasa la instalación.
  • Si la alternativa es un dispositivo OBD. A veces el hardware en el vehículo resuelve mejor el problema, sin depender de permisos ni de que el móvil esté encendido. Que la solución sea una app es una decisión, no un punto de partida.

Antes de estimar

  1. ¿Qué métricas exige el modelo actuarial, exactamente?
  2. ¿Hay presupuesto de batería y quién lo valida?
  3. ¿Está preparada la declaración de uso de ubicación en segundo plano para Play?
  4. ¿Qué se guarda, cuánto tiempo y quién lo ha aprobado?
  5. ¿Qué pasa con un asegurado que revoca el permiso a mitad de póliza?

La quinta no es hipotética: pasa constantemente, y define el comportamiento del producto y del contrato.

Es el tipo de proyecto que encaja en apps para el sector seguros, donde el reto no es la pantalla sino todo lo que ocurre cuando el teléfono está en el bolsillo.

Fuente primaria, consultada el 14 de agosto de 2026: Access location in the background en la documentación de Android.