40 votos

¿Cómo lidiar con los WakeLocks (huérfanos)?

Supongo que la mayoría de ustedes al menos tienen escuchó sobre WakeLocks . Muchos de ustedes tendrán experimentado ya ya sea a sabiendas o no. Algunos pueden saber cómo tratarlos en general - pero sólo unos pocos saben cómo tratar a los "candidatos más complicados".

Para aquellos que no lo sepan, aunque el enlace de arriba lleva a una explicación, un breve resumen: Las aplicaciones pueden solicitar un WAKE_LOCK para evitar que un componente del dispositivo se "duerma", para que puedan realizar una tarea incluso cuando la pantalla está apagada. Esto es muy útil en la mayoría de los casos (por ejemplo, mantener la pantalla encendida mientras se navega, mantener la WiFi activa para transmitir música), pero si se utiliza de forma incorrecta, hace que la batería se agote a corto plazo (hasta un 25% por hora).

La mayoría de las veces es fácil identificar la fuente (normalmente una aplicación que se comporta mal) - lo mostraré en una respuesta más abajo, ya que puede resultar útil para muchos usuarios. ¿Pero qué hacer si la aplicación que solicitó el WakeLock sale sin ser liberada? El sistema Android no se ocupará de ello . Claro, un reinicio resolvería el problema pero no siempre es una opción (deseada).

Por lo tanto, desde la perspectiva del usuario (no estoy preguntando sobre soluciones de desarrollo, sino sobre cómo un usuario puede manejar las cosas):

Lo que se puede hacer por el usuario para resolver el problema y evitar un mayor agotamiento de la batería?

Prefiero las respuestas no que involucra a Root (para que todos los usuarios puedan beneficiarse de ella). Sin embargo, las "soluciones arraigadas" son plenamente válidas y bienvenidas también.

2 votos

Tenía la impresión de que esto sólo ocurría si creabas el wakelock de la forma "incorrecta", utilizando /sys/power/wake_lock pero si lo haces de la forma "correcta" usando PowerManager y PowerManager.WakeLock, el servicio mantendrá el wakelock real y lo liberará incluso si tu proceso es eliminado...

1 votos

Según la información que he enlazado, obviamente no es así. Alguien informa de que ha comprobado las fuentes del kernel y no ha encontrado ninguna pista al respecto. Sugerencia para desarrolladores: parece que se pueden solicitar "wakelocks parciales". cronometrado para que caduquen automáticamente cuando se acabe el temporizador y no se actualice el wakelock aquire. Esa debe ser la "forma segura" a la que te refieres.

37voto

Izzy Puntos 45544

¿Cómo puedo saber si estoy afectado?

Esta es probablemente la primera pregunta para aquellos que no están familiarizados con este tema. Con Gingerbread (Android 2.3) y superior, tienes un servicio a bordo que te ayuda a averiguar: las estadísticas de las baterías. Aunque los fabricantes tienden a colocarlo en diferentes puntos, se encuentra principalmente en Ajustes → Sobre el teléfono → Batería o similar, y muestra una lista de las aplicaciones que han usado la mayor parte de su batería. Encima de eso hay un pequeño gráfico. Toca eso, y te llevará a una pantalla similar a esta:

battery stats
Captura de pantalla de las estadísticas de la batería en Android 2.3

Elegí una captura de pantalla de uno de mis dispositivos que ilustra el problema. Mirando las dos barras azules inferiores ("Aktiv" = El dispositivo se mantuvo despierto (activo), "Bildschirm an" = "Pantalla encendida"), la barra azul de la derecha en "Aktiv" indica un WakeLock: El dispositivo se mantuvo ocupado a pesar de que la pantalla estaba apagada. Así que con esto podemos estar bastante seguros de que tenemos un WakeLock pero no podemos decir quién lo causó.

Si su dispositivo no ofrece esta pantalla (o las barras de la parte inferior: Acabo de descubrir, por ejemplo, el LG Optimus 4X corriendo Android 4.0.3 ha cortado estas barras), puedes encontrarlas, por ejemplo, usando Monitor de batería GSam :

GSam Battery Monitor
Información similar de Monitor de batería GSam -- aquí las mencionadas "barras azules" son amarillas/naranjas

¿Qué causó el WakeLock?

Desafortunadamente, esta pregunta no puede ser respondida usando aplicaciones preinstaladas (excepto, tal vez, algunas ROMs personalizadas). Pero hay herramientas disponibles que sí pueden. El candidato más conocido para esto es BetterBatteryStats y nos muestra la causa en su wakelocks parciales sección:

BetterBatteryStatsBetterBatteryStats2
Capturas de pantalla de BetterBatteryStats

