Google es consciente de que el consumo excesivo de batería es una de las principales preocupaciones de los usuarios de Android, por lo que ha tomado medidas importantes para ayudar a los desarrolladores a crear aplicaciones más eficientes. El 1 de marzo del 2026, Google Play Store empezó a implementar los tratamientos técnicos de calidad de los wake lock para mejorar el consumo de batería. Este tratamiento se implementará de forma gradual en las aplicaciones afectadas durante las próximas semanas. Las aplicaciones que superen de forma constante el umbral "Wake lock parcial excesivo" en Android vitals pueden experimentar un impacto tangible en su presencia en Google Play Store, como advertencias en su ficha de Play Store y la exclusión de superficies de descubrimiento, como las recomendaciones.

Si tu aplicación supera el umbral de mal funcionamiento, es posible que los usuarios vean una advertencia en tu ficha de Play Store. 

Esta iniciativa ha elevado la eficiencia de la batería a una métrica vital principal junto con las métricas de estabilidad, como los fallos y los errores ANR. El "umbral de mal funcionamiento" se define como mantener un wake lock parcial no exento durante al menos dos horas de media mientras la pantalla está apagada en más del 5% de las sesiones de usuario en los últimos 28 días. Se excluye un wake lock si se trata de un wake lock mantenido por el sistema que ofrece ventajas claras a los usuarios que no se pueden optimizar más, como la reproducción de audio, el acceso a la ubicación o la transferencia de datos iniciada por el usuario. Puedes consultar la definición completa de los wake locks excesivos en nuestra documentación de Android vitals.

Como parte de nuestra iniciativa para mejorar la duración de la batería en todo el ecosistema Android, hemos analizado miles de aplicaciones y cómo usan los bloqueos de activación parciales. Aunque a veces son necesarios, a menudo vemos que las aplicaciones los mantienen de forma ineficiente o innecesaria, cuando existen soluciones más eficientes. En esta entrada de blog se describen los casos más habituales en los que se producen bloqueos de activación excesivos y nuestras recomendaciones para optimizar los bloqueos de activación.  Ya hemos visto resultados medibles en partners como WHOOP, que ha aprovechado estas recomendaciones para optimizar su comportamiento en segundo plano.

Usar un servicio en primer plano frente a los bloqueos de activación parcial

A menudo, los desarrolladores tienen dificultades para entender la diferencia entre dos conceptos al ejecutar tareas en segundo plano: servicios en primer plano y bloqueos de activación parciales.

Un servicio en primer plano es una API de ciclo de vida que indica al sistema que una aplicación está realizando una tarea perceptible por el usuario y que no se debe cerrar para liberar memoria, pero no impide automáticamente que la CPU entre en suspensión cuando la pantalla se apaga. Por el contrario, un wake lock parcial es un mecanismo diseñado específicamente para mantener la CPU en funcionamiento incluso cuando la pantalla está apagada. 

Aunque un servicio en primer plano suele ser necesario para continuar una acción del usuario, la adquisición manual de un wake lock parcial solo es necesaria junto con un servicio en primer plano durante la actividad de la CPU. Además, no es necesario que uses un wake lock si ya utilizas una API que mantiene el dispositivo activo. 

Consulta el diagrama de flujo de Elegir la API adecuada para mantener el dispositivo activo para asegurarte de que sabes qué herramienta debes usar para evitar adquirir un wake lock en situaciones en las que no sea necesario.

Bibliotecas de terceros que adquieren bloqueos de activación

Es habitual que una aplicación descubra que se ha marcado porque un SDK de terceros o una API del sistema que actúa en su nombre mantiene bloqueos de activación excesivos. Para identificar y resolver estos bloqueos de activación, te recomendamos que sigas estos pasos:

• Consulta Android vitals: busca el nombre exacto del wake lock infractor en el panel de control de wake locks parciales excesivos. Compara este nombre con las instrucciones de Identificar los bloqueos de activación creados por otras APIs para ver si se ha creado con una API del sistema o una biblioteca Jetpack conocidas. Si es así, puede que tengas que optimizar el uso de la API y consultar las recomendaciones.
• Captura un registro del sistema: si no se puede identificar fácilmente el wake lock, reproduce el problema de wake lock de forma local con un registro del sistema e inspecciónalo con la interfaz de usuario de Perfetto. Puedes consultar más información sobre cómo hacerlo en la sección Depurar otros tipos de bloqueos de activación excesivos de esta entrada de blog.
• Evalúa alternativas: si una biblioteca de terceros ineficiente es la responsable y no se puede configurar para que respete la duración de la batería, plantéate comunicar el problema a los propietarios del SDK, buscar un SDK alternativo o desarrollar la función internamente.

