Batería y privacidad: el coste real y la percepción del usuario

Las dos preocupaciones que hunden a una aplicación de ubicación son la misma preocupación vista desde dos ángulos: el usuario nota que algo le está costando y no entiende por qué. Si lo nota en la batería, desinstala. Si lo nota en el registro de accesos a su posición, desinstala y además lo cuenta. Ninguna de las dos reacciones se combate con una explicación posterior, porque para cuando llegan el usuario ya ha decidido. Se combaten antes, en el diseño, aceptando que cada fijación de posición y cada muestra de sensor es un cargo contra una cuenta de confianza que se agota mucho más rápido de lo que se rellena.

Medir antes de opinar

El consumo de una funcionalidad de ubicación no se intuye: se mide, y se mide con atribución, porque el dato agregado de la pantalla de batería no distingue quién encendió la radio. Las tres herramientas que importan son complementarias. Battery Historian reconstruye a partir de un volcado de estadísticas la línea temporal de bloqueos de despertar, adquisiciones GNSS y despertares del procesador atribuidos a cada proceso. Perfetto da la traza fina, con la que se ve si el oyente de sensores está impidiendo el reposo profundo. Y la propia pantalla de uso de batería del sistema es la única que refleja lo que el usuario verá, que es en definitiva el número que decide su reacción.

// Reinicia estadisticas, ejercita la funcionalidad y vuelca el resultado
// adb shell dumpsys batterystats --reset
// adb shell dumpsys batterystats --enable full-wake-history
// ... uso real de la aplicacion ...
// adb shell dumpsys batterystats > estadisticas.txt

class Sesion(private val cliente: FusedLocationProviderClient) {
    private var fijaciones = 0
    private var milisEncendido = 0L

    fun registrar(inicio: Long, fin: Long) {
        fijaciones++
        milisEncendido += fin - inicio
        Trace.setCounter("gnss_ms_acumulados", milisEncendido)
    }
}

Hay un atajo que aparece siempre en este punto y que conviene descartar de forma explícita: pedir al usuario la exención de las optimizaciones de batería. Salvo en el puñado de categorías que las tiendas reconocen como legítimas, esa petición es a la vez un motivo de rechazo en la revisión, una señal de alarma para el usuario que la ve en el diálogo del sistema y un parche que no arregla el diseño subyacente. Si una funcionalidad solo sobrevive escapando del planificador, el problema no está en el planificador.

Tres métricas resumen casi todo. El tiempo total con GNSS activo por hora de uso es la dominante, porque el receptor es el componente caro. El número de despertares del procesador atribuidos a la aplicación es la segunda, y explica por qué una cadencia baja mal agrupada puede consumir más que una alta bien agrupada. La tercera es el porcentaje de fijaciones que acabaron produciendo una decisión de producto: si de cada cien posiciones obtenidas noventa se descartan por redundantes o por imprecisas, el problema no es de eficiencia sino de diseño.

La brecha entre consumo y percepción

El usuario no mide, atribuye. Y atribuye mal, con un sesgo perfectamente predecible que conviene conocer porque se puede diseñar en contra de él.

Lo que agranda la brecha es sobre todo la visibilidad sin valor. Una notificación permanente de servicio en primer plano que dice que la aplicación está usando la ubicación es un recordatorio constante de coste; si el usuario no ve simultáneamente el beneficio, atribuirá a esa aplicación cualquier caída de batería del día, tuviera o no la culpa. El indicador de ubicación en la barra de estado hace lo mismo con más fuerza aún: aparece cada vez que se accede a la posición y el usuario lo nota especialmente cuando no está usando la aplicación. El tercer amplificador es el calor, porque un terminal templado se percibe como consumo desbocado con independencia de la cifra real.

Hay además dos mecanismos del sistema que degradan la funcionalidad justo cuando el usuario está más sensible al consumo, y que conviene detectar en lugar de sufrir. El modo de ahorro de energía restringe el trabajo en segundo plano y puede limitar la precisión disponible; el estrangulamiento térmico reduce el rendimiento cuando el terminal se calienta, algo frecuente precisamente durante una navegación prolongada con la pantalla encendida y el dispositivo al sol sobre un salpicadero. Consultar el estado de ahorro y suscribirse al nivel térmico permite que la aplicación reduzca su propia cadencia antes de que el sistema se la reduzca por la fuerza, y sobre todo que explique al usuario por qué lo hace, convirtiendo una degradación silenciosa en una decisión comprensible.

La otra cara es que hay contextos donde el gasto es prácticamente gratis en términos de percepción: mientras el dispositivo está cargando, mientras el usuario tiene la aplicación abierta y mirando un mapa, o durante una actividad que él mismo ha iniciado y cuya duración conoce. Trasladar trabajo a esas ventanas —sincronizaciones diferidas, subidas de histórico, precálculos— es la forma más barata de reducir el coste percibido sin tocar el medido.

