Battery Status API: privacidad y disponibilidad
Qué expone Battery Status API, por qué su compatibilidad es limitada y cómo usar el estado de la batería sin crear un perfil del usuario.
Quieres la documentación estructurada de Huella digital?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Battery Status API puede informar del estado de carga actual del navegador, del nivel de batería y del tiempo estimado de carga o descarga. Es una señal de capacidad opcional y de disponibilidad limitada, no una identidad del dispositivo ni una promesa sobre la duración de una sesión. La aplicación debe detectar la función, conservar un comportamiento predeterminado útil y usar el resultado solo para una decisión reversible y visible para la persona.
Qué proporciona Battery Status API
Cuando el navegador expone navigator.getBattery(), la aplicación puede llamarlo. El BatteryManager devuelto puede exponer charging, level, chargingTime y dischargingTime, además de eventos de cambio. Estos valores describen la observación actual del navegador; no son un inventario del hardware, una garantía exacta de autonomía ni una medición de la salud de la batería.
Los valores pueden cambiar durante la visita y el navegador puede ocultarlos, redondearlos o limitarlos según su política. Trátalos como indicios para la tarea actual. Una página puede posponer una animación opcional o reducir las actualizaciones en segundo plano cuando el dispositivo no está cargando, pero no debe quitar contenido necesario ni inferir quién usa la página.
La falta de compatibilidad es una rama normal
MDN clasifica Battery Status API como de disponibilidad limitada. Una página de producción no puede suponer que exista navigator.getBattery ni que su promesa se resuelva. La compatibilidad puede variar según el navegador, la versión, el contexto y la política del agente de usuario. Detecta el método, gestiona el rechazo y conserva la misma experiencia base cuando no haya datos.
No uses el nombre del navegador como sustituto de la detección de capacidades. Prueba el comportamiento que necesita el producto: la página debe seguir siendo utilizable si falta la API, cambia un valor o falla una solicitud. La guía de capacidades del navegador aplica este mismo enfoque de alternativa primero a otra API opcional.
Toma una decisión pequeña y reversible
Empieza por una experiencia base que funcione sin datos de batería. Si hay un resultado, úsalo para elegir entre pocas políticas, por ejemplo normal o con menos trabajo en segundo plano. Conserva navegación, formularios, alternativas multimedia y controles de accesibilidad. Explica cualquier cambio relevante con lenguaje de producto y deja que la persona elija cuando cambien la transferencia de datos, la calidad o la espera.
El estado de la batería no debe controlar autorización, facturación, recuperación de cuentas ni solicitudes necesarias. El servidor no debe depender de un valor de JavaScript que puede faltar o cambiar entre solicitudes. Si la persona selecciona explícitamente un modo de ahorro de datos o de efectos reducidos, envía esa elección en lugar de los campos brutos de batería.
Límites de privacidad y minimización
Las lecturas de batería pueden contribuir a la identificación por huella cuando se combinan con otras señales. Mantenlas dentro de la decisión que las necesita y descarta los valores brutos después de seleccionar la política. No añadas por defecto level, el estado de carga ni los tiempos a identificadores de cuenta, URL, etiquetas analíticas o registros de soporte duraderos.
Los registros operativos normalmente solo necesitan la política elegida y el resultado, por ejemplo power_policy=reduced y si terminó una tarea opcional. Si un caso de soporte necesita más detalle, explica el propósito, limita el acceso, fija una retención breve y elimina los campos al cerrar el caso. La guía básica de privacidad del navegador trata otras decisiones de minimización.
Prueba la alternativa, no un valor de batería concreto
Las pruebas deben cubrir una API indefinida, el rechazo de getBattery(), cambios en level o charging y un navegador que solo ofrezca la ruta base. Comprueba que el contenido y los controles necesarios sigan disponibles, que el trabajo opcional pueda cancelarse y que la persona pueda recuperarse tras un cambio. No afirmes que un dispositivo concreto debe devolver un porcentaje o tiempo específico.
Respeta la intención y la accesibilidad en todas las ramas. Un modo reducido puede aplazar una vista previa o bajar la frecuencia en segundo plano, pero debe conservar el sentido de la tarea y ofrecer una forma clara de continuar. Evita bucles de reintento y no pidas a la persona que debilite una configuración de privacidad para activar una mejora.
La API describe el estado que observa este contexto, no un contrato del sistema operativo.
El navegador puede devolver un valor algo antiguo o reducir su precisión.
El código debe tolerar que el valor cambie justo después de leerlo.
El comportamiento predeterminado debe ser correcto antes del resultado asíncrono.
Una promesa rechazada y un método ausente significan que la mejora no está disponible.
Ese resultado no debe convertirse en una alerta que bloquee la página.
Al volver a mostrar el documento, puede recalcularse una decisión breve.
No repitas solicitudes continuamente para hacer aparecer una señal ausente.
Un perfil administrado, un marco incrustado o un contexto privado pueden cambiar la disponibilidad.
Describe el comportamiento probado, sin prometer soporte para toda una familia de navegadores.
Si falta una vista previa opcional, el artículo y sus controles deben seguir funcionando.
Una operación larga puede ofrecer pausa o calidad reducida.
Conserva los datos introducidos y permite reanudar de forma segura.
Cuando cambie la carga, reevalúa solo el trabajo opcional afectado.
No cambies contenido o calidad en silencio durante una interacción.
Los informes de errores y los SDK de terceros también pueden copiar campos de batería.
Los eventos que salen de la página deben usar una lista explícita de campos.
Una política de una sola pestaña puede permanecer en memoria.
Continuar con la experiencia normal cuando falta la API reduce la creación de un historial energético.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.