Situaciones habituales de wake lock

A continuación, se desglosan algunos de los casos prácticos específicos que hemos analizado, junto con la forma recomendada de optimizar la implementación de los wake lock.

Subida o descarga iniciada por el usuario

Ejemplos de casos prácticos: 

• Aplicaciones de streaming de vídeo en las que el usuario activa la descarga de un archivo grande para acceder a él sin conexión.
• Aplicaciones de copia de seguridad de contenido multimedia en las que el usuario activa la subida de sus fotos recientes a través de una notificación.

Cómo reducir los bloqueos de activación: 

• No adquieras un wake lock manual. En su lugar, usa la API de transferencia de datos iniciada por el usuario (UIDT). Esta es la ruta designada para las tareas de transferencia de datos de larga duración iniciadas por el usuario y está exenta de cálculos excesivos de wake lock.

Sincronizaciones en segundo plano únicas o periódicas

Ejemplos de casos prácticos: 

• Una aplicación realiza sincronizaciones periódicas en segundo plano para obtener datos y poder acceder a ellos sin conexión. 
• Aplicaciones de podómetro que obtienen el recuento de pasos periódicamente.

Cómo reducir los bloqueos de activación: 

• No adquieras un wake lock manual. Usa WorkManager configurado para tareas únicas o periódicas. WorkManager respeta el estado del sistema agrupando las tareas y tiene un intervalo periódico mínimo (15 minutos), que suele ser suficiente para las actualizaciones en segundo plano. 
• Si identificas wake locks creados por WorkManager o JobScheduler con un uso elevado de wake locks, puede deberse a que has configurado incorrectamente tu trabajador para que no se complete en determinadas situaciones. Analiza los motivos por los que se detiene el trabajador, sobre todo si se produce con frecuencia el error STOP_REASON_TIMEOUT. 

  workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Además de registrar los motivos por los que se detienen los trabajadores, consulta nuestra documentación sobre depuración de trabajadores. También puedes recoger y analizar rastreos del sistema  para saber cuándo se adquieren y se liberan los bloqueos de activación.
• Por último, consulta nuestro caso de éxito con WHOOP, donde pudieron descubrir un problema con la configuración de sus trabajadores y reducir significativamente el impacto de los wake lock.

Comunicación Bluetooth

Ejemplos de casos prácticos: 

• La aplicación del dispositivo complementario pide al usuario que empareje su dispositivo externo Bluetooth.
• La aplicación del dispositivo complementario escucha los eventos de hardware en un dispositivo externo y los cambios visibles para el usuario en las notificaciones.
• El usuario de la aplicación del dispositivo complementario inicia una transferencia de archivos entre el dispositivo móvil y el dispositivo Bluetooth.
• La aplicación del dispositivo complementario realiza actualizaciones de firmware ocasionales en un dispositivo externo a través de Bluetooth.

Cómo reducir los bloqueos de activación: 

• Usa la emparejamiento de dispositivos complementarios para emparejar dispositivos Bluetooth y evitar que se adquiera un wake lock manual durante el emparejamiento por Bluetooth. 
• Consulta las directrices sobre  comunicación en segundo plano para saber cómo realizar la comunicación por Bluetooth en segundo plano. 
• A menudo, basta con usar WorkManager si la comunicación retrasada no afecta a los usuarios. Si se considera necesario un wake lock manual, solo se debe mantener el wake lock durante la actividad de Bluetooth o el procesamiento de los datos de actividad.

Seguimiento ubicación

Ejemplos de casos prácticos: 

• Aplicaciones de actividad física que almacenan en caché datos de ubicación para subirlos más tarde, como las que trazan rutas de running
• Aplicaciones de reparto de comida que obtienen datos de ubicación con una frecuencia alta para actualizar el progreso del reparto en una notificación o en la interfaz de usuario de un widget.

Cómo reducir los bloqueos de activación: 

