noticias
Android 17 passa a limitar memória por aplicativo para evitar que um processo prejudique todo o celular
Uma das mudanças mais importantes do Android 17 acontece longe dos menus, animações e recursos que normalmente aparecem nas apresentações do sistema. O Google começou a impor limites de memória individualizados aos aplicativos para impedir que um único processo consuma RAM em excesso e degrade o funcionamento de todo o aparelho.
A tecnologia, chamada de **Memory Limiter**, já está sendo utilizada nos aparelhos Pixel compatíveis com Android 17 e deve chegar gradualmente a dispositivos de outros fabricantes. O mecanismo foi projetado para funcionar tanto em celulares de entrada, com pouca memória disponível, quanto em modelos de alto desempenho equipados com 12 GB, 16 GB ou mais de RAM.
A ideia é relativamente simples: um aplicativo deixa de ter liberdade prática para crescer indefinidamente dentro da memória enquanto o Android encerra outros processos para acomodá-lo. Quando determinado software ultrapassa o orçamento estabelecido pelo sistema, a pressão passa a ser tratada primeiro dentro daquele próprio processo.
Isso altera uma parte importante da maneira como o Android administra um dos recursos mais disputados de um smartphone moderno.
O Android passa a responsabilizar o aplicativo que está consumindo memória demais
O Android possui mecanismos de gerenciamento de memória há muitos anos. Quando a quantidade de RAM disponível cai demais, o sistema procura liberar espaço, podendo remover processos armazenados em segundo plano para garantir que o aplicativo atualmente utilizado continue funcionando.
Esse modelo funciona razoavelmente bem quando vários programas estão utilizando memória de maneira normal. O problema aparece quando um único aplicativo apresenta vazamento de memória, mantém estruturas grandes demais ou simplesmente continua aumentando seu consumo.
Nessas situações, outros aplicativos podem acabar sendo encerrados antes que o verdadeiro responsável pelo problema seja contido.
É aquele comportamento bastante conhecido em aparelhos pressionados por falta de memória: o usuário alterna para o navegador e a página recarrega, volta para uma rede social e perde a posição onde estava ou retorna para outro programa e percebe que ele precisa iniciar novamente.
O Memory Limiter procura impedir justamente esse efeito dominó.
Em vez de esperar que a escassez de RAM se transforme em um problema global, o Android 17 passa a restringir individualmente o processo responsável pela pressão.
Como funciona o Memory Limiter do Android 17
Por baixo da interface gráfica, o mecanismo depende de uma tecnologia bastante conhecida no universo Linux: os **control groups**, ou cgroups.
O Android é baseado no kernel Linux, e os cgroups permitem organizar processos em grupos e estabelecer regras sobre recursos como processador e memória. No Android 17, o Google utiliza a versão mais recente dessa arquitetura, chamada cgroup v2, para aplicar limites de memória aos processos dos aplicativos.
O sistema acompanha quanto cada processo está consumindo e pode estabelecer um valor máximo adequado à quantidade de RAM existente no aparelho e ao estado do aplicativo.
Um programa que está sendo exibido na tela recebe uma tolerância maior. Aplicativos executados fora da área visível trabalham com limites mais restritos.
Isso faz sentido porque jogos, navegadores, editores de vídeo e outras aplicações interativas podem precisar temporariamente de grandes volumes de memória enquanto estão sendo utilizadas.
O ponto central é que essa margem deixa de ser ilimitada.
O Android não fecha o aplicativo imediatamente
Ultrapassar determinado nível de consumo não significa que o Android simplesmente encerre o aplicativo naquele instante.
Existe uma sequência de tentativas para recuperar memória antes disso.
Quando o processo alcança o limite de pressão definido pelo sistema, o kernel procura liberar páginas de memória que possam ser descartadas ou reconstruídas posteriormente.
Outra parte dos dados pode ser deslocada para a **zRAM**.
A zRAM cria dentro da própria memória física uma área na qual páginas pouco utilizadas ficam comprimidas. Em outras palavras, o sistema tenta guardar a mesma quantidade de informação ocupando menos espaço.
É uma técnica importante em smartphones porque armazenamento interno é muito mais lento do que RAM e porque dispositivos móveis precisam equilibrar desempenho, consumo de energia e quantidade limitada de memória.
A compressão, evidentemente, não produz memória gratuitamente.
O processador precisa comprimir e descomprimir os dados, criando algum custo computacional. Se um aplicativo estiver constantemente pressionando o limite, ele pode começar a apresentar queda de desempenho antes mesmo de ser encerrado.
Caso o processo continue crescendo e o sistema não consiga mais acomodar suas alocações, novas solicitações de memória podem falhar e o aplicativo pode acabar terminado.
A diferença é que o problema tende a permanecer concentrado naquele processo.
Celulares mais baratos podem sentir uma diferença maior
A estratégia ganha importância particular em dispositivos com pouca RAM.
A documentação técnica do Android prevê diferentes limites conforme a classe de memória disponível no aparelho. Um telefone equipado com 4 GB não pode permitir que um único processo se comporte da mesma forma que em um aparelho com 16 GB.
Nos parâmetros de referência do sistema, dispositivos de 4 GB permitem aproximadamente 2 GiB para determinados processos visíveis, enquanto processos fora da tela ficam próximos de 1 GiB.
À medida que a quantidade de memória aumenta, esses limites também sobem.
Em aparelhos com 8 GB, por exemplo, processos visíveis podem trabalhar com um orçamento muito maior, próximo de 5 GiB. Modelos na classe de 16 GB podem oferecer aproximadamente 10 GiB para aplicações visíveis.
Esses números não significam que um aplicativo receberá automaticamente toda essa memória.
Eles representam as fronteiras a partir das quais o mecanismo de proteção começa a exercer maior pressão.
O aplicativo que está na tela recebe tratamento diferente
A distinção entre processos visíveis e não visíveis é uma das partes mais relevantes da arquitetura.
Quando o usuário está interagindo com um jogo, editor de vídeo ou navegador, existe uma expectativa natural de que aquele software tenha prioridade sobre tarefas que estão executando discretamente em segundo plano.
Por isso, o Android permite um orçamento maior de memória para processos ligados diretamente à experiência que está aparecendo na tela.
Quando esse mesmo aplicativo deixa de ocupar a interface principal, sua posição dentro da hierarquia pode mudar.
Essa característica exige atenção especial dos desenvolvedores de softwares que realizam tarefas longas em segundo plano.
Manter uma notificação permanente ou executar um serviço não significa necessariamente receber o mesmo orçamento destinado a uma atividade visualmente ativa.
Jogos, edição de vídeo e inteligência artificial estão entre as cargas mais sensíveis
A maioria dos aplicativos provavelmente nunca encontrará o limite em condições normais de funcionamento.
Programas mais exigentes, porém, precisarão observar com maior atenção seu comportamento.
Jogos carregam texturas, mapas, áudio e diversos recursos durante a execução. Editores de fotografia e vídeo trabalham com imagens grandes, quadros descompactados e buffers temporários. Navegadores podem acumular dezenas de páginas e processos simultaneamente.
Aplicações capazes de executar modelos de inteligência artificial diretamente no smartphone também entram nessa categoria.
Um modelo local pode precisar manter pesos, caches, embeddings ou outros dados na memória durante uma inferência. Dependendo da arquitetura utilizada, alguns desses recursos ocupam centenas de megabytes ou até vários gigabytes.
Isso não significa, entretanto, que o Memory Limiter seja uma tecnologia criada especificamente para inteligência artificial.
Para o Android, não importa se a memória está sendo consumida por um modelo generativo, um jogo ou um aplicativo com erro de programação. O mecanismo observa o recurso utilizado, não a finalidade do software.
Desenvolvedores não poderão ignorar a regra usando versões antigas do Android como alvo
Uma consequência importante da mudança é que o Memory Limiter faz parte do comportamento do sistema operacional.
A política pode ser aplicada mesmo a aplicativos desenvolvidos tendo versões anteriores do Android como alvo.
Isso reduz uma saída bastante comum no ecossistema: manter configurações antigas para adiar adaptações a determinadas mudanças de plataforma.
Nesse caso, a solução passa necessariamente pela engenharia do aplicativo.
Desenvolvedores precisarão monitorar melhor alocações, identificar vazamentos, reduzir objetos desnecessariamente mantidos na memória e testar seus programas em aparelhos com quantidades diferentes de RAM.
O Android também oferece mecanismos para ajudar nessa investigação.
Informações sobre encerramentos de processos podem indicar quando o Memory Limiter esteve envolvido, facilitando a diferenciação entre um encerramento provocado pelo sistema e uma falha convencional do aplicativo.
Mais RAM deixou de ser uma solução confortável para software cada vez maior
Existe também uma questão econômica por trás dessa arquitetura.
Durante muitos anos, a evolução dos smartphones criou uma espécie de colchão para aplicações pouco eficientes. Enquanto a quantidade de RAM aumentava rapidamente, parte do crescimento do consumo de software podia ser absorvida simplesmente instalando mais memória nos aparelhos.
Essa dinâmica tem limites.
O próprio Google relacionou a expansão do mecanismo à necessidade de lidar com aparelhos que podem manter ou até reduzir determinadas configurações de memória em um cenário de custos maiores dos componentes.
Isso torna a otimização novamente relevante.
Um sistema operacional usado em bilhões de dispositivos não pode assumir que todos os smartphones futuros terão 16 GB ou 24 GB de RAM.
Boa parte do mercado continuará operando com 4 GB, 6 GB ou 8 GB por bastante tempo.
Ao colocar limites sobre os processos, o Google está essencialmente transferindo parte dessa responsabilidade novamente para os desenvolvedores.
Não basta esperar que o próximo celular tenha memória suficiente para esconder o problema.
Há também uma disputa silenciosa sobre quem controla os recursos do aparelho
Uma característica interessante da implementação é a tentativa de tornar a política relativamente uniforme entre aplicativos.
A documentação de referência não trata o Memory Limiter como um sistema construído para oferecer exceções arbitrárias a determinados aplicativos.
Isso pode ser particularmente relevante em aparelhos Android vendidos por fabricantes que instalam dezenas de programas próprios.
Se a política for implementada como planejado, aplicativos comuns pré-instalados também deverão conviver com as mesmas restrições aplicadas aos softwares baixados posteriormente pelo usuário.
Processos essenciais do sistema naturalmente possuem outra lógica, porque encerrá-los poderia comprometer o funcionamento do próprio telefone.
A diferença parece pequena, mas toca em uma discussão importante sobre plataformas digitais: quem tem permissão para consumir os recursos físicos que pertencem ao usuário?
Um aplicativo do fabricante não deveria receber automaticamente carta branca para monopolizar memória apenas porque veio instalado de fábrica.
A solução também pode criar novos problemas
Colocar um limite rígido sobre memória não transforma gerenciamento de recursos em uma ciência perfeitamente previsível.
Existem aplicações que realmente precisam trabalhar com enormes conjuntos de dados.
Um editor de vídeo processando conteúdo em alta resolução ou um jogo carregando uma região complexa podem apresentar picos legítimos de utilização.
Se os parâmetros forem agressivos demais, o mecanismo destinado a melhorar a estabilidade pode gerar efeitos colaterais.
Um aplicativo pressionado repetidamente contra a zRAM pode precisar realizar mais operações de compressão e recuperação. Isso utiliza processador e pode aumentar latência.
Em situações extremas, usuários poderão simplesmente perceber que determinado programa começou a fechar depois de uma atualização do sistema.
Para eles, a causa técnica será praticamente invisível.
É bastante provável que surjam episódios em que desenvolvedores responsabilizem fabricantes, fabricantes apontem para aplicativos e usuários concluam simplesmente que “o Android 17 está fechando tudo”.
É justamente por isso que ferramentas de diagnóstico serão importantes durante a expansão da tecnologia.
Análise da equipe
O Memory Limiter representa uma mudança mais significativa do que sua baixa visibilidade sugere.
Durante muito tempo, sistemas móveis administraram falta de memória tentando preservar aquilo que parecia mais importante naquele momento. O novo modelo acrescenta uma camada diferente de responsabilidade: antes de sacrificar o restante do ambiente, o Android tenta conter o processo que está causando a pressão.
É uma mudança arquitetural saudável.
Quando um aplicativo consome recursos de maneira anormal, vários outros programas não deveriam precisar pagar essa conta sendo eliminados da memória.
A estratégia também chega em um momento interessante.
Smartphones estão recebendo recursos cada vez mais pesados, principalmente em jogos, multimídia e inteligência artificial executada localmente. Ao mesmo tempo, não existe garantia de que a quantidade de RAM crescerá indefinidamente na mesma velocidade.
O Google está deixando claro que eficiência continuará fazendo parte da equação.
Ainda assim, os Pixel representam apenas uma pequena parcela do ecossistema Android.
O teste realmente importante acontecerá quando Samsung, Xiaomi, Motorola, Oppo e outros fabricantes começarem a combinar essa política com seus próprios sistemas de gerenciamento de memória, economia de bateria e processos em segundo plano.
Android possui uma longa história de comportamentos diferentes dependendo do fabricante.
Uma regra elegante no Android Open Source Project pode assumir características bastante diferentes quando atravessa dezenas de implementações comerciais.
Se o Google conseguir manter parâmetros consistentes, o resultado será um sistema mais previsível para desenvolvedores e potencialmente mais estável para usuários.
Se cada fabricante decidir reinterpretar agressivamente os limites, o ecossistema poderá ganhar mais uma variável que equipes de software precisarão testar.
Há uma ironia discreta nessa mudança.
Em uma indústria obcecada por anunciar mais memória, mais processamento e mais inteligência artificial, uma das melhorias potencialmente mais úteis do Android 17 consiste simplesmente em ensinar os aplicativos a não ocupar tudo o que encontram pela frente.
Se funcionar bem, ninguém verá o Memory Limiter trabalhando.
Os aplicativos simplesmente permanecerão disponíveis por mais tempo, o sistema sofrerá menos com pressão extrema de RAM e um software problemático terá mais dificuldade para transformar seu comportamento em problema de todos os outros.
Para uma tecnologia de infraestrutura, desaparecer da percepção do usuário costuma ser sinal de que o trabalho foi bem-feito.
👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis