Actualizaciones de ubicación: prioridad, primer plano y segundo plano

Pedir una posición es una transacción; pedir un flujo de posiciones es un contrato de largo plazo con el sistema operativo, y ese contrato tiene cláusulas que el desarrollador no negocia. El sistema decide cuándo despertar la radio, cuándo agrupar entregas, cuándo estrangular la cadencia hasta unas pocas veces por hora y cuándo cortar del todo porque la aplicación no tiene derecho a seguir mirando. Escribir bien un LocationRequest consiste en expresar la necesidad real con la máxima honestidad posible, para que el planificador del sistema pueda ser generoso donde importa y tacaño donde no.

El contrato: prioridad, intervalos y agrupamiento

Un LocationRequest no ordena nada, declara. Cada parámetro es una pista que el planificador de ubicación usa para amortizar trabajo entre todos los clientes del dispositivo, y por eso el sistema puede entregar más rápido de lo pedido si otra aplicación ya estaba pagando la fijación, o más lento si el entorno no colabora.

La prioridad selecciona qué fuentes se permite encender. PRIORITY_HIGH_ACCURACY autoriza el GNSS y es la única adecuada para navegación o registro de rutas. PRIORITY_BALANCED_POWER_ACCURACY se queda en el orden de la decena de metros apoyándose en redes y en fijaciones oportunistas, y es el valor por defecto correcto para casi todo lo demás. PRIORITY_LOW_POWER opera a escala de manzana o barrio, y PRIORITY_PASSIVE no enciende absolutamente nada: se limita a escuchar las posiciones que otras aplicaciones ya provocaron, lo que la convierte en la opción de coste marginal cero para funcionalidades oportunistas.

Los tiempos son tres y se confunden con facilidad. El intervalo principal es la cadencia deseada. setMinUpdateIntervalMillis es el suelo: la entrega más rápida que la aplicación es capaz de procesar, y protege de la ráfaga que llega cuando otro cliente está pidiendo alta frecuencia. setMaxUpdateDelayMillis es la palanca energética más rentable de toda la API, porque autoriza al sistema a acumular varias posiciones y entregarlas juntas en un único despertar del procesador.

val peticion = LocationRequest.Builder(
    Priority.PRIORITY_BALANCED_POWER_ACCURACY,
    TimeUnit.SECONDS.toMillis(30),
)
    .setMinUpdateIntervalMillis(TimeUnit.SECONDS.toMillis(10))
    .setMinUpdateDistanceMeters(25f)
    .setMaxUpdateDelayMillis(TimeUnit.MINUTES.toMillis(2))
    .setWaitForAccurateLocation(false)
    .build()

El filtro por distancia mínima merece atención aparte: suprime entregas mientras el usuario permanece quieto, que es exactamente el caso en el que las actualizaciones periódicas son puro desperdicio. Y setWaitForAccurateLocation en falso indica que se prefiere una primera posición mediocre pronto a una excelente tarde, lo cual casi siempre es lo que la interfaz necesita para dejar de mostrar un indicador de carga.

flowchart TD
A[LocationRequest] --> B{app visible}
B -- si --> C[cadencia solicitada]
B -- no --> D{servicio en primer plano tipo location}
D -- si --> C
D -- no --> E[estrangulado a unas pocas por hora]
C --> F[callback o PendingIntent]
E --> F
style C fill:#a6e3a1,color:#11111b
style E fill:#f38ba8,color:#11111b

Primer plano: ciclo de vida y entrega

En primer plano la regla es simple y estricta: las actualizaciones se registran cuando la interfaz es visible y se retiran cuando deja de serlo. Una suscripción huérfana es una fuga de batería que sobrevive a la pantalla y que ninguna herramienta señala como error.

private val callback = object : LocationCallback() {
    override fun onLocationResult(resultado: LocationResult) {
        resultado.locations
            .filter { it.hasAccuracy() && it.accuracy < 50f }
            .forEach { procesar(it) }
    }

    override fun onLocationAvailability(disponibilidad: LocationAvailability) {
        if (!disponibilidad.isLocationAvailable) mostrarSinSenal()
    }
}

override fun onStart() {
    super.onStart()
    cliente.requestLocationUpdates(peticion, callback, Looper.getMainLooper())
}

override fun onStop() {
    super.onStop()
    cliente.removeLocationUpdates(callback)
}

Dos detalles del fragmento son estructurales. El primero es que onLocationResult recibe una lista, no una posición: cuando el sistema agrupa entregas llegan varias de golpe, y el código que solo lee la última descarta información ya pagada. El segundo es onLocationAvailability, la única señal fiable de que el dispositivo ha perdido la capacidad de fijar posición; sin ella la interfaz se queda congelada en el último punto conocido sin poder explicar por qué.

En capas modernas conviene envolver la suscripción en un flujo frío que se registre al primer coleccionista y se desregistre al último, de modo que el ciclo de vida deje de ser responsabilidad de cada pantalla.

Segundo plano: estrangulamiento, servicio tipificado y permiso en dos pasos

Cuando la aplicación deja de ser visible, el sistema aplica un límite duro a las actualizaciones de las aplicaciones en segundo plano, del orden de unas pocas entregas por hora, con independencia de lo que pida el LocationRequest. Es una decisión deliberada de plataforma, no un fallo, y no se puede eludir con trucos.

Solo hay dos vías legítimas para recibir posición continua sin interfaz visible. La primera es un servicio en primer plano con tipo location declarado, lo que implica una notificación permanente y visible, el permiso FOREGROUND_SERVICE_LOCATION en el manifiesto y, desde Android 14, que el servicio se inicie desde un contexto válido. La segunda es no pedir un flujo, sino suscribirse a eventos: geofences o transiciones de actividad, que el sistema evalúa con hardware de bajo consumo y entrega solo cuando ocurre algo relevante.

En el manifiesto eso se traduce en declarar el permiso FOREGROUND_SERVICE_LOCATION y marcar el servicio con el atributo foregroundServiceType con valor location. En el código, el servicio debe promoverse a primer plano de inmediato y con el tipo correcto, o el sistema lo aborta:

class SeguimientoService : Service() {

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        ServiceCompat.startForeground(
            this,
            ID_NOTIFICACION,
            construirNotificacion(),
            ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION,
        )
        cliente.requestLocationUpdates(peticion, callback, Looper.getMainLooper())
        return START_STICKY
    }

    override fun onDestroy() {
        cliente.removeLocationUpdates(callback)
        super.onDestroy()
    }
}

El permiso ACCESS_BACKGROUND_LOCATION es aparte y tiene su propio protocolo. Desde Android 11 no puede solicitarse en el mismo diálogo que los permisos de primer plano: hay que obtener antes el permiso en uso, explicar después con la interfaz de la aplicación por qué se necesita el acceso permanente, y solo entonces lanzar la petición, que abre los ajustes del sistema donde el usuario debe elegir explícitamente la opción de permitir siempre.