Como lidar com WakeLocks (órfãos)?

Acho que a maioria de vocês já ouviu falar sobre WakeLocks . Muitos de vocês já os experimentaram - com conhecimento ou não. Alguns podem saber como lidar com eles em geral - mas poucos sabem como lidar com os "candidatos mais complicados".

Para quem não sabe, embora o link acima leve a uma explicação, um breve resumo: os aplicativos podem solicitar a opção WAKE_LOCKpara impedir que um componente do dispositivo "durma", para que possam executar uma tarefa mesmo quando a tela estiver desligada. Isso é muito útil na maioria dos casos (por exemplo, manter a tela ligada durante a navegação, manter o Wi-Fi ativo para transmitir música) - mas, usado de maneira errada, faz com que a bateria seja descarregada em curto prazo (até 25% por hora) .

Na maioria das vezes, é fácil identificar a fonte (geralmente um aplicativo que se comporta mal) - mostrarei isso em uma resposta abaixo, pois pode ser útil para muitos usuários. Mas o que fazer se o aplicativo que solicitou o WakeLock sair sem liberá-lo? O sistema Android não vai cuidar disso . Claro, uma reinicialização resolveria o problema - mas nem sempre é uma opção (desejada).

Portanto, da perspectiva dos usuários (não estou perguntando sobre soluções de desenvolvimento, mas como um usuário pode lidar com as coisas):

O que pode ser feito * pelo usuário * para resolver o problema e evitar o consumo adicional de bateria?

Prefiro respostas que não envolvam raiz (para que todos os usuários possam se beneficiar). No entanto, "soluções enraizadas" são totalmente válidas e bem-vindas também.

Como posso saber se estou afetado?

Esta é provavelmente a primeira pergunta para aqueles que não estão familiarizados com este tópico. Com o Gingerbread (Android 2.3) e superior, você tem um serviço a bordo para ajudá-lo a descobrir: estatísticas da bateria. Embora os fabricantes tendam a colocá-lo em pontos diferentes, ele é encontrado principalmente em Configurações → Sobre o telefone → Bateria ou similar e mostra uma lista dos aplicativos que utilizaram a maior parte da bateria. Além disso, há um pequeno gráfico. Toque nesse botão e ele o levará a uma tela semelhante a esta:

^{Captura de tela das estatísticas da bateria no Android 2.3}

Escolhi uma captura de tela de um dos meus dispositivos que ilustra o problema. Observando as duas barras azuis inferiores ("Aktiv" = O dispositivo foi mantido acordado (ativo), "Bildschirm an" = "Tela ativada"), a barra azul mais à direita no "Aktiv" indica um WakeLock: O dispositivo foi mantido ocupado apesar de o fato de a tela estar desligada. Assim, podemos ter certeza de que temos um WakeLock - mas não podemos dizer quem o causou.

Se o seu dispositivo não oferece esta tela (ou as barras na parte inferior: Acabei de descobrir, por exemplo, o LG Optimus 4X executando o Android 4.0.3 cortou essas barras), você pode encontrá-las, por exemplo, usando o GSam Battery Monitor :

^{Informações semelhantes do GSam Battery Monitor - aqui as "barras azuis" mencionadas são amarelas / laranja}

O que causou o WakeLock?

Infelizmente, esta pergunta não pode ser respondida usando aplicativos pré-instalados (exceto, talvez, algumas ROMs personalizadas). Mas existem ferramentas disponíveis que podem. O candidato mais conhecido para isso é BetterBatteryStats e mostra a causa em sua seção parcial de wakelocks :

^{Imagens de BetterBatteryStats}

No primeiro exemplo ² (retirado da página playstore do aplicativo), o evento que causou a maioria dos WakeLocks foi o desejado: não queremos que a reprodução seja interrompida enquanto ouve música. Portanto, o segundo exemplo ³ (retirado de um caso real em um dos meus dispositivos) pode ser melhor: os três eventos mais importantes são causados ​​pelo mesmo aplicativo, que precisava do WakeLock para manter o serviço de envio IMAP ativo.

Para uma alternativa ao BetterBatteryStats , confira o aplicativo Wakelock Detector mencionado na resposta do UzumApps - que parece mais fácil de lidar, especialmente para os não técnicos:

^{Detector Wakelock - Clique na imagem para ampliar. (Fonte: Google Play )}

O que pode ser feito?

Se o caso for tão claro quanto no segundo exemplo da seção anterior, a ação será bastante óbvia - pelo menos no meu caso: não preciso ser informado imediatamente quando um e-mail chegar; um atraso de 30 minutos é absolutamente aceitável. Então, entrei no aplicativo de email, desabilitei o IMAP Push (consulte também: Push Email ) e alternei para um intervalo de pesquisa de 30 minutos. O WakeLocks não desapareceu completamente, mas caiu notavelmente - a duração da bateria melhorou notavelmente.

Depois, há o caso mencionado na pergunta em si: um aplicativo com mau comportamento que não libera seu WakeLock. Confronte o desenvolvedor com suas descobertas e peça uma solução. Se ele entregar: problema resolvido. Caso contrário: quase sempre há um aplicativo alternativo disponível.

E se for o próprio sistema Android?

Sim, às vezes parece exatamente isso: 98% ou mais consumido por algum serviço Android. Ah, se for 98%, na maioria dos casos o candidato se chama LocationManagerService . Cara mau nos espionando? Não necessariamente. Nesse caso especial, o "bandido" listado nem é culpado - pelo menos não diretamente. Aqui está outro aplicativo que solicita a localização atual com muita frequência. Há um excelente artigo no Setera.org sobre o assunto: Identificando o local da bateria do Android LocationManagerService . Para dar um resumo: ele usa o Androiddumpsysrecurso (requer raiz!) para despejar um estado do sistema e permite investigar os ouvintes estabelecidos para o LocationManagerService. Um olhar mais atento às suas configurações mostra que elas são constantemente "marteladas" para obter informações de localização (algumas o fazem permanentemente, ou seja, sem interrupção). Como o ID do aplicativo é listado junto e em outro local do despejo, mesmo junto com o nome técnico do aplicativo, você ainda pode identificá-lo e executar as ações apropriadas.

E quanto aos OVNIs?

Infelizmente, existem: Aplicativos que registraram um WakeLock - e saíram sem liberá-lo. O que resta são * Obsoletos não utilizados * - WakeLocks mantidos sem uso. Portanto, não há como simplesmente colocar o aplicativo em primeiro plano e reconfigurá-lo ou fazê-lo liberar seus WakeLocks.

Aqui, a única solução conhecida para mim é uma reinicialização - e eu gostaria de ter uma solução melhor. Obviamente, se você conhece o aplicativo culpado, as etapas a respeito são as mesmas que acima: informe o desenvolvedor, obtenha uma correção - ou substitua o aplicativo. Mas sobre como se livrar do WakeLock atual ? Talvez alguém possa fornecer uma alternativa melhor para a reinicialização?

Existem algumas leituras adicionais recomendadas?

Certo. Um por enquanto, posso acrescentar mais tarde:

• [GUIA] Definição de Wakelocks e como evitá-los (XDA Developers, março de 2013)

Resumindo, essa é uma pergunta muito boa, mas receio, ela merece mais do que apenas conscientizar o usuário final!

Redesenhe o kernel para eliminar os despertares e use uma maneira mais eficiente e eficiente de gerenciar melhor o princípio, prolongando assim a vida útil da bateria.

Infelizmente, ela foi aceita como uma solução de fato para permitir o "gerenciamento de energia", apesar de também não ser exatamente eficiente! Houve uma extensa discussão sobre wakelocks (com Gregh Kroah Hartman - o guru do Linux para desenvolvimento de drivers - estou pesquisando o link exato), outros sites como o LWN.net e outro artigo explicado no mesmo site aqui . Este foi o artigo que Gregh Kroah Hartman se referiu a este blog , no qual ele parece concordar com a solução alternativa proposta por Rafael J. Wysocki, que documentou muito sobre a alternativa em potencial. Não tenho certeza se isso realmente existe no kernel mais moderno v3.xx

Aplicativos mal projetados podem e frequentemente solicitam wakelocks, como manter a tela ligada, mas, de fato, nesse cenário para manter a tela ligada, existe de fato uma maneira mais eficiente de fazer isso:

getWindow().addFlags(LayoutParams.FLAG_KEEP_SCREEN_ON);

Enquanto, esforçando-se para manter isso livre de jargões, etc. para o usuário final, realmente o núcleo do problema se resume ao código do kernel na maneira como os wakelocks são gerenciados.

Aqui está um breve resumo do XDA sobre o que é wakelocks para os não iniciados. Usando o BetterBatteryStats , é possível ver exatamente qual processo está esgotando a bateria, o wiki está hospedado no github e está disponível no mercado aqui .

Confira Wakelock Detector: XDA-Developers / Google Play :

O detector Wakelock agrupa os wakelocks do aplicativo em uma visualização expansível para uma melhor aparência. E mostra quais aplicativos estão em execução. E existem botões de informações de desinstalação matados na visualização expandida do aplicativo.

^{Clique na imagem para ampliar. (Fonte: Google Play )}

Divulgação: eu sou um dos desenvolvedores responsáveis ​​por este aplicativo. Mais quatro amigos estão trabalhando neste projeto como hobby.

Algumas maneiras de ajudar os usuários de dispositivos não enraizados

1. Vendo que @Uzumapps, um dos desenvolvedores do aplicativo postou uma solução usando o Wakelock Detector ( WLD ), estou surpreso que ele não tenha atualizado sobre o uso do aplicativo, que também pode ser usado sem raiz chamado Wakelock Detector Light ! Eu descobri isso procurando uma solução para o meu novo dispositivo (sem raiz).

Este é um desenvolvimento recente e, portanto, publicado para usuários de dispositivos não raiz. Testado como funcionando no Moto X Play (Android 6.0.1)

• Faça o download do WLD no link da Play Store acima

• Manual para usar o WLD aqui

• Instruções para dispositivos não raiz aqui . Ele tem todos os detalhes, exceto para resumir:

  • Ative a depuração USB no dispositivo e adb

  • Baixe o Wakelock Unlocker for Chrome no seu laptop (também funciona no Chromium)

  • Ative e pronto!

  • A versão Wakelock Detector Light não exibe estatísticas desde Desconectado

    2. Existe outra alternativa no reddit que envolve executar o comando abaixo em um loop, como mencionado aqui

  poder do dumpsys do shell adb | grep -i parcial_wake_lock

Nota: Eu não consegui que o segundo método funcionasse, aceitaria a solução de edição ao fazê-lo funcionar para pessoas não mais experientes como eu