flowchart TD
A[acceso a ubicacion] --> B[indicador en barra de estado]
A --> C[registro en panel de privacidad]
A --> D[atribucion en pantalla de bateria]
B --> E[percepcion del usuario]
C --> E
D --> E
E --> F{beneficio visible al mismo tiempo}
F -- si --> G[permiso conservado]
F -- no --> H[revocacion o desinstalacion]
style G fill:#a6e3a1,color:#11111b
style H fill:#f38ba8,color:#11111b

Lo que la plataforma cuenta de ti

Una parte creciente de la relación entre la aplicación y el usuario ocurre en superficies que el desarrollador no controla y sobre las que no puede argumentar. Conviene enumerarlas porque cada una convierte una decisión técnica en una decisión reputacional.

El indicador de la barra de estado se enciende en cada acceso a la posición. El panel de privacidad muestra un histórico por aplicación de accesos a ubicación, cámara y micrófono con marca temporal. Los recordatorios periódicos avisan al usuario de qué aplicaciones tienen acceso permanente y le ofrecen retirarlo con un toque. La revocación automática elimina los permisos de las aplicaciones que no se abren durante meses, y también detiene sus trabajos en segundo plano. La sección de seguridad de los datos en la ficha de la tienda declara públicamente qué se recoge, con qué fin y si se comparte, y esa declaración es contrastable contra el comportamiento observado. A ello se suma la exigencia de divulgación destacada: una explicación propia, previa al diálogo del sistema, para cualquier recogida de ubicación en segundo plano.

Diseñar para el no

El diseño responsable se reconoce por una propiedad simple: la aplicación sigue siendo valiosa cuando el usuario dice que no. Eso implica planear cuatro respuestas distintas antes de escribir el primer diálogo de permisos, porque las cuatro van a ocurrir en producción con volumen significativo.

Con permiso exacto y permanente la aplicación opera en su modo completo. Con permiso exacto solo en uso, las funcionalidades continuas se convierten en manuales o en geofences, y el usuario debe entender qué gana si amplía. Con permiso aproximado, la funcionalidad se reescala a nivel de zona: listados por ciudad, contenido regional, distancias orientativas. Sin permiso alguno, queda la entrada manual, que además conviene ofrecer siempre porque hay usuarios que la prefieren aunque hayan concedido todo.

sealed interface ModoUbicacion {
    data object Completo : ModoUbicacion
    data object SoloEnUso : ModoUbicacion
    data object Aproximado : ModoUbicacion
    data object Manual : ModoUbicacion
}

fun politica(modo: ModoUbicacion): Politica = when (modo) {
    ModoUbicacion.Completo -> Politica(zonas = true, seguimiento = true, precision = ALTA)
    ModoUbicacion.SoloEnUso -> Politica(zonas = false, seguimiento = true, precision = MEDIA)
    ModoUbicacion.Aproximado -> Politica(zonas = false, seguimiento = false, precision = BAJA)
    ModoUbicacion.Manual -> Politica(zonas = false, seguimiento = false, precision = NINGUNA)
}

Modelar los modos como un tipo cerrado y derivar de él la política tiene una virtud que va más allá de la elegancia: obliga a que cada nueva funcionalidad declare explícitamente cómo se comporta en los cuatro escenarios, en lugar de asumir el mejor y fallar en silencio en los otros tres.

El embudo de permisos merece además instrumentación propia, porque es donde el diseño se valida o se refuta con datos. Interesan cuatro cifras: cuántos usuarios llegan a ver la pantalla de justificación, cuántos aceptan abrir el diálogo del sistema, cuántos conceden y en qué grado, y cuántos revocan después. Una tasa de concesión baja no significa que los usuarios sean reticentes, significa que se les pidió antes de haberles demostrado nada; una tasa de revocación alta semanas más tarde significa que el beneficio prometido no se materializó en su experiencia diaria. Ambas son señales de producto, no de plataforma, y ambas se corrigen moviendo la petición más cerca del momento en que el usuario ya quiere el resultado.

Conviene también aceptar que la retirada del acceso no es un caso de error sino un estado ordinario del sistema. Una aplicación que no se abre durante meses pierde sus permisos por revocación automática, y sus trabajos programados se detienen. El código que asume que un permiso concedido en la instalación sigue vigente en cada ejecución fallará, tarde o temprano, en un dispositivo real; la comprobación debe hacerse en el punto de uso, siempre, y el camino de recuperación debe ser tan cuidado como el de la primera concesión.