En el primer ejemplo 2 (tomado de la página de la playstore de la aplicación), el evento que causó la mayoría de los WakeLocks fue uno deseado: No queremos que la reproducción se detenga mientras escuchamos música. Así que el segundo ejemplo 3 (tomado de un caso real en uno de mis dispositivos) podría resultar mejor: los 3 eventos más importantes son causados por la misma aplicación, que necesitaba el WakeLock para mantener el servicio de empuje IMAP activo.

Para una alternativa a BetterBatteryStats mira el Detector Wakelock que se mencionan en La respuesta de UzumApps -- que parece más fácil de manejar, especialmente para los que no son técnicos:

Wakelock Detector: App details Wakelock Detector: Select processes
Detector Wakelock -- Haga clic en la imagen para ampliarla. (Fuente: Google Play )

¿Qué se puede hacer?

Si el caso es tan claro como en el segundo ejemplo de la sección anterior, la acción es bastante obvia, al menos en mi caso: No necesito ser informado inmediatamente cuando llega un correo; un retraso de 30 minutos es absolutamente aceptable. Así que entré en la aplicación de correo, desactivada Empuje IMAP (véase también: Empujar el correo electrónico ), y en su lugar cambió a un intervalo de encuesta de 30 minutos. WakeLocks no desapareció por completo, pero se redujo notablemente la vida de la batería mejoró notablemente.

Luego está el caso mencionado en la propia pregunta: Una aplicación que se comporta mal y no libera su WakeLock. Confronta el dispositivo con tus hallazgos y pide una solución. Si lo hace: problema resuelto. Si no: Casi siempre hay una aplicación alternativa disponible.

¿Y si es el propio sistema Android?

Sí, a veces se ve así: 98% o más consumido por algún servicio de Android. Si es el 98%, en la mayoría de los casos el candidato es nombrado LocationManagerService . ¿Un tipo malo espiándonos? No necesariamente. En este caso especial, el "tipo malo" de la lista ni siquiera es culpable al menos no directamente. Aquí hay otra aplicación que solicita la ubicación actual con demasiada frecuencia. Hay un excelente artículo en Setera.org sobre esto: Localización de Android LocationManagerServicio de descarga de la batería . Para dar un resumen: Utiliza el Android dumpsys (requiere Root!) para volcar un estado del sistema, y permite investigar los oyentes establecidos para el LocationManagerService. Una mirada más cercana a su configuración muestra que están constantemente "martillando" para obtener información de localización (algunos lo hacen permanentemente, es decir, sin interrupción). Como el ID de la aplicación aparece en la lista, y en otro lugar del vertedero incluso junto con el nombre técnico de la aplicación, todavía puedes identificarlo y tomar las acciones apropiadas.

¿Y qué hay de los OVNIS?

Desafortunadamente, existen: Aplicaciones que registraron un WakeLock y luego salieron sin liberarlo. Lo que queda son F sin usar **ing Obsoletes* -- WakeLocks held for no use. Así que no hay manera de simplemente traer la aplicación al primer plano y reconfigurarla, o hacer que libere sus WakeLocks.

Aquí la única solución que conozco es un reinicio y me gustaría tener una solución mejor. Por supuesto, si conoce la aplicación culpable, los pasos a seguir son los mismos que los anteriores: informar al desarrollador, obtener una solución o reemplazar la aplicación. Pero acerca de deshacerse de la actual ¿WakeLock? ¿Tal vez alguien más puede proporcionar una mejor alternativa al reinicio?

¿Hay algunas lecturas adicionales recomendadas?

Claro. Uno por ahora, puede que añada más después:

2 votos

Mejor educación para los desarrolladores que decir... ¿"Libera los wakelocks cuando termines con ellos y limpia lo que ensucies"?

3 votos

¡¡¡Upvote de mi parte por tu siempre asombrosa respuesta!!! Nunca te aburres de esto ¿verdad? :D

2 votos

Claro pero mira mi pregunta: Estoy explícitamente NO preguntando por el lado de los desarrolladores, pero desde la perspectiva del usuario . Quizá tenga que hacerlo más evidente ;)

6voto

Nick Pierpoint Puntos 7976

En resumen, esta es una muy buena pregunta, pero me temo que merece algo más que hacer que el usuario final sea consciente.

Rediseñar el núcleo para eliminar los relojes despertadores y utilizar una forma más completa y eficiente de gestionar mejor el principio, prolongando así la vida de la batería.

