O Google anunciou uma mudança significativa no cronograma de liberação do código fonte do Android Open Source Project (AOSP), passando de quatro para apenas dois lançamentos por ano a partir de 2026. A empresa concentrará as publicações nos segundo e quarto trimestres, priorizando atualizações consideradas mais relevantes para o desenvolvimento da plataforma.

Essa alteração visa alinhar o processo ao modelo de desenvolvimento trunk-stable, que busca maior estabilidade para todo o ecossistema Android. Um aviso já aparece no site oficial do AOSP, recomendando que desenvolvedores utilizem o branch android-latest-release em vez do tradicional aosp-main.

A decisão não afeta a distribuição de patches de segurança mensais, que continuarão sendo liberados regularmente em um ramo dedicado.

Motivos da mudança no cronograma

O Google explicou que a cadência anterior, com releases trimestrais, aumentava a complexidade interna ao exigir o gerenciamento de múltiplos ramos de código simultaneamente. Essa abordagem dificultava a manutenção de coerência e segurança em todas as versões.

Ao reduzir para dois lançamentos anuais, a empresa pretende oferecer uma base mais previsível e sólida para fabricantes de dispositivos e desenvolvedores. A concentração em Q2 e Q4 corresponde às atualizações principais de meio de ano e às menores de final de ano, que geralmente trazem mudanças mais impactantes para a plataforma.

Recomendações para desenvolvedores

Desenvolvedores que constroem ou contribuem para o AOSP devem migrar para o novo branch android-latest-release. Esse ramo sempre apontará para a versão mais recente publicada publicamente, evitando dependência do aosp-main, que não refletirá mais o estado em tempo real do projeto.

Essa transição facilita o trabalho com uma versão estável, reduzindo riscos de instabilidade em builds personalizadas. O Google reforça que a mudança simplifica o fluxo de desenvolvimento sem comprometer o acesso ao código aberto.

Manutenção das atualizações de segurança

As patches mensais de segurança permanecerão inalteradas, sendo publicadas em um branch específico como ocorre atualmente. Essa separação garante que dispositivos Android continuem recebendo correções de vulnerabilidades de forma regular, independentemente do cronograma de código fonte completo.

Fabricantes parceiros, como os de grande porte, já recebem acesso antecipado a códigos privados, o que não altera seus pipelines de desenvolvimento.

Novo modelo trunk-stable em detalhes

O modelo trunk-stable adota um tronco único de desenvolvimento, com recursos ativados por flags até estarem prontos para uso geral. Essa estratégia evita ramificações excessivas e promove uma base mais uniforme para todo o ecossistema.

• Reduz complexidade no gerenciamento de branches paralelos.
• Aumenta a previsibilidade para OEMs e comunidades de custom ROMs.
• Mantém foco em releases com mudanças relevantes para desenvolvedores.
• Preserva o compromisso com o open source, segundo a empresa.

Essa abordagem já vinha sendo implementada gradualmente, com delays observados em alguns releases de 2025.

Efeitos no ecossistema Android

A mudança pode exigir ajustes em projetos que dependem de acesso frequente ao código mais recente, como comunidades de ROMs personalizadas. No entanto, o Google argumenta que releases menos frequentes, mas mais consolidados, resultam em código mais maduro e seguro.

Para usuários finais, o impacto é mínimo, pois atualizações de sistema vêm diretamente dos fabricantes. A estabilidade maior da plataforma pode beneficiar a longo prazo a fragmentação e a entrega de features em dispositivos variados.

Perspectivas para o desenvolvimento futuro

Com o novo ritmo, o Q2 deve trazer a grande atualização anual, enquanto o Q4 focará em refinamentos com APIs novas. Essa concentração permite que o Google entregue versões mais testadas, alinhando-se a práticas de concorrentes que priorizam ciclos anuais robustos.

O ecossistema Android, que equipa bilhões de dispositivos globalmente, ganha com uma fundação mais controlada. Desenvolvedores independentes precisarão planejar ciclos mais longos, mas contam com patches de segurança contínuos.