Android 17: Limites de memória por app e endurecimento de áudio em segundo plano

O Android 17 completou o seu ciclo de betas e encontra-se atualmente na fase de lançamento estável. A versão final foi apresentada oficialmente durante o Android Show 2026, realizado a 12 de maio, marcando o início de uma nova era para o sistema operativo da Google. De acordo com as notas de versão oficiais, a última beta estável (Beta 4.1) foi lançada a 1 de junho de 2026, com um nível de patch de segurança de maio de 2026.

O lançamento inicial centra-se nos dispositivos Pixel, mas a Google confirmou que os fabricantes de equipamento original (OEM) começarão a implementar estas funcionalidades nos seus próprios dispositivos ao longo do próximo ano. Esta transição gradual permite que desenvolvedores e utilizadores se adaptem aos novos comportamentos do sistema sem uma interrupção abrupta da experiência do utilizador.

Uma das alterações mais significativas no Android 17 é a introdução de limites de memória por aplicação. Até agora, a única restrição real era o limite do heap, que variava enormemente entre dispositivos. Com o Android 17, cada aplicação opera sob um limite de memória que escala com a RAM total do dispositivo, criando um ambiente mais estável e determinístico.

Se uma aplicação exceder o seu orçamento de memória alocado, o sistema toma medidas progressivas para proteger a resposta do dispositivo. Primeiro, as páginas da aplicação são forçadas para zRAM (RAM comprimida). Se a pressão de memória persistir, a aplicação pode ser ralentada ou terminada. Esta abordagem proativa evita que uma única aplicação com fugas de memória cause lentidões em todo o sistema, maior consumo de bateria ou a terminação de outras aplicações em segundo plano.

O Android 17 também introduz um endurecimento do áudio em segundo plano que restringe as interações de áudio quando a aplicação não está visível. A partir desta versão, o framework de áudio aplica restrições à reprodução de áudio, às solicitações de foco de áudio e às APIs de alteração de volume. Para que uma aplicação possa interagir com o áudio em segundo plano, deve ter uma atividade visível ou estar a executar um serviço em primeiro plano que não seja do tipo SHORT_SERVICE.

Esta medida visa garantir que as alterações de áudio sejam iniciadas intencionalmente pelo utilizador. Se uma aplicação tentar chamar as APIs de áudio enquanto não está num ciclo de vida válido, a reprodução e as alterações de volume falharão silenciosamente, sem lançar uma exceção ou fornecer uma mensagem de erro. Isto afeta diretamente aplicações de streaming, mensageiros e qualquer software que dependa da reprodução automática ao ligar auscultadores ou dispositivos Bluetooth.

Para os desenvolvedores, a otimização da pegada de memória é agora essencial para evitar o estrangulamento do sistema operativo. A Google recomenda estabelecer uma linha de base de memória e utilizar as novas métricas Android vitals para medir o consumo. As aplicações que seguem a abordagem "lançar na memória e esquecer" são as mais propensas a serem afetadas, especialmente aquelas intensivas em imagens ou que carregam muita multimédia no arranque.

Os utilizadores avançados notarão uma maior estabilidade no multitarefa, mas também uma maior rigidez na forma como as aplicações gerem o áudio. Nos dispositivos Pixel, não há um interruptor simples para desativar estas restrições; os utilizadores devem recorrer a comandos ADB para contornar as limitações. No entanto, alguns fabricantes, como a Samsung com a One UI 9, estão a oferecer opções ocultas para desativar estas restrições, o que representa um desvio notável do comportamento padrão do Android.

A introdução destes limites marca uma mudança de paradigma na gestão de recursos do Android. Anteriormente, o sistema era autocorretivo, mas reativo: o sistema operativo só intervinha quando o low-memory killer começava a colher processos em segundo plano. Agora, a intervenção é proativa e baseada em orçamentos de memória definidos pelo sistema.

Esta evolução responde à tendência dos novos dispositivos de manter ou mesmo diminuir a sua capacidade de memória física em resposta ao aumento dos preços da memória, enquanto os utilizadores continuam a esperar a mesma experiência de alto desempenho. Ao estabelecer limites claros, o Android 17 procura equilibrar a procura de recursos das aplicações modernas com a necessidade de manter o dispositivo rápido e fiável.

Os desenvolvedores devem testar as suas aplicações no Android 17 e modificá-las conforme necessário para suportar estas alterações. Podem determinar se uma sessão da sua aplicação foi afetada pelos limites de memória chamando getDescription em ApplicationExitInfo; se a aplicação foi afetada, a razão de saída será REASON_OTHER e a descrição conterá detalhes específicos.

Para os utilizadores, a recomendação é manter as suas aplicações atualizadas e estar atentos a possíveis mudanças no comportamento das aplicações de áudio e multimédia. Se uma aplicação deixar de reproduzir áudio em segundo plano, é provável que precise de uma atualização do desenvolvedor para cumprir as novas restrições do Android 17. A transição para um sistema mais inteligente e otimizado requer uma colaboração contínua entre desenvolvedores, fabricantes e utilizadores.