Google complica acesso ao kernel dos Pixel e irrita a comunidade

Durante anos, o kernel dos Pixel foi um dos poucos exemplos em que a Google fazia mais do que a licença a obrigava. Código no Git, histórico completo de commits, árvores de dispositivo, binários de drivers. Agora, esse cenário está a encolher e com burocracia pelo meio.

Segundo o projeto GrapheneOS, a Google deixou de disponibilizar o kernel source dos Pixel por repositórios públicos com download direto. Em vez disso, quem quer o código tem de preencher um formulário Google Forms e esperar que alguém, do outro lado, envie um ficheiro pelo Google Drive. O que antes demorava horas está a demorar semanas. Para quem mantém ROMs alternativas ou faz auditoria de segurança, isto quebra ciclos de desenvolvimento inteiros.

O alvo aqui é o kernel Linux específico dos Pixel, base essencial para construir, testar e depurar ROMs custom, portar Android para novos dispositivos e validar patches de segurança. O GrapheneOS que muita gente escolhe precisamente por reforçar a privacidade em Pixel fica preso a este funil: não há lançamento sem primeiro receber e testar o kernel respetivo. Pior, a Google está a fornecer o código como um único ficheiro, sem um histórico de alterações facilmente navegável, o que dificulta seguir bugs, regressões e o impacto de cada patch.

Isto não acontece no vazio. Desde o Android 16 que a Google tirou os Pixel do centro da AOSP. O alvo de referência passou a ser o dispositivo virtual Cuttlefish e, ao mesmo tempo, deixaram de ser publicados device trees e binários de drivers dos Pixel. A empresa que anda a meter dinheiro em iniciativas como a OpenROAD para puxar pelo silício open source está a encolher a abertura precisamente na linha de produtos que usa para vender a sua visão “pura” de Android.

Na prática, atrasos no código-fonte significam atrasos em tudo o resto: portas independentes de Android, testes de kernel, correções de segurança. Quem está em Portugal e importa um Pixel ou compra via retalhistas europeus depende destas comunidades para ter mais controlo sobre o equipamento que tem no bolso. Bloquear o fluxo de código é uma forma discreta, mas eficaz, de recentrar o poder na ROM oficial e afastar quem quer alternativas.

Curiosamente, o GrapheneOS diz que os futuros modelos Motorola que vai suportar escapam a este bloqueio, porque o projeto trabalha diretamente com a marca e aloja o seu próprio código. Ou seja, o problema não é “open source é complicado”, é a escolha da Google em colocar um formulário e semanas de espera onde antes havia um comando git. A empresa ainda não explicou a mudança, nem prometeu reduzir os prazos. Se isto é descuido burocrático ou estratégia deliberada, o efeito é o mesmo: cada vez menos transparência em torno do hardware que a própria Google usa como montra para o Android.

Fonte: Open Source For You