O Android sempre foi “open source”. Até agora.

Quinze anos. Esse foi o tempo que o Google levou para quebrar uma das regras mais básicas do ecossistema Android: toda nova API vai para o AOSP antes de chegar aos aparelhos. Parece uma promessa boba, mas é exatamente essa promessa que manteve o Android diferente do iOS por mais de uma década. Fabricantes como Samsung, Xiaomi e OnePlus podiam construir seus próprios sistemas em cima do código aberto, e projetos como GrapheneOS e LineageOS existiam justamente por causa dessa abertura.

Com o Android 17 QPR1, lançado em 15 de setembro de 2026, o Google decidiu que algumas APIs novas são exclusivas do Pixel. Sem código aberto. Sem acesso para outros OEMs. Sem patches de segurança compartilhados no tempo certo. A última vez que algo assim aconteceu foi com o Android 3.0 Honeycomb, lá em 2011, quando o Google manteve o código-fonte fechado para evitar que fabricantes colocassem uma interface de tablet em celulares.

Eu achei que tinham aprendido com o fiasco do Honeycomb. Aparentemente, não.

O que mudou no Android 17 QPR1

Para quem não acompanha o ciclo de releases do Android: desde o Android 16, o Google mudou a cadência dos QPRs (Quarterly Platform Releases). QPR1 e QPR3 passaram a ser exclusivos do Pixel. QPR2 e QPR4 vão para o AOSP e ficam disponíveis para todos os fabricantes.

Isso, por si só, já era questionável. Mas o Android 17 QPR1 foi além. Pela primeira vez desde o Honeycomb, o Google adicionou APIs novas para desenvolvedores de apps dentro de um QPR1, sabendo que esse release não vai para o AOSP.

Na prática, isso significa:

• Desenvolvedores podem usar essas APIs apenas em Pixels
• Outros fabricantes (Samsung, Xiaomi, Motorola) não têm acesso ao código
• Projetos open source como GrapheneOS ficam impossibilitados de implementar as features
• As APIs só devem chegar ao AOSP no QPR2, em dezembro de 2026

O Google publicou a documentação das diferenças de API entre o Android 17 e o QPR1, mostrando que existem novas APIs. Só que o código por trás delas está trancado dentro do Pixel OS.

GrapheneOS abre o jogo

O GrapheneOS, projeto de sistema operacional focado em segurança e privacidade baseado no Android, não ficou quieto. Daniel Micay e a equipe publicaram uma série de posts no Mastodon detalhando os problemas.

Segundo o GrapheneOS, o projeto já portou seu código para o Android 17 QPR1, mas não tem permissão para lançar a atualização. Em vez disso, a equipe está trabalhando num processo de backporting: pegando firmware, drivers de kernel, drivers de userspace e HALs (Hardware Abstraction Layers) do QPR1 e trazendo de volta para o Android 17 base.

Parece gambiarra? Porque é. Um projeto que existe há anos contribuindo para a segurança do ecossistema Android agora precisa fazer engenharia reversa para manter seus usuários protegidos.

E o problema vai além das APIs.

Patches de segurança retidos

Talvez o ponto mais grave dessa história não seja sobre features novas, mas sobre segurança. O September 2026 Pixel Update Bulletin contém patches de segurança que não estão no Android Security Bulletin regular.

Leia de novo: existem correções de segurança para componentes padrão do Android (usados em todos os aparelhos, não apenas Pixels) que só foram distribuídas no boletim do Pixel.

Isso significa que:

O GrapheneOS foi direto: “Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs.” Traduzindo: o Google não deveria estar segurando patches de segurança do código padrão da plataforma Android.

Esses patches só devem chegar aos outros fabricantes com o QPR2 em dezembro. Três meses de janela de vulnerabilidade. Três meses em que quem não tem Pixel está exposto a falhas que o Google já corrigiu.

O histórico do Honeycomb

Para entender por que isso é tão sério, vale voltar a 2011. O Android 3.0 Honeycomb foi o primeiro (e, até agora, único) Android a não ter seu código publicado no AOSP imediatamente.

