Sinal de célula
Alguns antecedentes, conforme explicado por ce4, sobre a pergunta A recepção 'ruim' esgota a bateria mais rapidamente? :
O circuito do transceptor é projetado com economia de energia em mente e reduzirá o envio de energia o máximo possível se a recepção for boa. Isso também reduz o valor da SAR, que é uma medida para a exposição do corpo humano à radiação.
Se a recepção estiver ruim, a intensidade do sinal de envio deve ser ajustada de acordo.
Então é isso que realmente está por trás disso: em uma recepção ruim, o dispositivo gasta muita energia para encontrar um sinal melhor / mais forte (ou qualquer sinal se for perdido). A captura de tela 1 a seguir mostra claramente esses horários, quando você dá uma olhada na barra intitulada Sinal do telefone .
"Quanto mais verde o limpador": Um verde claro significa "boa recepção" (a captura de tela mostra isso no início e no final, que é aqui: manhã e noite - para que em casa eu tenha uma boa recepção). Ficando amarelado: "Recepção moderada". Isso consome mais energia: compare-o com o gráfico em cima (não na captura de tela - mas o mesmo da primeira captura de tela) e você verá que a barra está quase plana onde o sinal da célula é bom - mas cai mais rapidamente onde não está. Veja os pequenos pontos vermelhos: "sem recepção". E o telefone liga como um louco para encontrar uma nova torre de celular ...
Como descobrir onde estão os pontos mortos?
Eu já mostrei na minha resposta em A recepção 'ruim' esgota a bateria mais rapidamente? como se pode descobrir sobre essas "zonas mortas" e onde elas estão:
Aplicativos como No Signal Alert 2 e OpenSignalMaps 3 monitoram o sinal da célula em segundo plano e registram essas áreas, para que possam mostrar um mapa de onde estavam as zonas mortas. O OpenSignalMaps tem a vantagem de mostrar a você todas as torres de celular ao alcance, indicando quais você está conectado. Também oferece uma "bússola", indicando a direção do sinal mais forte.
No entanto, minha resposta sobre como lidar automaticamente com essas zonas mortas não foi tão detalhada. Então, eu brinquei um pouco com soluções diferentes - e aqui está o que eu descobri:
Como lidar automaticamente com essas zonas mortas para economizar energia?
Aplicativos para automatizar o modo avião
Alcancei bons resultados com dois aplicativos: Autopilot 4 e NoBars Battery Saver 5 . Ambos monitoram o sinal da célula e, quando cai para longe, alternam para o Modo Avião por um tempo predefinido. O usuário pode definir quanto tempo isso levaria. Após esse tempo limite, o Modo Avião fica desativado e o monitoramento da célula assume o controle.
No segundo gráfico da minha pergunta, isso aparece como "lacunas" na barra de sinal do telefone : Como o rádio da célula foi desativado durante o modo avião, nenhuma cor é mostrada; o sistema não sabia nada sobre a força do sinal nesse período. E com o rádio celular desligado, ele também não usava energia adicional (mais precisamente, não usava energia para esse rádio) - que era exatamente o que se pretendia.
Com o piloto automático , o único efeito colateral irritante era: Para cada verificação de sinal, ele piscava no visor por cerca de um segundo. Além disso, oferece mais opções para serem configuradas pelo usuário. No entanto, como os resultados de ambos os aplicativos são absolutamente comparáveis, essas opções extras parecem não ser realmente necessárias, embora sejam agradáveis. Outra vantagem do piloto automático é o log fornecido ao usuário: dessa forma, você pode ver os horários exatos das opções de modo.
Aplicativos para lidar com rede de dados
Também testei o ShutUpBatterySaver 6 , que visa lidar com o tráfego de dados. Ao cair abaixo de uma certa intensidade de sinal que o usuário pode definir, desativa o AutoSync e, abaixo de um segundo nível definível, desliga completamente a Internet móvel.
Porém, ele nunca ativa (ou desativa) o Modo Avião, portanto a energia usada para obter um sinal (melhor) ainda será a mesma. Porém, com um sinal ruim, a transferência de dados consome mais energia do que com um bom sinal, pois, por exemplo, a perda de pacotes pode ser maior. Na barra de status, vi várias vezes que o AutoSync estava desativado 7 , por isso parece funcionar. Por não ser um usuário pesado de dados (como mostram as estatísticas do LBE na mesma captura de tela), não pude realmente dizer quanta ajuda isso trouxe: Comparado aos dois aplicativos de manuseio no modo avião, os resultados em termos de duração da bateria foram mínimos (caso existam).
Solução combinada
Provavelmente, obteria melhores resultados para unir as duas abordagens. Como não estava com vontade de verificar todas as combinações possíveis, decidi pela poderosa solução de 6 letras: TASKER.
Como muitos de vocês provavelmente sabem, o Tasker é a solução de automação no Android. Acho que poderia até preparar café, se nossos dispositivos tivessem sensores para detectar café e água. Então, eu criei alguns perfis para esse ótimo aplicativo - e os resultados foram excelentes!
Então, basicamente, são 3 perfis, comunicando-se através de uma variável comum:
- % SIGSTATE <1: verifique se o sinal cai abaixo de ~ 25%. Nesse caso, desative os dados móveis, defina% SIGSTATE como 1.
- % SIGSTATE <2: verifique se o sinal cai abaixo de ~ 15%. Nesse caso, mude para o modo avião, defina% SIGSTATE como 2.
- % SIGSTATE> 0: aguarde 5 minutos, desative o modo avião, ative os dados móveis, aguarde mais 15 segundos (para a restauração do sinal), defina% SIGSTATE como 0.
No meu perfil Init global (que é executado quando o Tasker inicia o monitoramento),% SIGSTATE é definido como 0 (se não estiver definido). Todos os três perfis acima também definem notificações, como a captura de tela acima mostra 9 . Cada estado mantém uma notificação (que é substituída quando o mesmo estado ocorre novamente), o estado mais atualizado está sempre na parte inferior.
Os resultados pareciam ainda melhores do que com os dois aplicativos de manipulação no modo avião acima, mas isso também pode ser devido a condições de sinal ligeiramente diferentes. Portanto, deve pelo menos ser comparável. Usando uma dessas três soluções, cheguei em casa após cerca de 11 horas com cerca de 20% a mais de carga, sem aplicar nenhuma.
Dito isto, encerrarei esta resposta mostrando os perfis do Tasker que criei, para que você possa usá-los com sua instalação do Tasker :
Tarefa "InitVars":
- Variável -> Conjunto de Variáveis:% SIGSTATE = 0
Tarefa "SigLow":
- Rede -> Dados móveis: Desativado
- Variável -> Conjunto de Variáveis:% SIGSTATE = 1
- Alerta -> Notificar Vibrar: Título "IzzySignal"; Texto: "Sinal baixo; dados móveis desativados (sinal:% CELLSIG)"
Tarefa "SigLost":
- Variável -> Conjunto de Variáveis:% WLANSTATE = 0
- Variável -> Conjunto de variáveis:% WLANSTATE = 1 SE% Wifi ~ ligado
- Rede -> Modo Avião: Ativado
- Rede -> Wifi: em IF% WLANSTATE ~ 1
- Variável -> Conjunto de Variáveis:% SIGSTATE = 2
- Alerta -> Notificar Vibrar: Título "IzzySignal", Texto: "Sinal Perdido; Entrando no Modo Avião"
Tarefa "SigReturn":
- Tarefa -> Aguardar: 5 minutos
- Rede -> Modo Avião: Desativado
- Tarefa -> Aguardar: 15 segundos
(dê algum tempo ao dispositivo para encontrar um novo sinal!)
- Líquido -> Dados móveis: Ativado se% ROAM ~ Desativado
(evite surpresas ruins ao retornar de férias no exterior!)
- Variável -> Conjunto de Variáveis:% SIGSTATE = 0
- Alerta -> Notificar Vibrar: Título "IzzySignal", Texto "Sinal ativado; Modo avião desativado (Sinal:% CELLSIG)"
Agora para os perfis:
Perfil SigLowCheck:
- Estado -> Variável -> Valor da variável: Nome "% SIGSTATE", Op "Matemática: Menor que", Valor "1"
- Estado -> Telefone -> Intensidade do sinal: de 0 a 2
- Estado -> Tasker -> Perfil ativo: "SigLost", [x] Invert
(evite um conflito:% SIGSTATE ~ 0 && SignalStrength ~ 1 corresponderá à condição de ambos os perfis)
- Tarefa: SigLow
Perfil SigLostCheck:
- Estado -> Variável -> Valor da variável: Nome "% SIGSTATE", Op "Matemática: Menor que", Valor "2"
- Estado -> Telefone -> Intensidade do sinal: de 0 a 1
- Tarefa: SigLost
Perfil SigReturnCheck:
- Estado -> Variável -> Valor da variável: Nome "% SIGSTATE", Op "Matemática: Maior que", Valor "0"
- Tarefa: SigReturn
Inicial do perfil:
- Evento -> Tarefa -> Início do Monitor
- Tarefa: InitVars
Agora, esse é apenas o conceito básico e pode ser estendido com, por exemplo, reprodução de sons, vibração, exibição da tela piscante e muito mais. Mas o material de economia de energia já está presente - e faz seu trabalho conforme descrito. Espero que isso possa ajudá-lo também!
Outra observação: pelo menos com o GSM (não sei dizer o CDMA), retornar do modo avião por padrão obriga a inserir o PIN do SIM. É claro que isso pode ser desligado - mas, nesse caso, essa proteção adicional também desaparece ao ligar o telefone. Não faço ideia por que isso não é possível seletivamente, como foi com meus telefones pré-Android.
No entanto, para alguns telefones, há uma alternativa para alguns itens nas tarefas acima, que removem esta limitação:
- No SigLost , em vez de Rede -> Modo avião: Ao usar Telefone -> Rádio: Desligado se o seu telefone suportar isso (meu Droid2 / Milestone2, infelizmente não). Se você puder fazer isso, a verificação do WiFi se tornará obsoleta (e o limpador de tarefas).
- A contra-reação no SigReturn também precisa ser alterada: em vez de Rede -> Modo avião: Desativado , use Telefone -> Rádio: Ativado .
Informe-me nos comentários se isso remover a limitação do PIN do SIM, pois não posso testá-lo (meu dispositivo não suporta, como descrito acima).
Editar por t0mm13b
O interessante é que notei que havia vários ícones de tasker aparecendo na barra de status, o que tornava as coisas confusas quanto ao estado em que os perfis dos tasker estavam sendo executados; Descobri que, ao definir o Título para o 'Notify Vibrate' em cada uma das tarefas acima, o mesmo resultado líquido é uma notificação singular chamada ' IzzyTasker ', com a mensagem apropriada usada.
