Quem instala o Ubuntu em um MacBook Air A1466 geralmente percebe duas coisas logo no início: o sistema funciona bem, mas a bateria pode acabar rápido demais. Isso nem sempre significa que a bateria está ruim. Em muitos casos, o problema real está no consumo da sessão gráfica, do navegador, de processos em segundo plano e na forma como o processador está escalando frequência fora da tomada.
Foi exatamente esse cenário que apareceu no seu caso. A bateria não estava “morta”. O que estava pesado era o consumo durante o uso. A boa notícia é que esse tipo de problema pode melhorar bastante com diagnóstico correto e alguns ajustes simples, sem gambiarra e sem promessas irreais.
O que descobrimos antes de mexer
O primeiro passo foi separar duas coisas que muita gente mistura: saúde da bateria e consumo instantâneo.
No Linux, o upower mostra propriedades importantes da bateria, como energia atual, energia máxima real, energia máxima de projeto, taxa de descarga e capacidade. A própria documentação do UPower define EnergyFull como a energia máxima atual da bateria, EnergyFullDesign como a capacidade de projeto, EnergyRate como o consumo em watts e Capacity como a saúde da bateria. O UPower ainda observa que capacidade abaixo de 75% costuma ser sinal de troca.
No seu MacBook Air 7,2, a bateria apareceu com cerca de 94,7% de capacidade, o que é um resultado muito bom para a idade do equipamento. Então o diagnóstico correto foi este: a bateria está boa, mas o notebook estava gastando energia demais durante o uso.
Por que isso acontece no MacBook Air com Ubuntu
Em Macs Intel mais antigos, principalmente com ambiente gráfico completo, navegador aberto, Wi-Fi ligado e processos multimídia rodando, o consumo pode subir mais do que no macOS. No seu caso, os testes práticos mostraram que os maiores pesos vinham do uso real da sessão, com destaque para navegador, GNOME Shell, PipeWire e carga gráfica, não do teclado retroiluminado nem de defeito grave de hardware.
Além disso, o seu processador é um Intel Core i5-5350U de 5ª geração. A documentação oficial do TLP explica que, desde o kernel 5.7, CPUs Intel de 5ª geração ou anteriores que não têm HWP passam a usar o intel_pstate em modo passive, que aparece como intel_cpufreq. Nesse modo, os governors disponíveis mudam, e o schedutil virou o padrão em kernels mais novos. O próprio FAQ do TLP alerta que forçar powersave nesse cenário pode deixar o sistema lento, e recomenda usar schedutil.
Esse detalhe foi importante para o seu caso, porque a solução não era simplesmente “jogar tudo em powersave”, mas sim limitar o teto de desempenho do processador na bateria, mantendo o comportamento do governor coerente com esse hardware. A documentação do TLP prevê isso com CPU_MAX_PERF_ON_BAT, cujo valor padrão em bateria é 80%.
Objetivo deste tutorial
O propósito aqui não é só instalar um pacote qualquer, mas seguir uma linha de raciocínio correta:
- verificar se a bateria ainda está saudável
- medir temperatura e comportamento do sistema
- instalar um gerenciador de energia adequado
- ajustar o limite de desempenho do processador na bateria
- confirmar, com números, se o consumo realmente caiu
Foi exatamente esse caminho que resolveu o problema no seu MacBook.
Passo 1: verificar a saúde real da bateria
Antes de otimizar, confira se a bateria ainda vale a pena.
Rode:
JavaScriptupower -i /org/freedesktop/UPower/devices/battery_BAT0Preste atenção principalmente nestes campos:
- energy-full
- energy-full-design
- energy-rate
- capacity
- time to empty
Como referência prática, no seu caso a bateria estava com cerca de 33,6 Wh de carga cheia real contra 35,52 Wh de projeto, e capacidade em torno de 94,7%, o que confirma que o problema não era desgaste forte.
Se a sua capacidade estivesse muito baixa, especialmente perto ou abaixo de 75%, o próprio UPower já trata isso como um sinal de bateria envelhecida.
Passo 2: verificar temperatura e sensores do sistema
Depois, vale conferir se o notebook não está aquecendo demais ou se algum sensor importante não está sendo lido.
Instale o lm-sensors:
JavaScriptsudo apt update sudo apt install -y lm-sensors sensorsNo seu MacBook, o resultado mostrou:
- CPU na faixa de 62 °C a 66 °C
- ventoinha lida corretamente pelo applesmc
- bateria em temperatura normal
- sem sinal de superaquecimento grave no momento do teste
Esse passo não reduz a bateria sozinho, mas ajuda a confirmar se o sistema está se comportando de forma coerente.
Passo 3: instalar o TLP
O ajuste principal foi feito com o TLP, que é uma das ferramentas mais conhecidas para economia de energia em notebooks Linux. A documentação oficial do projeto descreve o TLP como uma ferramenta voltada para economia de bateria e afirma que as configurações padrão já implementam recomendações do Powertop.
Instale assim:
JavaScriptsudo apt update sudo apt install -y tlp tlp-rdw sudo systemctl enable tlp sudo systemctl start tlpDepois confira:
JavaScriptsudo tlp-stat -sNo seu caso, ele ficou ativo em modo battery e funcionando corretamente.
Passo 4: entender por que não usamos powersave na marra
Esse ponto foi decisivo.
Muita gente tenta resolver drenagem de bateria forçando o governor powersave. No seu MacBook Air 7,2, isso não era a melhor ideia. Como o seu i5 de 5ª geração opera com intel_pstate em modo passivo, o TLP recomenda manter schedutil nesse cenário, justamente porque o powersave via intel_cpufreq pode provocar lentidão.
Então, em vez de trocar governor, o ajuste correto foi limitar a performance máxima permitida na bateria.
Passo 5: criar um perfil de economia específico para o MacBook
Crie um arquivo de configuração local do TLP:
JavaScriptsudo mkdir -p /etc/tlp.d sudo nano /etc/tlp.d/10-macbook-air.confColoque:
JavaScriptCPU_MAX_PERF_ON_BAT=60Salve o arquivo e aplique:
JavaScriptsudo systemctl restart tlp sudo tlp-stat -pO que esse ajuste faz
A opção CPU_MAX_PERF_ON_BAT define o percentual máximo de desempenho que o processador pode usar quando o notebook está fora da tomada. Segundo a documentação do TLP, esse valor é expresso em porcentagem do desempenho total disponível do processador Intel. O valor padrão em bateria é 80%, mas no seu caso reduzi-lo para 60% trouxe ganho real de autonomia sem matar completamente a fluidez do sistema. (Linrunner)
Passo 6: confirmar se o TLP aplicou o ajuste
Depois do restart do TLP, confira:
JavaScriptsudo tlp-stat -pNo seu MacBook, o resultado final mostrou:
- scaling_governor = schedutil
- intel_pstate/status = passive
- intel_pstate/max_perf_pct = 60
- scaling_max_freq = 1740000
- cpuinfo_max_freq = 2900000
Ou seja, o processador passou a respeitar o novo teto na bateria.
Passo 7: medir se o consumo realmente caiu
Agora vem a parte mais importante: medir antes e depois.
Use:
JavaScriptupower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep -E 'energy-rate|time to empty|percentage'No seu caso, a evolução prática foi esta:
- no começo, o consumo estava chegando perto de 13,5 W
- depois dos ajustes, caiu para a faixa de 8 W a 9 W
- com o perfil em 60%, chegou a cerca de 7,7 W
Isso já colocou o MacBook Air 7,2 em uma faixa muito mais saudável para uso em Ubuntu nesse hardware.
Passo 8: verificar quem ainda consome mais energia
Para enxergar melhor os maiores consumidores do sistema, use o Powertop:
JavaScriptsudo apt install -y powertop sudo powertopNos seus testes, os principais pesos não eram a bateria, nem o teclado retroiluminado, mas sim a própria sessão: navegador, GNOME Shell, PipeWire e carga gráfica.
Isso é importante porque evita diagnósticos errados. Em outras palavras: não adianta culpar só a bateria se o que está drenando é o uso real do sistema.
Passo 9: manter Bluetooth desligado quando não estiver usando
Esse ajuste é simples, mas ajuda em notebook antigo.
Desligue quando não precisar:
JavaScriptbluetoothctl power offÉ um detalhe pequeno, mas somado aos outros ajustes faz diferença.
Passo 10: observar o Wi-Fi na bateria
A documentação do TLP informa que o padrão é Wi-Fi power saving desligado na tomada e ligado na bateria. Ela também alerta que esse modo pode causar instabilidade em alguns drivers ou redes. (Linrunner)
No seu caso, como o objetivo era reduzir consumo, fez sentido manter esse comportamento padrão. Só vale observar: se notar Wi-Fi lento, desconexões ou link instável na bateria, esse é um dos primeiros pontos a revisar.
Passo 11: manter brilho de tela e teclado em níveis razoáveis
Aqui entra bom senso.
No MacBook Air, a tela pesa muito mais no consumo do que o teclado retroiluminado. Então, depois de resolver o backlight do teclado, vale manter a iluminação apenas no nível necessário e não no máximo o tempo todo. O mesmo vale para o brilho da tela, que costuma ter impacto real maior na autonomia.
Configuração final recomendada
Depois dos testes, este foi o ponto de equilíbrio mais interessante para o seu MacBook Air 7,2:
- bateria com saúde boa
- TLP ativo
- governor mantido em schedutil
- CPU_MAX_PERF_ON_BAT=60
- Bluetooth desligado quando não precisar
- brilho de tela moderado
- uso consciente do Chrome e de tarefas multimídia
Arquivo final usado no ajuste
O arquivo principal criado por você ficou assim:
JavaScriptCPU_MAX_PERF_ON_BAT=60Caminho:
JavaScript/etc/tlp.d/10-macbook-air.confComo validar depois de reiniciar
Sempre que quiser conferir se continua tudo certo, rode:
JavaScriptsudo tlp-stat -p upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep -E 'energy-rate|time to empty|percentage'O ideal é observar esses números em três cenários:
- sistema parado
- uso leve
- navegador aberto com seu uso normal
Resultado prático esperado
No seu caso, a autonomia saiu de um cenário mais preocupante para algo bem mais aceitável. Com consumo na faixa de 7,7 W, a conta teórica com a sua bateria cheia fica perto de 4,3 horas em uso semelhante ao teste. Na prática, isso pode variar conforme brilho de tela, número de abas, vídeo, chamadas, Wi-Fi e carga gráfica.
Conclusão
O problema de bateria do seu MacBook Air 7,2 no Ubuntu não era uma bateria condenada. Era principalmente um problema de consumo em uso real. O diagnóstico correto veio ao separar saúde da bateria de taxa de descarga, e a correção veio ao aplicar um ajuste coerente com esse hardware: instalar o TLP, manter schedutil, limitar CPU_MAX_PERF_ON_BAT para 60% e confirmar tudo com medições.
Esse é o tipo de ajuste que faz sentido porque é simples, reversível e baseado no comportamento real do equipamento.