Na época, a justificativa do Google era que o Honeycomb tinha sido projetado para tablets, e permitir que fabricantes colocassem a interface em celulares criaria uma experiência ruim. Andy Rubin, então chefe do Android, prometeu que era temporário.

A comunidade não gostou. A decisão gerou uma crise de confiança que demorou anos para o Google reverter. Quando o Android 4.0 Ice Cream Sandwich saiu, o código foi publicado no AOSP normalmente, e o Google passou a mensagem de que aquilo não aconteceria de novo.

Quinze anos depois, aconteceu. Com uma diferença: em 2011, o Google pelo menos reconheceu que estava fazendo algo incomum. Em 2026, a empresa simplesmente mudou a estrutura dos QPRs e esperou que ninguém notasse.

GPL e a lentidão no código-fonte

Outro ponto que o GrapheneOS levantou: o Google está demorando para cumprir obrigações da GPL (General Public License). O projeto solicitou o código-fonte do kernel em 1 de setembro. O acesso só veio mais de duas semanas depois, e não pelo Git (como seria padrão), mas por um link do Google Drive.

Google Drive. Para código GPL. Em 2026.

A GPL exige que qualquer pessoa que distribua software baseado em código GPL disponibilize o código-fonte de forma razoável e em tempo hábil. Mandar um link do Google Drive depois de duas semanas de espera dificilmente se qualifica como “razoável” para um projeto do tamanho do Android.

Essa não é a primeira vez que o Google tem problemas com cumprimento de GPL. Em 2021, a Software Freedom Conservancy já havia criticado a empresa por práticas semelhantes. O padrão se repete: distribuir binários compilados, demorar para liberar o código, e dificultar o acesso quando ele finalmente sai.

Por que o Google está fazendo isso?

A resposta curta: dinheiro e controle.

O Pixel nunca foi um sucesso de vendas comparado a Samsung ou Xiaomi. Mas com a exclusividade de features, o Google cria um incentivo direto para consumidores comprarem Pixels. Se o seu Pixel tem patches de segurança três meses antes de qualquer outro aparelho e APIs que nenhum outro fabricante oferece, por que você compraria um Samsung?

Tem também a questão do “trunk stable development model”. O Google anunciou em 2026 que publicaria código no AOSP apenas no Q2 e Q4, alegando que isso garante estabilidade para o ecossistema. Na prática, isso significa que o AOSP fica com código atrasado em relação ao Pixel por até três meses, duas vezes por ano.

É uma estratégia de “embrace, extend, extinguish” em câmera lenta:

1. Embrace: cria um sistema open source que atrai fabricantes
2. Extend: adiciona features exclusivas no Pixel
3. Extinguish: torna o AOSP tão defasado que fabricantes dependem cada vez mais do Google

Quem é velho o suficiente para lembrar do que a Microsoft fez com o Java e com protocolos web nos anos 90 reconhece o padrão.

O impacto para desenvolvedores

Se você desenvolve apps Android, a situação cria um dilema. As novas APIs do QPR1 são documentadas, então você sabe que elas existem. Mas se você implementar funcionalidades usando essas APIs, seu app só vai funcionar em Pixels até dezembro.

Para apps corporativos e B2B, isso é irrelevante: ninguém vai lançar um app só para Pixel. Para indie devs e quem quer estar na frente, é tentador: usar APIs exclusivas pode dar uma vantagem temporária no ecossistema Pixel.

O problema real é a fragmentação. O Android já sofre com diferentes versões rodando em diferentes aparelhos. Adicionar APIs que só existem em uma marca por três meses piora um cenário que o Google gastou anos tentando melhorar com programas como Project Treble e Mainline.

// Checando se a API exclusiva está disponível
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.BAKLAVA_QPR1) {
    // API disponível — mas só no Pixel até dezembro
    newFeature.enable()
} else {
    // Fallback para 95% dos dispositivos Android
    legacyFeature.enable()
}

