Como o Google tentou taxar aplicativos que consomem muita bateria em segundo plano no Android

Você já notou como o Google vive ajustando o que os aplicativos podem fazer em segundo plano no Android? Essa é uma constante na vida de quem usa celulares Android, junto com a certeza da morte e dos impostos. A ideia é simples: a bateria é um recurso limitado, então não dá para deixar aplicativos gastando energia à vontade. O sistema operacional Android possui táticas para gerenciar a bateria, controlando a execução das tarefas para evitar o esgotamento rápido.

Para evitar que aplicativos mal-comportados drenem a bateria do seu telefone, o sistema operacional Android implementa uma série de táticas de gerenciamento. Essas táticas controlam quando e por quanto tempo os aplicativos podem funcionar em segundo plano, garantindo uma melhor eficiência energética.

Aplicativos que precisam realizar tarefas importantes em tempo real, como baixar um arquivo, monitorar uma corrida ou reproduzir música, podem criar um serviço de primeiro plano. Para isso, eles precisam exibir uma notificação visível, informando o usuário sobre a atividade em andamento.

Em vez de usar um serviço em primeiro plano, o Google sugere que os desenvolvedores utilizem APIs como <_JobScheduler_> e <_AlarmManager_>. Eles também podem optar por um <_wrapper_> de nível superior, como o <_WorkManager_>, para agendar tarefas em segundo plano de forma mais eficiente.

Diagrama que ilustra como os aplicativos agendam tarefas através da API WorkManager. Imagem: Google.

Com base na API utilizada e nos parâmetros definidos, o Android consegue executar tarefas em horários específicos, ou em momentos considerados ideais para a bateria do dispositivo. Apesar de inteligente, o sistema não quantifica o custo real de bateria dessas tarefas nem limita o volume total de trabalho.

Mesmo com limites arbitrários, como a execução de até 150 tarefas por aplicativo, ainda há um consumo considerável de energia. Isso mostra que, apesar dos controles, a gestão inteligente do gasto de bateria é um desafio contínuo para manter seu aparelho funcionando por mais tempo.

Em uma tentativa de resolver essa limitação e maximizar a vida útil da bateria, o Google idealizou a <_The Android Resource Economy_> (TARE). Essa proposta era uma grande reformulação na forma como o sistema gerenciaria o trabalho em segundo plano.

A TARE buscava aplicar princípios macroeconômicos à gestão de recursos, tratando a energia da bateria como um bem finito. Ela criava uma economia virtual completa, com moeda, custos, salários e regulamentações. O objetivo era alocar a energia de forma eficiente para as tarefas que ofereciam mais valor ao usuário.

Embora o Google tenha abandonado a TARE no ano passado, é interessante explorar o que poderia ter sido. Este artigo vai detalhar a TARE e explicar como o Google planejava cobrar pelo consumo de bateria de aplicativos Android.

Uma Economia Virtual para Taxar Aplicativos em Segundo Plano

A <_Android Resource Economy_> alteraria significativamente a forma como as tarefas são executadas quando agendadas pelas APIs <_AlarmManager_> e <_JobScheduler_>. Ela criava uma economia virtual gerenciada por uma autoridade central, o IRS, sigla para <_Internal Resource Service_>.

O IRS funcionaria como um banco central e um órgão regulador. Ele determinaria a oferta de moeda, definia preços e garantia a aplicação das regras. Seu papel era essencial para manter a estabilidade e a eficiência da economia de recursos do Android.

Sob a TARE, o Android utilizaria uma moeda virtual chamada <_Android Resource Credits_> (ARCs). Os aplicativos precisariam ter um saldo de ARCs para “comprar” a capacidade de executar tarefas em segundo plano. Havia também a moeda “<_Cakes_>“, uma denominação menor, onde um <_Giga-Cake_> (1.000.000.000 <_Cakes_>) equivalia a 1 ARC.

Um <_Android Bot_> exibindo um <_Android Resource Credit_> (ARC). Imagem: Google.

Modelo Econômico: CTP versus Preço

A TARE introduzia um modelo sofisticado que separava o custo da bateria de uma ação (o <_Cost to Produce_> – CTP) do preço cobrado (em ARCs) ao aplicativo. Isso garantia que a gestão de recursos fosse transparente e eficiente para todos os envolvidos.

O CTP representa o custo estimado (em ARCs) para o sistema, ou seja, o equivalente ao consumo de bateria para executar a ação. Já o Preço é a quantia (em ARCs) que o aplicativo realmente pagava pela ação.

No mercado ideal da TARE, o Preço geralmente seria maior ou igual ao CTP. O sistema visava maximizar seu “lucro” (Preço menos CTP). Ao priorizar ações com preços mais altos, o sistema teoricamente daria preferência a tarefas que ofereciam maior valor ao usuário.

O CTP e o Preço não eram fixos; o IRS aplicava “<_Modifiers_>” com base no estado do dispositivo. Por exemplo, os custos poderiam aumentar quando o modo de economia de bateria estivesse ativado ou diminuir quando o telefone estivesse carregando. O estado do processo do aplicativo era crucial. Se um aplicativo fosse o “TOP app” (em uso ativo), o Preço era frequentemente reduzido a zero.

