O AOSP não está morto, mas o Google simplesmente deu um grande golpe para as ROMs personalizadas

No início deste ano, o Google anunciou que desenvolveria o sistema operacional Android totalmente em particular para simplificar seu processo de desenvolvimento. Ao focar seus esforços em uma única filial interna, o Google pretendia otimizar o trabalho anteriormente dividido. As notícias inicialmente assustaram alguns na comunidade de desenvolvimento do Android, mas a controvérsia diminuiu rapidamente. O impacto foi mínimo, pois o Google já estava desenvolvendo a maior parte do Android a portas fechadas e prometeu que os lançamentos de código -fonte continuariam. Agora, no entanto, uma omissão recente do Google reacendeu os medos de que a empresa pare de compartilhar o código -fonte para novos lançamentos do Android. O Google afirmou que essas preocupações são infundadas, mas outras novas mudanças dificultam a prosperidade da comunidade de ROM personalizada em dispositivos de pixel.

O AOSP está indo embora? O Google diz não

Conforme prometido, o Google publicou o código -fonte do Android 16 nesta semana, permitindo que desenvolvedores independentes compilassem suas próprias construções do novo sistema operacional. Esse código fonte foi enviado para o projeto de código aberto do Android (AOSP), como de costume, sob a licença permissiva do Apache 2.0.

No entanto, vários desenvolvedores notaram rapidamente uma omissão flagrante do Android 16 -fonte de liberação: as árvores de dispositivos para dispositivos de pixel estavam ausentes. O Google também não conseguiu fazer o upload de novos binários de driver para cada dispositivo Pixel e lançou o código -fonte do kernel com um histórico de commit squashed. Como o Google compartilhou as árvores de dispositivos, os binários de driver e o histórico de cometer do código -fonte completo do kernel por anos, sua omissão no lançamento desta semana foi preocupante.

Essas omissões levaram alguns a especular nesta semana que o Google estava dando o primeiro passo em um plano para interromper a AOSP. Em resposta, o vice -presidente e GM do Google da plataforma Android, Seang Chau, refutou essas reivindicações. Ele abordou a especulação em um post em xafirmando que “o AOSP não está desaparecendo”.

Ele também confirmou que a omissão de árvores de dispositivos Pixel é intencional, afirmando que “a AOSP precisa de um alvo de referência flexível, configurável e acessível – independentemente de qualquer hardware em particular, incluindo os do Google”. Em vez de apoiar o AOSP, se baseia nos dispositivos Pixel, o Google suportará o dispositivo virtual do Android “Cuttlefish” como seu alvo de referência. O Cuttlefish é executado em PCs, permitindo que os desenvolvedores do Google e da plataforma testem novos recursos de hardware. O Google também continuará suportando alvos GSI, que são imagens genéricas do sistema que podem ser instaladas em quase qualquer dispositivo Android.

Por um lado, essa lógica é sólida. O Google quer se afastar do uso de pixels como dispositivo de referência do AOSP e está fazendo alterações nesse efeito. Como observa Seang Chau, “o AOSP foi construído sobre a base de ser uma plataforma aberta para implementações de dispositivos, fornecedores de SOC e arquiteturas de conjuntos de instruções”. Nesse sentido, o Cuttlefish é um alvo de referência mais apropriado, porque não é uma peça de hardware de consumidor fortemente personalizada, como um telefone pixel. No entanto, como o Cuttlefish é um dispositivo virtual, ele pode simular apenas como os recursos de hardware se comportam, tornando -o uma referência imperfeita de alguma maneira.

A questão mais significativa, no entanto, é o impacto que essa decisão terá sobre os desenvolvedores que construem ROMs personalizados – o termo da comunidade para os garfos hobbys da AOSP. Nolen Johnson, um colaborador e revisor de longa data do projeto Lineageos, diz que o processo de construção dessas ROMs para os telefones de pixel se tornará “doloroso” avançando.

Anteriormente, o Google simplificou para os desenvolvedores criarem os dispositivos de pixels da AOSP, mas esse suporte agora desapareceu. Os desenvolvedores simplesmente tiveram que “puxar as configurações [that] O Google criou “, adicione suas personalizações e, em seguida, construa. Agora, no entanto, eles precisarão pegar as árvores de dispositivos antigas que o Google lançou para o Android 15 e“ Adivinhe cegamente e engenheiro reverso do pré -edifício [binaries] Que mudanças são necessárias a cada mês. ”

Isso ocorre porque fazer uma compilação completa do Android para um dispositivo – não apenas um GSI – requer uma árvore de dispositivos. Esta é uma “coleção de arquivos de configuração que definem o layout de hardware, periféricos, listagens de arquivos proprietários e outros detalhes para um dispositivo específico, permitindo que o sistema de construção construa uma imagem adequada para esse dispositivo”. Enquanto o Google lidou com esse trabalho anteriormente, os desenvolvedores agora devem criar suas próprias árvores de dispositivos sem acesso ao código -fonte proprietário necessário.

Além disso, a decisão do Google de esmagar o histórico de comprometimentos do código -fonte do kernel também dificulta o desenvolvimento personalizado. O código -fonte do kernel do pixel era frequentemente usado como um “ponto de referência para outros dispositivos para obter recursos, correções de bugs e patches de segurança”, mas com a história agora reduzida a uma única confirmação, isso não é mais viável.

Embora o Google não tenha nenhuma obrigação de liberar árvores de dispositivos, fornecer binários de motorista ou compartilhar o histórico completo de comprometimento do kernel (na verdade, é um dos poucos fabricantes de dispositivos para fazer essas coisas), o faz há anos. A razão da empresa para isso foi porque o pixel foi tratado como uma plataforma de referência para a AOSP, portanto, os desenvolvedores precisavam de uma maneira fácil de construir.

A decisão do Google de agora interromper o pixel como um dispositivo de referência da AOSP é lamentável, pois puxou o tapete de desenvolvedores como as equipes da Lineageos e grafeneos que constroem Android para dispositivos de pixels. Esses desenvolvedores ainda poderão construir o AOSP para dispositivos de pixels, mas agora será mais difícil e doloroso do que antes.