Essa checagem condicional vai ser a realidade por pelo menos três meses. Mais um if no código. Mais uma condicional para testar. Mais um cenário de fragmentação para gerenciar.

O que projetos como GrapheneOS podem fazer?

A situação do GrapheneOS é particularmente difícil. O projeto conseguiu portar seu sistema para o QPR1, mas não pode distribuí-lo. A alternativa é backportar firmware e drivers do QPR1 para o Android 17 base, o que é tecnicamente possível, mas trabalhoso e propenso a bugs.

O GrapheneOS também mencionou que os Pixels estão ficando “significantly harder to support”. Cada release que traz componentes proprietários torna mais difícil manter um sistema alternativo que depende do hardware do Pixel.

Para o LineageOS e outras ROMs custom, o impacto é similar: patches de segurança atrasados e APIs inacessíveis até que o QPR2 saia.

A comunidade open source do Android sempre dependeu da boa vontade do Google em manter o AOSP atualizado. Quando essa boa vontade evapora, as opções são limitadas:

• Backporting manual (caro, lento, frágil)
• Pressão pública (o que o GrapheneOS está fazendo agora)
• Migração para outro ecossistema (quem vai para onde?)
• Ações legais baseadas em violação de GPL (possível, mas demorado)

O elefante na sala: existem alternativas?

Uma das reações mais comuns no Hacker News foi “just use Linux”. Sim, existem alternativas mobile como o PureOS da Purism, o postmarketOS e o Ubuntu Touch. Nenhuma delas está nem perto de ser utilizável para 99% das pessoas.

O iOS é proprietário por design. O Android era a alternativa “open source”. Se o Android deixar de ser efetivamente open source, a computação mobile inteira fica nas mãos de duas empresas que não têm nenhuma obrigação real de abrir seu código.

Projetos como o /e/OS e o CalyxOS dependem do AOSP tanto quanto o GrapheneOS. Se o AOSP continuar defasado, todos esses projetos sofrem.

Existe um argumento contrário: “o QPR2 vem em dezembro, as APIs estarão disponíveis, relaxa”. E é verdade. Tecnicamente, o Google não está fechando o Android permanentemente. Está criando janelas de exclusividade.

Mas janelas de exclusividade no open source são o primeiro passo para algo pior. Quando a comunidade aceita três meses de atraso sem reclamar, o próximo passo é seis meses. Depois um ano. Depois “vamos ver”.

A cronologia da fechadura

Para quem quer entender como o Google foi reduzindo a abertura do Android ao longo dos anos, aqui vai um resumo:

Cada linha dessa tabela, sozinha, tem uma justificativa técnica razoável. A questão é a direção. E a direção é sempre a mesma: menos código aberto, mais controle do Google.

O que isso significa para o futuro do Android

O Android já não é o mesmo projeto que Eric Schmidt apresentou em 2007 como “a first truly open platform for mobile devices”. O Google Play Services concentra funcionalidades críticas fora do AOSP há anos. O SafetyNet (agora Play Integrity) dificulta a vida de ROMs custom. E agora, APIs e patches de segurança ficam exclusivos do Pixel por meses.

Cada uma dessas mudanças, isoladamente, parece pequena. Juntas, formam um padrão claro: o Android open source está encolhendo enquanto o Android proprietário do Google cresce.

Para quem trabalha com Android profissionalmente, a recomendação prática é simples: teste no Pixel, mas não dependa de APIs exclusivas de QPR1. Espere o QPR2 para adotar novas APIs em produção. E acompanhe o GrapheneOS, que está fazendo o trabalho sujo de documentar cada passo do Google nessa direção.

Agora, se me perguntarem se o Android ainda é open source em 2026, a resposta honesta é: depende do que você quer dizer com “open source”. O código eventual sai. As APIs eventualmente chegam. Os patches de segurança eventualmente ficam disponíveis. Mas “eventualmente” é uma palavra que não combina com software livre.

Fonte de inspiracao: GrapheneOS no Mastodon