• Consulta nuestras directrices para optimizar el uso de la ubicación. Para ahorrar batería, te recomendamos que implementes tiempos de espera, aproveches el envío por lotes de solicitudes de ubicación o utilices actualizaciones de ubicación pasivas.
• Cuando solicitas actualizaciones de ubicación mediante las APIs FusedLocationProvider o LocationManager, el sistema activa automáticamente el dispositivo durante la retrollamada del evento de ubicación. Este breve wake lock gestionado por el sistema está exento de los cálculos de wake locks parciales excesivos.
• Evita adquirir un wake lock continuo independiente para almacenar en caché los datos de ubicación, ya que es redundante. En su lugar, persiste los eventos de ubicación en la memoria o en el almacenamiento local y aprovecha WorkManager para procesarlos a intervalos periódicos.

  override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Monitorización de sensores de alta frecuencia

Ejemplos de casos prácticos: 

• Aplicaciones de podómetro que recogen de forma pasiva los pasos o la distancia recorrida. 
• Aplicaciones de seguridad que monitorizan los sensores del dispositivo para detectar cambios rápidos en tiempo real y ofrecer funciones como la detección de accidentes o caídas.

Cómo reducir los bloqueos de activación: 

• Si usa SensorManager, reduzca el uso a intervalos periódicos y solo cuando el usuario haya concedido acceso explícitamente a través de una interacción con la interfaz de usuario. La monitorización de sensores de alta frecuencia puede agotar la batería rápidamente debido al número de activaciones de la CPU y al procesamiento que se produce.
• Si quieres monitorizar el número de pasos o la distancia recorrida, en lugar de usar SensorManager, aprovecha la API Recording o utiliza Salud conectada para acceder al historial y al número de pasos agregados del dispositivo y registrar los datos de forma eficiente en cuanto al consumo de batería.
• Si registras un sensor con SensorManager, especifica un maxReportLatencyUs de 30 segundos o más para aprovechar el procesamiento por lotes de sensores y minimizar la frecuencia de las interrupciones de la CPU. Cuando el dispositivo se activa posteriormente mediante otro activador, como una interacción del usuario, una obtención de la ubicación o una tarea programada, el sistema enviará inmediatamente los datos de los sensores almacenados en caché.

  val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Si tu aplicación requiere datos de ubicación y de sensores, sincroniza su recuperación y procesamiento de eventos. Al aprovechar las lecturas de los sensores en el breve wake lock que mantiene el sistema para las actualizaciones de ubicación, no necesitas un wake lock para mantener la CPU activa. Usa un trabajador o un wake lock de corta duración para gestionar la subida y el procesamiento de estos datos combinados.

Mensajes a distancia

Ejemplos de casos prácticos: 

• Aplicaciones complementarias de monitorización de vídeo o sonido que necesiten monitorizar eventos que se produzcan en un dispositivo externo conectado mediante una red local.
• Aplicaciones de mensajería que mantienen una conexión de socket de red con la variante para ordenadores.

Cómo reducir los bloqueos de activación: 

• Si los eventos de red se pueden procesar en el lado del servidor, usa FCM para recibir información en el cliente. Puedes programar un proceso de trabajo acelerado si necesitas que se traten más datos de FCM. 
• Si los eventos se deben procesar del lado del cliente a través de una conexión de socket, no es necesario un wake lock para escuchar las interrupciones de eventos. Cuando los paquetes de datos llegan a la radio Wi-Fi o móvil, el hardware de la radio activa una interrupción de hardware en forma de wake lock del kernel.Después, puedes programar un trabajador o adquirir un wake lock para procesar los datos.
• Por ejemplo, si usas ktor-network para detectar paquetes de datos en un socket de red, solo debes obtener un wake lock cuando se hayan enviado paquetes al cliente y sea necesario procesarlos.

  val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Resumen

Si adoptan estas soluciones recomendadas para casos de uso habituales, como la sincronización en segundo plano, el seguimiento de la ubicación, la monitorización de sensores y la comunicación de red, los desarrolladores pueden reducir el uso innecesario de wake locks. Para seguir aprendiendo, lee nuestra otra entrada de blog técnica o consulta nuestro vídeo técnico sobre cómo descubrir y depurar wake locks: Optimiza la batería de tu aplicación con la métrica de wake locks de Android vitals. También puedes consultar nuestra documentación actualizada sobre wakelocks. Para ayudarnos a seguir mejorando nuestros recursos técnicos, envíanos tus comentarios adicionales sobre nuestras guías a través de la encuesta de comentarios sobre la documentación.