¿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:
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 :
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:
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:
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
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.