Desafortunadamente, ha sido aceptada como una solución de facto para permitir la "gestión de la energía" a pesar de que tampoco es exactamente eficiente! Hubo una extensa discusión sobre wakelocks (con Gregh Kroah Hartman - el gurú de Linux para el desarrollo de drivers - estoy buscando el linky exacto), otros sitios como LWN.net y otro artículo explicado en el mismo sitio aquí . Este fue el artículo al que Gregh Kroah Hartman se refirió blog en el que parece estar de acuerdo con la solución alternativa propuesta por Rafael J. Wysocki han documentado mucho sobre la alternativa potencial. No estoy seguro de que eso esté realmente en su lugar en el núcleo más moderno v3.x.x.

Las aplicaciones mal diseñadas pueden y a menudo solicitan wakelocks como mantener la pantalla encendida, pero de hecho, en este escenario para mantener la pantalla encendida, hay de hecho una forma más eficiente de hacerlo:

getWindow().addFlags(LayoutParams.FLAG_KEEP_SCREEN_ON);

Mientras que, esforzándose por mantener esto libre de jerga, etc. para el usuario final, realmente el núcleo del problema se reduce al código del núcleo en cómo se gestionan los wakelocks.

Aquí hay un breve resumen sobre XDA en lo que es wakelocks para los no iniciados. Al usar BetterBatteryStats se puede ver exactamente qué proceso está agotando la batería, el wiki está alojado en github, y está disponible en el mercado aquí .

1 votos

Curioso que apuntes al mismo hilo de XDA que he mencionado. Estoy de acuerdo contigo en que el sistema debería tener más cuidado (por ejemplo, liberando los WakeLocks solicitados por aplicaciones que ya no se están ejecutando). Y que los desarrolladores deberían tener más cuidado en la codificación (liberándolos explícitamente en los estados apropiados del LifeCycle). Pero eso no nos ayuda a los usuarios conozca . Espero que mi respuesta dé alguna idea de lo que puede hacer un usuario, y que alguno de vosotros, "técnicos", pueda llenar el vacío que queda.

3voto

UzumApps Puntos 39

Mira Detector Wakelock: XDA-Desarrolladores / Google Play :

El detector de wakelock agrupa los wakelocks de la aplicación en una vista ampliable para una mejor visualización. Y muestra qué aplicaciones se están ejecutando. Y hay botones de información de desinstalación de kill en la vista ampliada de la aplicación.

Wakelock Detector: App details Wakelock Detector: Select processes
Haga clic en la imagen para ampliarla. (Fuente: Google Play )

Revelación: Soy uno de los desarrolladores responsables de esta aplicación. Cuatro amigos más están conmigo trabajando en este proyecto como un hobby.

0 votos

Gracias. Es una información muy valiosa. ¿Le importaría añadir algunos detalles más a su respuesta, por ejemplo, qué lo hace tan especial? Entonces añadiría algunas capturas de pantalla. Hasta que eso esté hecho: Aquí está Enlace de Playstore a la aplicación ...

0 votos

Gracias por los detalles. Los he integrado en tu respuesta, espero que no te importe :) Pregunta de comprensión: Digamos que una aplicación consulta la ubicación utilizando un intervalo de "0 segundos". Esto causaría la Servicio de localización para despertar el dispositivo. ¿Podría Detector de bloqueo de vigilia mostrar la aplicación responsable entonces como la causa real -- o la Servicio de localización ya que no forma parte de ese paquete de aplicaciones?

0 votos

La respuesta a tu pregunta es "no" porque el detector de wakelocks agrupa wakelocks que pertenecen al mismo nombre de paquete de aplicación. Como el servicio de localización pertenece al sistema operativo Android, la solución sería comprobar los permisos de usuario de la aplicación.

1voto

beeshyams Puntos 82

Un par de formas que podrían ayudar dispositivo desarraigado usuarios

  1. Viendo que @Uzumapps, uno de los desarrolladores de la app ha publicado un solución utilizando Detector Wakelock ( WLD ), me sorprende que no haya actualizado sobre el uso de la aplicación que también se puede utilizar sin root llamado Wakelock Detector de Luz ¡! Descubrí esto buscando una solución para mi nuevo dispositivo (unrooted).

Este es un desarrollo reciente y por lo tanto la publicación de este para los usuarios de dispositivos no rooteados. Probado como trabajando en Moto X Play (Android 6.0.1)

  • Descarga WLD desde el enlace de Play Store

  • Manual de uso del DTM aquí

  • Instrucciones para dispositivos no rooteados aquí . Tiene todos los detalles pero para resumir:

    adb shell dumpsys power | grep -i partial_wake_lock

Nota: No pude conseguir el segundo método de trabajo, daría la bienvenida a la solución de edición en hacer que funcione para los chicos no conocedores como yo

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X