O Google planeja mudar para um modelo de desenvolvimento “upstream first” para recursos do kernel Linux no Android a partir de 2023. Continue lendo para saber mais.
Quando você vê as palavras “Android” e “fragmentação” na mesma frase, sua mente provavelmente salta imediatamente para o Gráfico de distribuição de versões do Android. Existem algumas entidades para as quais a maioria das pessoas aponta o dedo ao reclamar que as atualizações do sistema operacional Android demoram a ser implementadas em todos os níveis, mas há um limite para o que o Google pode fazer para força OEMs desenvolvam e implementem atualizações mais rapidamente. O que o Google pode fazer, entretanto, é reduzir o tempo de desenvolvimento e, portanto, o custo de implementação de atualizações.
A primeira grande iniciativa do projeto de longo prazo do Google para reduzir os encargos de desenvolvimento é Projeto Agudos. Anunciado junto com o Android 8.0 Oreo em 2017, o Project Treble modularizou o Android separando a estrutura do sistema operacional da implementação do fornecedor (HALs e o fork do kernel Linux específico do dispositivo). Isso tornou mais fácil para os OEMs do Android rebasearem seus sistemas operacionais na estrutura AOSP mais recente, pois eles poderiam inicializar a versão mais recente sem a necessidade de código atualizado dos fornecedores. Como resultado, os OEMs poderiam preparar seus forks Android personalizados mais rapidamente do que antes e, por extensão, lançar atualizações importantes do sistema operacional mais rapidamente.
O próximo passo nos planos do Google era agilizar a entrega de atualizações aos principais componentes do Android. O Google chamou essa iniciativa Linha principal do projeto quando o apresentou junto com o Android 10 em 2019. O Google essencialmente assumiu o controle dos principais componentes do sistema operacional e proibiu os OEMs de modificá-los. Em seguida, eles configuraram um mecanismo de entrega por meio do Google Play para que pudessem lançar atualizações remotamente para esses componentes principais, sem ter que esperar que os próprios OEMs aplicassem os patches. A Mainline melhorou muito a rapidez com que os dispositivos recebem versões atualizadas de componentes importantes do sistema operacional, melhorando, por sua vez, a segurança do ecossistema Android como um todo.
Mas o que vem a seguir é ainda mais importante e é sem dúvida a parte mais importante da estratégia de longo prazo do Google. Quando apontamos anteriormente como Treble modularizou o Android, separando a estrutura do sistema operacional do implementação do fornecedor, incluímos o "fork do kernel Linux específico do dispositivo" como parte desse fornecedor código. Qualquer pessoa familiarizada com o Linux em desktops reconhecerá um problema: por que ele está incluído no código de fornecedor de código fechado? O problema é que, embora os dispositivos Android sejam fornecidos com o kernel Linux, esse kernel apresenta um muito de código fora da árvore.
Como chegamos lá? O problema, conforme descrito pelo engenheiro de software do Google, Todd Kjos, em Conferência de encanadores Linux deste ano (através da ArsTechnica), é porque o kernel principal do Linux é bifurcado várias vezes antes de ser lançado em um dispositivo Android. O Google transforma cada kernel Linux principal em um "Kernel comum do Android", que acompanha de perto o lançamento da linha principal, mas adiciona alguns patches específicos do Android. Fornecedores de SoC como Qualcomm, MediaTek e Samsung então bifurcam que kernel para cada SoC que eles fabricam. Os OEMs então pegam o kernel específico do SoC e adicionam patches adicionais para implementar suporte para o hardware específico que desejam enviar.
Devido a essas mudanças, "até 50% do código em execução em um dispositivo é código fora da árvore (não de kernels upstream Linux ou AOSP comuns)", segundo o Google. A grande quantidade de código fora da árvore nesses dispositivos torna a fusão de alterações upstream um processo longo e desafiador. Isso é prejudicial à segurança dos dispositivos, pois os OEMs precisam trabalhar mais para implementar patches para vulnerabilidades descobertas no kernel do Linux. Além disso, isso deixa a maioria dos dispositivos Android com versões de kernel antigas, o que significa que eles perdem os novos recursos do kernel Linux.
Em um esforço para resolver esse problema, o Google está trabalhando no Android Generic Kernel Image (GKI), que é essencialmente um kernel compilado diretamente de uma ramificação ACK. O GKI isola personalizações de fornecedores de SoC e OEM para módulos de plug-in, eliminando código fora da árvore e permitindo que o Google envie atualizações do kernel diretamente para o usuário final. Por mais de um ano, o Google vem trabalhando em uma maneira de entregar atualizações do GKI por meio da Play Store, através do uso de um módulo Mainline.
De acordo com nossas fontes, os dispositivos lançados com Andróide 12 e fornecidos com o kernel Linux 5.10 devem implantar uma imagem de inicialização assinada pelo Google. Próprio do Google Pixel 6 A série será lançada com Android 12 pronto para uso e com kernel Linux 5.10, portanto, os dois telefones podem ser os primeiros dispositivos do mercado de massa a serem fornecidos com um GKI.
Além disso, Todd Kjos do Google revelou que a empresa planeja mudar para um modelo de desenvolvimento “upstream first” para novos recursos do kernel Linux. Isso ajudará o Google a garantir que o novo código chegue primeiro ao kernel principal do Linux, o que reduzirá a dívida técnica futura acumulada com a chegada de mais códigos fora da árvore em dispositivos Android.
Na Linux Plumbers Conference esta semana, Kjos disse: "Como os módulos fora da árvore são realmente importantes para o nosso caso de uso, esperamos que sempre tenhamos um conjunto de exportações e algumas coisas que são diferentes ou adicionais ao que está upstream, mas todo esse projeto é um projeto de vários anos, trabalhando para nos livrarmos do maior número possível de manchas fora da árvore e alinharmos o máximo possível com rio acima." O Google pretende concluir seu trabalho de upstreaming de recursos existentes e isolar mudanças de fornecedores até o final de 2022 e, a partir de 2023, a empresa planeja adotar esse modelo de desenvolvimento "upstream first" para evitar tais problemas no futuro.