Exclusivo Google decide acabar com o código aberto do Android
Para efeitos de reportagens e discussões puramente interessantes, Ai Faner conduziu várias "deduções na mesa de areia" sobre as estratégias de empresas de tecnologia conhecidas e imaginou muitos cenários.
Mas eu não esperava que a situação mais improvável estivesse realmente acontecendo com o Google.
AOSP (Android Open Source Project) é um projeto de código aberto liderado pelo Google que fornece estrutura básica e componentes principais para todos os sistemas operacionais de dispositivos Android. É equivalente a uma “sala em branco” onde os desenvolvedores podem baixar, modificar e distribuir livremente seu código e construir sistemas personalizados baseados nele, incluindo Xiaomi HyperOS, vivo OriginOS, OPPO ColorOS e até mesmo o sistema Android de telefones Pixel, todos baseados em AOSP.
A manutenção do Android pelo Google é dividida em dois caminhos: a filial pública do AOSP está aberta a desenvolvedores de todo o mundo, contém código-fonte aberto puro e não envolve nenhum serviço proprietário do Google. Qualquer fabricante ou indivíduo pode desenvolver um sistema baseado neste ramo. A filial interna de código fechado está disponível apenas para fabricantes que assinaram o acordo GMS (Google Mobile Services).
Especificamente, o Google não manterá mais a atual filial pública do AOSP, fechará gradualmente os recursos de suporte relacionados e poderá parar de atualizar o código-fonte de componentes fora das obrigações legais de código aberto (código sob GPL e outros acordos).
A partir da próxima semana, todo o desenvolvimento do Android será feito exclusivamente nas filiais internas do Google. Após um período de tempo, a agência externa poderá deixar de ser pública ou até mesmo ser totalmente fechada. Além disso, as ferramentas e ambientes de integração/entrega contínua (CI/CD) do AOSP também podem ser encerrados, e até mesmo o Android Gerrit (https://android-review.googlesource.com/) pode ser encerrado. A partir de agora, apenas funcionários do Google poderão acessar as filiais internas do AOSP ou enviar códigos. O processo de desenvolvimento do Android não será mais transparente.
De uma perspectiva de alto nível, o Google reduzirá gradualmente o conteúdo incluído no AOSP até que o AOSP não exista mais como um projeto de código aberto e como um conceito.
Tomando a história como guia, o projeto OpenSolaris (ou seja, o projeto de código aberto correspondente ao sistema operacional Solaris), depois que a Oracle adquiriu a Sun e anunciou "código aberto atrasado" para OpenSolaris, não abriu mais da metade do código sob a licença CDDL até que o departamento de desenvolvimento do Solaris fosse dissolvido.
Ninguém sabe se a promessa do Google à Android Authority de “continuar com o código aberto, apenas adiá-lo” são apenas palavras vazias – afinal, o adiamento indefinido também é uma espécie de adiamento.
De acordo com o entendimento de Ai Faner, a idéia geral do código fechado do Android é, em última análise, reter apenas as partes de código aberto exigidas pela licença de infecção forte da GPL, principalmente drivers e patches de estado do kernel Linux. Outras partes das camadas intermediárias e superiores que anteriormente usavam licenças livres de código aberto, como o Apache, eventualmente serão de código fechado ; futuras versões do Android não serão mais lançadas publicamente ou atualizadas após o lançamento do código-fonte.
O nível de tomada de decisão sobre este assunto é da alta administração do Google. Acredita-se que tomarão esta decisão o mais tardar no início de 2025. A execução de toda a estratégia será concluída durante um período mais longo, pelo menos durante vários anos, até que o AOSP perca completamente o seu significado.
O verdadeiro motivo da mudança do Google ainda não está claro, mas de acordo com a análise e entendimento de Ai Faner, é principalmente para economizar despesas e aumentar receitas :
AOSP possui vários pipelines de código e um grande número de ramificações em diferentes dimensões (como número de versão, progresso de lançamento, etc.). Tendo em conta os códigos upstream e downstream do projeto e a colaboração entre múltiplas empresas, torna-se ainda mais complicado, tornando a manutenção e a gestão muito difíceis, resultando numa grande quantidade de recursos informáticos e custos homem-hora. O Google pode querer economizar nesses custos. Considerando que o departamento Android proporcionou a todos os funcionários a opção de “demissão voluntária” no início de 2025, a lógica de corte de despesas não é difícil de entender. Além disso, os fabricantes que assinaram um acordo de parceria também são obrigados a agrupar os serviços do Google para aumentar as receitas de publicidade do Google, o que por sua vez aumenta a receita global da empresa.
Felizmente, actualmente, o impacto directo do AOSP de código fechado na indústria não é catastrófico, e o impacto intuitivo nos utilizadores finais de telemóveis também é mínimo.
A maioria dos principais fabricantes de telefones celulares já assinou vários acordos de parceria autorizada com o Google. Os fabricantes sob os acordos existentes ainda podem obter e usar o código-fonte Android mais recente, obter a certificação Google GMS, normalmente pré-instalar serviços e aplicativos como Google Play e Gmail e receber suporte do Google. Todos os negócios permanecem normalmente.
O impacto real não será mostrado diretamente, mas será refletido lateralmente durante um longo período de tempo. Isso será explicado em detalhes posteriormente.
AOSP, não existe mais?
Os seguintes pontos precisam de esclarecimento:
- Como a maior parte do código AOSP é lançada sob a licença Apache 2.0, qualquer pessoa pode fazer um fork de uma cópia. Existem também vários espelhos AOSP em outras plataformas de serviço de código, como GitHub e a comunidade Android doméstica. O Google não tem o direito de colocar outras bases de código AOSP "não oficiais" off-line. O que foi de código aberto não pode ser revogado.
- Em outras palavras, desde que possa ser baixado de outros canais não oficiais, as pessoas ainda podem usar o código AOSP atualizado mais recentemente do Google e modificá-lo de acordo com suas próprias necessidades. Em princípio, se você tiver desenvolvedores poderosos o suficiente, poderá transformar o AOSP anterior em seu próprio sistema para mantê-lo e atualizá-lo.
O Android/AOSP nunca foi um verdadeiro projeto de código aberto, e os fundamentalistas da comunidade sempre o criticaram.
Conforme mencionado anteriormente, o Android atualmente roda no kernel Linux, que é de código aberto sob a licença GPL. A GPL é uma licença altamente contagiosa que exige que todos os trabalhos derivados sejam de código aberto de acordo com a licença GPL, implementando assim o espírito de código aberto ilimitado e expandindo a comunidade.
Para construir o ecossistema empresarial Android, o Google criou um modelo de licenciamento que equilibra o código aberto e as necessidades comerciais. O Google divide a plataforma Android em várias partes: a parte subjacente do kernel Linux permanece sob a licença GPL v2 (conforme necessário), enquanto a maior parte do código AOSP adota a licença mais permissiva Apache 2.0. Essa estrutura de licenciamento permite que os fabricantes de dispositivos modifiquem e personalizem o Android sem precisar abrir o código-fonte de todas as modificações, ao mesmo tempo que permite que as empresas criem aplicativos e serviços proprietários na plataforma Android. O serviço proprietário do Google, GMS (Google Mobile Services), é separado do AOSP e adota termos de licenciamento diferentes. Esta abordagem híbrida cria um modelo que mantém a abertura e ao mesmo tempo proporciona flexibilidade comercial ao ecossistema.
Especificamente, o kernel Linux é baseado na licença GPL. Embora o módulo do kernel precise ser de código aberto forçado de acordo com a GPL, os aplicativos do espaço do usuário não são afetados pelo contágio da GPL e, portanto, não precisam ser de código aberto. Alguns aplicativos do espaço do usuário também são diferentes das distribuições Linux tradicionais, como o uso de libc biônico em vez de glibc, o uso de toybox em vez de busybox, etc. Além disso, o Google também usa a "Camada de Abstração de Hardware" (HAL), que permite aos fabricantes armazenar informações comerciais confidenciais que eles não desejam divulgar, como o código e a lógica por trás de algumas funções proprietárias específicas, nesta camada, que fornece uma ABI (Application Binary Interface) estável para que os fabricantes possam atualizar seu código proprietário independentemente da camada de estrutura Android.
Claro, a Linux Foundation estava muito insatisfeita com os métodos operacionais do Google que violavam o espírito do código aberto, e uma vez removeu o AOSP do projeto de código aberto Linux.
O resultado é que a camada inferior do AOSP é de código aberto de acordo com a GPL, e um grande número de camadas intermediárias são de código aberto vagamente (código parcialmente fechado) de acordo com o Apache. Os aplicativos baseados nisso podem escolher seus próprios atributos de código aberto e fechado de acordo com os desejos e propósitos comerciais do desenvolvedor.
O próprio Google faz isso. Na verdade, desde o Android 4.4 KitKat em 2013, todas as versões do Android não são mais totalmente de código aberto. Alguns dos drivers, UI e um grande número de produtos e serviços principais na camada de aplicativo desenvolvida pelo Google para o sistema Android, também conhecido como pacote GMS, são todos de código fechado.
O AOSP existe, mas não é um Android completo. É por isso que muitos desenvolvedores de sistemas enfatizarão que o “Android nativo” (referindo-se ao sistema operacional Google Nexus/Pixel) não é igual ao AOSP.
Embora o AOSP seja um projeto de código aberto, o Google não costuma mesclar solicitações de mesclagem enviadas por terceiros (a fusão do código AOSP requer a aprovação dos funcionários do Google, e muitos PRs morrem na Gerrit Review). Isso também é o que muitos desenvolvedores acreditam ser a maior diferença entre o AOSP e os projetos típicos de código aberto. Isso torna difícil para os participantes obterem um verdadeiro sentimento de participação no AOSP.
No site oficial do projeto AOSP, o Google escreveu esta “filosofia de governança”:
O Google lidera a AOSP, responsável pela manutenção e desenvolvimento do Android. Embora o Android consista em vários subprojetos, o AOSP é estritamente gerenciado pelo projeto. O Google trata e gerencia o Android como um produto de software único e monolítico, em vez de um lançamento, especificação ou coleção de peças substituíveis. A intenção do Google é que os fabricantes de dispositivos portem o Android em seus dispositivos; eles não impõem especificações nem selecionam lançamentos.
Esta passagem descreve as intenções do Google com bastante clareza. Se o AOSP é um burro que trabalha, então chegou a hora de matar o burro.
Que impacto o código fechado do Android trará?
Conclusão importante: as principais marcas de telefones e seus usuários não têm nada com que se preocupar.
Primeiro, vamos revisar o acordo entre o Google e o OEM do Android:
- AOSP, qualquer fabricante pode usar o AOSP para desenvolvimento sem o consentimento do Google;
- Contrato de Compromisso de Compatibilidade Android ACC, Contrato de Distribuição de Aplicativos Móveis MADA, Contrato Suplementar de Dispositivos Empresariais EDLA, etc., para citar alguns. Através de acordos, são estabelecidas restrições comerciais entre o Google e os OEMs. Somente os OEMs que assinaram o acordo ACC podem desenvolver sistemas operacionais através do AOSP e chamá-los de sistemas operacionais Android, e obter os direitos de uso da marca registrada Android e outros direitos.
- O Google Mobile Services GMS inclui funções de back-end, como núcleo de serviço e sistema de conta do Google, bem como aplicativos de front-end, como Google Play Store, YouTube, Gmail e Agenda. Somente quando a empresa assinar o acordo acima e o modelo do celular passar no teste de compatibilidade do Google o GMS poderá ser pré-instalado.
A combinação de ACC, MADA/EDLA e outros protocolos garante que o Google tenha controle absoluto sobre o sistema operacional Android.
A maioria das marcas atuais de telefones celulares Android, incluindo Xiaomi, vivo, OPPO, Samsung, etc., assinaram acordos com o Google. Se não houver surpresas, o Google deveria tê-los contatado para tranquilizá-los e garantir que a cooperação futura continuasse normalmente.
No passado, um número considerável de fabricantes de equipamentos e chips usavam o AOSP para desenvolver produtos, mas não obtinham a certificação de dispositivos Android do Google. O dispositivo não precisava ser pré-instalado com o GMS Family Bucket e poderia evitar os requisitos de certificação do Google.
Existem bilhões ou até dezenas de bilhões de dispositivos Android não certificados. Através deste AOSP de código fechado, o Google pode induzir os fabricantes de equipamentos não certificados a se curvarem e assinarem os vários acordos mencionados acima.
Uma situação muito provável é que o código do sistema de cockpit inteligente desenvolvido com base no AOSP não possa mais ser fornecido gratuitamente a fabricantes em todo o mundo. A menos que as montadoras assinem um acordo com o Google, elas não conseguirão obter o código mais recente. É claro que as montadoras também podem continuar a usar o desenvolvimento de sistemas antigos de código aberto.
Isso não é um fato que aconteceu, apenas uma possibilidade. A decisão do Google de fechar o código-fonte do Android desta vez não descarta um pequeno motivo de tentar reconquistar o mercado de dispositivos não certificados, ou pelo menos obter uma fatia dele. Embora este grande mercado tenha sido criado pelos próprios fabricantes de equipamentos, não seria o que é hoje sem o AOSP.
Nesta perspetiva, os consumidores de dispositivos Android não certificados poderão ser afetados, embora, claro, isso não seja óbvio. O impacto vem principalmente do aspecto financeiro: se os OEMs quiserem continuar a pré-instalar o sistema operacional Android, eles devem cumprir o gerenciamento e os requisitos do Google para dispositivos. Este custo será obviamente repercutido nos consumidores, resultando no pagamento de preços mais elevados. Além disso, os consumidores só podem utilizar canais como o Google Play para baixar aplicativos. O espaço vital dos mercados de aplicativos de terceiros (como o F-Droid) também se tornou menor. O Google também pode cobrar uma taxa por todos os pagamentos no aplicativo.
Alguns fabricantes podem não estar dispostos a submeter-se ao Google e os seus produtos serão retirados do mercado, reduzindo as escolhas dos consumidores; mas, ao mesmo tempo, qualquer código AOSP lançado pelo Google antes de fechar o código-fonte ainda pode ser usado em teoria. Os fabricantes podem bifurcar o código à vontade e desenvolvê-lo, atualizá-lo e mantê-lo por conta própria. Estima-se que os consumidores de refrigeradores inteligentes não se importarão se o refrigerador vem pré-instalado com o sistema operacional Android mais recente.
No entanto, isso pode estar de volta ao clichê da "fragmentação do Android": se os fabricantes de dispositivos não autorizados continuarem a seguir seu próprio caminho e usar códigos antigos, não mais mantidos oficialmente para desenvolver produtos, então a fragmentação pode não ser tão simples quanto um número de versão – mas pode ser semelhante à China de hoje, com push, versão, função, aparência, nome, experiência, etc.
Violação dos direitos do desenvolvedor
O código fechado do AOSP tem um impacto mais óbvio nos desenvolvedores de ROM de aplicativos Android de terceiros.
A cena em que centenas de escolas de pensamento competiram em ROMs de terceiros para Android também será enterrada pela história. O melhor resultado para os desenvolvedores de ROM é usar a versão atualizada mais recente do AOSP para modificá-lo e, em seguida, manter a versão atual até que ela se torne lentamente desatualizada, até que finalmente desistam do projeto.
Quanto aos desenvolvedores de aplicativos, eles ainda podem obter o SDK de que precisam do Google e não deve haver muito impacto direto na era pós-AOSP.
Porém, antes disso, devido ao considerável grau de fragmentação do Android, os desenvolvedores precisavam obter códigos de sistema de diferentes fabricantes e dispositivos como máquinas de teste, a fim de se adaptarem a diversas versões do sistema e diversas marcas de modelos. Este é um custo significativo para as pequenas e médias empresas, especialmente para os promotores independentes. Não está claro se esta situação se tornará mais grave no futuro.
Se o ambiente de vida dos pequenos e médios promotores for ainda mais pressionado, o efeito de transmissão será que os fortes serão sempre fortes, a inovação será restringida e ocorrerão mais monopólios. Portanto, depois que o Google tiver feito o que deveria fazer, deverá fornecer planos de acompanhamento para garantir a sobrevivência dos pequenos e médios desenvolvedores.
A abordagem mais extrema, mas menos inesperada
Anteriormente, no contexto da dissociação tecnológica entre a China e os Estados Unidos, Ai Faner tinha concebido várias possibilidades para o Android "cortar o fornecimento" aos fabricantes chineses de telemóveis: proibir a exibição de marcas registadas Android em telemóveis vendidos no estrangeiro, proibir a pré-instalação de GMS, fechar "diretamente" a fonte AOSP aos fabricantes chineses, e até suspender a autorização destes fabricantes e cancelá-los/retirá-los da OHA.
De todas as possibilidades, o AOSP de código totalmente fechado é o menos provável. Ai Faner certa vez pensou que era muito vergonhoso fazer isso.
Na fase inicial de dispositivos móveis inteligentes, o Google tomou a decisão de abrir o código-fonte do Android, que não só ganhou reputação de tecnologia aberta, mas também conquistou um grande número de fabricantes e usuários de Symbian, Windows Mobile, Nokia e BlackBerry na época.
É claro que Nokia, BlackBerry e Microsoft fizeram desvios, o que desempenhou um grande papel para ajudar o Google a vencer. Mas o Android de código aberto do Google é, sem dúvida, a decisão mais correta no caminho para conquistar mais de 70% da participação do Android no mercado de sistemas operacionais móveis hoje.
Ainda existem funcionários no Google que reconhecem a importância e o valor a longo prazo do código aberto na popularização da tecnologia. Seja por requisitos comerciais e superiores, ou por status pessoal, eles escrevem código e fazem trabalhos de manutenção para o projeto Android, e a AOSP também é a transportadora desses trabalhos. No entanto, o valor comercial do AOSP para Android e Google não é mais o mesmo.
Embora a principal motivação para esta operação seja a economia de custos, no longo prazo, ela também ajudará o Google a aumentar as receitas. Afinal, no passado, foi difícil para o Google obter receitas diretas ou benefícios indiretos, como dados de dispositivos não certificados que executavam sistemas operacionais baseados em AOSP.
Antes deste incidente, o Google ganhava dinheiro através do Android principalmente cobrando dos OEMs pela autorização e certificação no âmbito de um acordo de parceria. Para usar o Android dentro de uma estrutura de conformidade comercial, os fabricantes precisam assinar um acordo. Detalhes como o conteúdo e o método do acordo específico podem ser diferentes, mas as regras gerais permanecem inalteradas. A principal fonte de receita do Google são as receitas de publicidade e o compartilhamento de aplicativos obtidos por meio de aplicativos e serviços pré-instalados do Google (pesquisa, Play Store, etc.).
Obviamente, equipamentos não certificados não podem gerar receita para o Google, mas a existência do AOSP é “um vestido de noiva para as pessoas”. Como qualquer empresa comercial, temo que queira se desligar desses equipamentos e fabricantes o mais rápido possível.
# Bem-vindo a seguir a conta pública oficial do WeChat de Aifaner: Aifaner (WeChat ID: ifanr). Conteúdo mais interessante será fornecido a você o mais rápido possível.
