Android aberto ameaçado: Google corta o AOSP, e isso é só o começo

Junto com o lançamento do Android 16, o Google lançou uma versão aberta do sistema AOSP (Android Open Source Project), que agora não possui os componentes que estavam presentes antes, escreve o Android Authority. Isso levantou preocupações na comunidade de desenvolvedores de que o Google pretende encerrar o projeto, mas a empresa negou.

Fonte da imagem: Kelly Sikkema/unsplash.com

No início deste ano, o Google anunciou que desenvolveria o Android inteiramente internamente para simplificar o processo — uma única ramificação otimizaria significativamente o trabalho anteriormente dividido. A mudança teve pouco impacto na comunidade, visto que a empresa já vinha criando grande parte do código da plataforma a portas fechadas. Com o Android 16, um desenvolvedor lançou o código AOSP sob a licença tradicional Apache 2.0, e foi revelado que ele não continha as árvores de dispositivos Pixel e os binários de driver, e tinha um histórico de commits truncado.

O Google havia se mostrado satisfeito em publicar todos esses dados e, ao fazê-lo, gerou uma nova onda de preocupações sobre o fim do suporte ao AOSP. O vice-presidente do Google e gerente geral da plataforma Android, Seang Chau, teve que refutá-los. Ele explicou que “o AOSP precisa de um dispositivo de referência flexível, personalizável e acessível — independente de qualquer hardware específico, incluindo o do Google”. Portanto, agora a empresa oferecerá suporte a um dispositivo de referência virtual chamado Cuttlefish, que roda em um PC e permite testar novos recursos de hardware. O Google também se comprometeu a oferecer suporte a Imagens Genéricas do Sistema (GSI), que são instaladas em praticamente qualquer dispositivo Android.

Fonte da imagem: Denny Muller / unsplash.com

Por um lado, isso faz sentido: a empresa abandonou o uso de dispositivos Pixel como dispositivos de referência para o AOSP e fez as alterações apropriadas. Por outro lado, o Cuttlefish é um dispositivo virtual e só pode simular a operação de funções de hardware, portanto, tal referência não pode ser considerada completa. Na prática, isso complicará significativamente o desenvolvimento de compilações alternativas do Android para dispositivos Pixel, informou o projeto LineageOS. Em particular, será necessário usar árvores de dispositivos do código do Android 15 e adivinhar quais alterações foram feitas nos binários pré-compilados a cada mês, ou recorrer à engenharia reversa. Uma árvore de dispositivos é um conjunto de arquivos de configuração que definem o layout do hardware, periféricos, listas de arquivos proprietários e outros dados para um dispositivo específico, necessários para criar a imagem correta. Anteriormente, o Google fazia esse trabalho sozinho, mas agora os desenvolvedores terão que criar suas próprias árvores de dispositivos sem acesso ao código-fonte correspondente.

Outro problema pode ser a decisão do Google de unificar o histórico de commits do kernel, que antes era usado para extrair recursos, corrigir bugs e fechar vulnerabilidades. Mas quando todo o histórico é reduzido a um único commit, isso não é mais possível. O Google não se comprometeu a publicar árvores de dispositivos, hospedar drivers binários ou compartilhar o histórico completo de commits do kernel, mas já faz isso há anos. Como resultado, os dispositivos Pixel agora estão reduzidos ao nível de abertura dos dispositivos Android comuns. Ainda é fácil desbloquear o bootloader e obter uma imagem de fábrica em telefones Google, mas os desenvolvedores agora precisam trabalhar mais para garantir que as compilações alternativas funcionem de forma confiável.