Atualização de progresso de código fechado do Android: Google não fornece mais compilação de firmware do Pixel
Em 10 de junho, horário dos EUA, o iFanr descobriu de forma independente que o código AOSP divulgado pelo Google hoje não fornecia o binário do fornecedor dos dispositivos Pixel, ou seja, os arquivos de driver necessários, como nos anos anteriores.
Os arquivos binários oficiais do driver fornecidos pelo Google para cada dispositivo Pixel estão atualmente na versão Android 15.0.0.
O código AOSP da versão 16 do Android fornecido desta vez só pode ser criado como uma "Imagem Genérica do Sistema" (GSI).
O GSI pode ser entendido como um ambiente de teste fornecido aos OEMs, usado apenas para verificar se o hardware do dispositivo é compatível com o sistema operacional Android mais recente e atende às especificações do Google. Não é um sistema completo e carece de muitas funções.
Este novo desenvolvimento não apenas reafirma a situação mencionada no relatório exclusivo do iFanr no final de março de que "o Google está gradualmente reduzindo o AOSP até que ele não exista mais como um projeto de código aberto", mas também cria um enorme obstáculo para sistemas operacionais de terceiros (ROMs) desenvolvidos para dispositivos Pixel.
No passado, o Google liberava o código AOSP e fornecia um binário do fornecedor para dispositivos Pixel ao mesmo tempo. Os desenvolvedores de ROM podem empacotá-lo manualmente para garantir que a ROM suporte o dispositivo completamente.
Como o Google já vinha fazendo isso no passado, trouxe grande conveniência aos desenvolvedores, e todos os dispositivos Pixel têm sido usados como "máquinas de desenvolvimento nativas" por desenvolvedores há muito tempo. Diversas ROMs de terceiros costumam ser adaptadas primeiro aos celulares Pixel.
A partir do Android 16, o Google decidiu não oferecer mais essa conveniência. Os desenvolvedores não poderão modificar o código AOSP, compactá-lo em firmware e instalá-lo em dispositivos Pixel.
Se os desenvolvedores de sistemas operacionais de terceiros (ROM do Android) ainda quiserem continuar trabalhando, a partir do Android 16, eles terão que desmontar o pacote de atualização do Pixel lançado pelo Google por meio de engenharia reversa e fazer muito trabalho de adaptação desnecessário para fazer a ROM suportar o Pixel.
Atualmente, há oito celulares Pixel à venda no mercado americano. Se os desenvolvedores de ROMs quiserem se adaptar a todos eles, precisarão fazer engenharia reversa em cada um deles. Isso limitará severamente o escopo de adaptação de ROMs de terceiros, afetará seu desempenho no mercado e restringirá os usuários que utilizam ROMs de terceiros.
De acordo com o iFanr, em princípio, apenas os parceiros OEM que assinaram um acordo GMS com o Google podem obter o código "AOSP completo" no sentido anterior .
Isso significa ainda que será difícil para ROMs desenvolvidas com base no código AOSP desenvolverem versões baseadas no Android 16, a menos que a equipe de desenvolvimento assine um acordo de licenciamento com o Google de alguma forma, ou obtenha o código que a equipe precisa por meio de outros OEMs que tenham assinado contratos com o Google.
A renomada equipe de ROMs GrapheneOS também confirmou ao iFanr que algumas das situações mencionadas em nossa reportagem já se tornaram realidade. A equipe também está estudando como lidar com essa mudança do Google a curto e longo prazo.
A equipe postou no X (antigo Twitter) que, como a equipe não tem privilégios de parceiro OEM, eles não conseguiram obter o código AOSP em primeiro lugar, e o que obtiveram foi uma "versão castrada" que não tinha o código privado do fabricante.
Essa situação atrasou seriamente o progresso da equipe no desenvolvimento do GrapheneOS baseado no Android 16 e na portabilidade para dispositivos Pixel.
“Fizemos mais preparação para o Android 16 do que para qualquer versão anterior. Como não temos privilégios de parceiro OEM, tivemos que fazer muita engenharia reversa. Até nossos desenvolvedores praticaram com arquivos de portabilidade anteriores.”
No entanto, essas mudanças feitas pela equipe do Android dificultaram muito a portabilidade do Android 16 e versões posteriores. Isso também dificulta o suporte ao GrapheneOS para novos dispositivos Pixel. Parece que precisamos acelerar o progresso dos celulares com GrapheneOS.
Embora não tenham feito contribuições substanciais para os interesses comerciais do Google no passado, os desenvolvedores de ROMs terceirizados ainda são uma parte importante do ecossistema do sistema operacional Android. Muitos dos recursos existentes no sistema operacional Android hoje foram originalmente submetidos ao projeto AOSP por desenvolvedores de ROMs terceirizados.
A equipe do GrapheneOS publicou anteriormente uma publicação tentando recrutar OEMs de forma privada para que lhes fornecessem uma cópia completa do código AOSP. A equipe disse:
O desenvolvimento que fizemos do upstream do Android trouxe benefícios para todos os fabricantes de Android. Se você puder cooperar conosco, será ainda mais beneficiado.
Quanto ao motivo pelo qual o Google fez isso, o iFanr mencionou em um relatório exclusivo anterior:
O código aberto do Android gerou um mercado enorme e segmentado, como ROMs de terceiros e dispositivos Android não certificados. No entanto, com o ecossistema Android já bastante sólido, esses mercados não trazem mais benefícios para o Google. O Google pode não precisar continuar a fornecer mão de obra gratuita para esses mercados por algum motivo semelhante a "manter os benefícios dentro da família".
Fundo
Em março deste ano, relatamos detalhadamente alguns dos grandes planos e mudanças na divisão "Dispositivos e Serviços" do Google, citando uma grande quantidade de informações obtidas de forma independente.
Muitas informações indicam que o Google planeja reduzir a natureza de código aberto do projeto Android por meio de algumas ações discretas. As seguintes ações foram confirmadas:
- O Google não mantém mais o ramo público atual do AOSP e está gradualmente encerrando os recursos de suporte relacionados
- O Google não fornece mais recursos de compilação e criação de dispositivos Pixel para desenvolvedores terceirizados não autorizados.
Entendemos que o Google ainda está discutindo essa questão internamente e ainda não confirmou se fará isso ou qual será a abordagem específica:
- O Google não fornece mais o código-fonte do AOSP fora das obrigações legais de código aberto (como GPL e outras partes do protocolo), mas o fornece sob demanda;
- O lançamento foi adiado, e nem mesmo o código-fonte completo do AOSP estava mais disponível;
- …
A ideia do Google de reduzir gradualmente os atributos de código aberto do Android já está em vigor desde o início de 2025, e a tomada de decisões cabe à alta administração do Google. A implementação de toda a estratégia será concluída ao longo de um período mais longo, pelo menos por vários anos, até que o AOSP perca completamente seus atributos de código aberto.
O objetivo por trás dessas ações que já ocorreram ou ainda estão sendo discutidas não é complicado: elas são principalmente economizar despesas e aumentar a receita.
Felizmente, atualmente, o impacto direto do AOSP de código fechado na indústria não é catastrófico, e o impacto direto nos usuários de telefones celulares também é mínimo.
A maioria dos principais fabricantes de celulares já assinou diversos acordos de parceria autorizados com o Google. Os fabricantes sob o acordo existente ainda podem obter e usar o código-fonte mais recente do Android, obter a certificação Google GMS, pré-instalar o Google Play, o Gmail e outros serviços e aplicativos, além de receber suporte do Google. Todos os negócios continuam normalmente.
O impacto real não ocorrerá diretamente, mas será refletido indiretamente ao longo de um período de tempo mais longo.
Você pode ler os relatórios na época para obter mais detalhes. Se tiver mais detalhes, também agradecemos seus relatórios.
#Bem-vindo a seguir a conta pública oficial do iFanr no WeChat: iFanr (ID do WeChat: ifanr), onde mais conteúdo interessante será apresentado a você o mais breve possível.