Quando a economia de bateria está ativada, o preço de uma ação aumenta para atender à preferência do usuário por uma vida útil da bateria maximizada. Imagem: Joe Hindy / Android Authority.

Ganhando Créditos: Salários e Estímulos

Os aplicativos mantinham um saldo de ARCs em seu <_Ledger_>, que era gerenciado pelo IRS e seu braço fiscalizador, o <_Agent_>. Havia duas maneiras principais de os aplicativos ganharem créditos: Regulamentações (estímulo governamental) e Recompensas (salários).

As Regulamentações eram intervenções do IRS. Ao ser instalado, um aplicativo recebia um “<_Birthright_>“, um saldo inicial de ARCs. Se um aplicativo caísse abaixo do saldo mínimo exigido, o IRS forneceria uma “<_Basic Income_>” quando o dispositivo estivesse carregando, evitando que os aplicativos ficassem permanentemente “falidos”.

As Recompensas eram obtidas por meio do engajamento positivo do usuário. O sistema concedia ARCs quando o usuário abria o aplicativo, interagia com uma notificação ou <_widget_>, ou até mesmo apenas visualizava uma notificação. Os aplicativos podiam acumular ARCs até um “<_Maximum Satiated Balance_>” para evitar o acúmulo excessivo.

A TARE recompensava os aplicativos com ARCs quando o usuário interagia com suas notificações. Imagem: Megan Ellis / Android Authority.

Gastos e Fiscalização

Com exceção dos “VIPs” (<_Very Important Packages_> – como o próprio sistema operacional, o aplicativo principal ou aplicativos isentos de restrições de bateria), todos os aplicativos precisavam gastar ARCs para realizar suas ações. Isso criava um sistema justo para a alocação de recursos.

Antes de iniciar uma tarefa, o sistema verificava se o aplicativo tinha condições de arcar com uma “<_Action Bill_>“. Essa conta incluía o Preço para iniciar a tarefa mais um tempo de execução estimado, como 30 segundos. Se o saldo do aplicativo caísse abaixo do valor exigido enquanto a tarefa estivesse em execução, o <_Agent_> notificava o sistema, que interrompia a tarefa imediatamente.

Quando um aplicativo ficava sem ARCs para gastar, ele era considerado “falido” e não podia mais agendar trabalho em segundo plano. A TARE incentivava os aplicativos a escolher suas ações com cuidado, pois o sistema era projetado para maximizar seus próprios “lucros”, priorizando tarefas com um Preço mais alto.

Limite de Consumo e Regulamentação

A TARE não apenas gerenciava os saldos individuais dos aplicativos, mas também controlava a oferta global de recursos disponíveis, conhecida como “<_Consumption Limit_>“. Este limite era fundamental para garantir a saúde geral da economia de bateria.

Isso introduzia uma dupla verificação crucial: uma ação só poderia prosseguir se o aplicativo pudesse pagar o Preço e se o <_Consumption Limit_> restante do sistema pudesse cobrir o CTP. Quando um aplicativo executava uma tarefa, o Preço era deduzido do <_Ledger_> do aplicativo, e o CTP era deduzido do <_Consumption Limit_>.

Quando a bateria estava “satisfeita” (cheia), o <_Consumption Limit_> estava em seu máximo. À medida que o nível da bateria diminuía, os recursos disponíveis eram imediatamente reduzidos proporcionalmente. O motivo para vincular o número de ARCs ao nível da bateria do dispositivo era que o consumo de energia era mais aceitável com a bateria cheia e menos aceitável quando o aparelho estava prestes a ficar sem carga.

O <_Consumption Limit_> (ou seja, a quantidade total de ARCs em circulação) estava no máximo quando o dispositivo estava totalmente carregado. Imagem: Eric Zeman / Android Authority.

O IRS também geria ativamente a economia através da regulamentação:

• Recuperação de Riqueza (Tributação): Para evitar que os aplicativos acumulassem créditos, o IRS periodicamente recuperava uma porcentagem de ARCs não utilizados de aplicativos que não eram usados recentemente (padrão de 3 dias).
• Ajuste Dinâmico: O IRS não dependia apenas de limites fixos. Ele usava um componente “<_Analyst_>” para rastrear o consumo histórico de bateria em relação a uma taxa alvo, como 40 horas de vida útil em segundo plano. Se a bateria estivesse drenando muito lentamente, o IRS poderia aumentar o <_Consumption Limit_> (“<_Quantitative Easing_>“); se a bateria estivesse drenando muito rapidamente, o limite poderia ser diminuído.

O Que Aconteceu com a TARE?

A TARE foi um experimento de curta duração que o Google abandonou no ano passado, com o lançamento do Android 15. Ela nunca foi implementada em nenhum dispositivo e só podia ser ativada manualmente nas Opções de Desenvolvedor do Android.

Não sabemos por que o Google descartou a ideia, já que o registro de remoção de seu código não menciona uma razão. É possível que a TARE tenha sido ambiciosa demais; ajustar uma economia virtual para corresponder ao comportamento real da bateria é algo incrivelmente complexo. Dada sua complexidade e os efeitos de longo alcance nos aplicativos, os desenvolvedores precisariam de muito tempo para avaliar e fazer alterações para dar suporte ao novo sistema, o que representaria um fardo significativo para equipes menores. O projeto TARE, embora interessante, não avançou para uma implementação completa nos dispositivos.

Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.