A imagem genérica do kernel do Google é o próximo passo para resolver o problema de fragmentação do Android

O Google vem trabalhando há anos para reduzir a fragmentação no Android, embora parte da causa disso seja a natureza inerente do Android e a faca de dois gumes da escolha e da liberdade. Existem inúmeros OEMs ativos no setor e todos desejam fazer suas próprias modificações em seus próprios dispositivos. O problema então é que parece que as atualizações do sistema operacional Android demoram a ser implementadas em todos os aspectos, mas não há muito que o Google possa realmente fazer para forçar os OEMs a atualizar seus dispositivos. Como tal, a próxima melhor coisa que o Google pode fazer é tornar o processo de atualização o mais fácil e simples possível.

Aliviando a dor de atualização do Android

A primeira grande iniciativa no projeto de longo prazo do Google para reduzir a carga de desenvolvimento foi 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.

Porém, quando se trata de Treble, o kernel do Linux, realisticamente, não deveria ser confundido com código de fornecedor de código fechado. Todd Kjos em Conferência de encanadores Linux deste ano explicou no passado as dificuldades enfrentadas quando se trata de fragmentação no Android, e muito disso agora gira em torno do kernel Linux que os OEMs enviam com seus dispositivos. Para contextualizar, o Google bifurca cada kernel Linux principal em um “Kernel comum do Android”(ACK), 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.

O diagrama acima mostra como o kernel de um dispositivo passa por várias camadas de mudanças que o abstraem do kernel Linux LTS. Para simplificá-lo, começamos com o Kernel Linux, e ele é mesclado ao Kernel Comum do Android com algumas alterações. A partir daí, o kernel comum do Android é mesclado em um kernel de fornecedor (Qualcomm, MediaTek, etc.) com suas próprias modificações e alterações. Finalmente, o kernel do fornecedor é mesclado em um kernel específico do dispositivo OEM. Nesse estágio, o kernel de qualquer dispositivo está muito distante do kernel Linux LTS com o qual foi iniciado.

Como resultado de todas essas bifurcações, até 50% do código executado em um dispositivo Android é código fora da árvore, o que significa que não provém de kernels comuns do Linux upstream ou AOSP. Isso torna incrivelmente difícil (sem mencionar que é demorado e caro) mesclar alterações upstream. Para os OEMs, não há incentivo para fazê-lo, mas essa prática pode ser prejudicial à segurança do dispositivo. É também por isso que muitos dispositivos Android são deixados em versões mais antigas do kernel LTS, o que tem o efeito colateral de os dispositivos perderem acesso aos novos recursos do kernel Linux.

O Android está fragmentado e o Google sabe disso

O Google sabe muito bem que isso é um problema e ainda tem uma seção chamada "Os custos da fragmentação" na documentação do desenvolvedor Android. Google diz isso "a maioria dos dispositivos principais vem com uma versão do kernel que já tem pelo menos 18 meses". Pior ainda, o Google também diz que "O Android 10 suporta kernels 3.18, 4.4, 4.9, 4.14 e 4.19, que em alguns casos não foram aprimorados com novos recursos desde o Android 8 em 2017." Isso dificulta a adição de recursos que exigem novas versões do kernel Linux. O kernel Linux 3.18 foi lançado em dezembro de 2014, quando o Android 5.0 Lollipop era a versão mais recente do Android. Isso é claramente um problema e pode atrasar a plataforma.

Por exemplo, Code Aurora Forum, ou CAF, hospeda o código-fonte de vários SoCs Qualcomm Snapdragon. Qualcomm, como um SoC fornecedor, distribui uma versão bifurcada do kernel Linux para OEMs/ODMs, e essas empresas então adicionam alterações específicas do dispositivo no envio dispositivos. Isto é o que adiciona várias camadas de fragmentação. Além disso, a Qualcomm está fazendo alterações na estrutura AOSP para otimizar o Android para cada uma das plataformas móveis Snapdragon da empresa. A Qualcomm distribui de forma privada seu kernel Linux modificado, estrutura AOSP e outras ferramentas de software para seus parceiros como parte de um Board Support Package, ou BSP. CAF é onde a Qualcomm publica publicamente essas alterações no kernel Linux e na estrutura AOSP.

Esta versão do CAF pode ser útil para desenvolvedores de ROM customizada que desejam usá-la como ponto de partida em vez de AOSP puro, e é por isso que às vezes você vê ROMs “baseadas em CAF” em nossos fóruns. Lembra-se do Snapdragon 625 que parecia alimentar tantos smartphones de gama média durante anos? Que foi lançado com o Linux Kernel 3.18, e somente no final de 2018 (dois anos após o lançamento do chipset) a Qualcomm atualizou as fontes do kernel e as publicou em CAF para msm8953 (o nome do chipset Snapdragon 625) trazendo suporte para Linux Kernel 4.9. O problema é que a maioria dos OEMs não atualizará os telefones para esta nova versão do kernel Linux, especialmente os telefones de gama média dois anos após o chip ter sido lançado. É certo que é muito raro que uma grande atualização do kernel como essa aconteça, mas a questão é que tem aconteceu, então não é apenas um cenário impossível.

Resumindo, a atual fragmentação no Android é uma bagunça, para dizer o mínimo. As últimas tentativas do Google de corrigir essa fragmentação vêm na forma da Imagem Genérica do Kernel, ou GKI.

Apresentando a imagem genérica do kernel

Para resolver essa fragmentação, o Google trabalhou na imagem genérica do kernel do Android (GKI). Este é 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.

Como resultado, os dispositivos iniciados com Android 12 que executam o kernel Linux 5.10.43 ou superior devem seguir um destes procedimentos: de acordo com Mishaal Rahman.

• Implantar uma imagem de inicialização assinada pelo Google

OU

• Implante uma imagem de inicialização com um kernel que exporte um KMI (Kernel Module Interface) que é um subconjunto do KMI exportado pelo GKI, exporta uma API de espaço de usuário que é um superconjunto da UAPI exposta pelo GKI e oferece suporte a todos os recursos do GKI correspondente versão

Os fornecedores podem criar módulos que se conectam ao GKI, mas a ideia do GKI é que o Google assuma a responsabilidade de lidar com as alterações do kernel. A Interface do Módulo Kernel (ou KMI, mais sobre isso nas últimas partes do artigo) é efetivamente onde se espera que o código fora da árvore vá.

A série Google Pixel 6 foi lançada com Android 12 pronto para uso e vem com kernel Linux 5.10, e é o primeiro telefone a ser fornecido com um GKI. Como o Google poderia atualizar o kernel por meio da Play Store, poderemos até ver atualizações frequentes do kernel, já que as atualizações do kernel LTS são normalmente lançadas semanalmente. De qualquer forma, é um sistema muito melhor do que o método atualmente complicado de atualização via OTA, embora isso signifique que está inerentemente vinculado à estrutura GMS.

O Google simplesmente define o GKI como o seguinte:

• É construído a partir das fontes ACK.
• É um binário de kernel único mais módulos carregáveis ​​associados por arquitetura, por versão LTS (atualmente apenas arm64 para android11-5.4 e android12-5.4).
• Ele foi testado com todas as versões da plataforma Android compatíveis com o ACK associado. Não há descontinuação de recursos durante a vida útil de uma versão do kernel GKI
• Ele expõe um KMI estável aos drivers dentro de um determinado LTS.
• Não contém SoC ou código específico da placa.

O Google até quer estar em uma posição até 2023 em que possa adotar um modelo de desenvolvimento “upstream first”. Isso ajudará o Google a garantir que o novo código chegue primeiro ao kernel principal do Linux, reduzindo a “dívida técnica” acumulada no código fora da árvore em dispositivos Android.

A Interface do Módulo Kernel (KMI)

A Kernel Module Interface, ou KMI, faz parte da solução do Google para a fragmentação contínua no Android. Em essência, o suporte ao SoC e à placa não está mais localizado no núcleo do kernel e, em vez disso, é movido para módulos carregáveis. Tanto o kernel quanto os módulos podem ser atualizados independentemente, à medida que os módulos são atualizados em /lib/modules. O GKI em si deve ser o mais limpo e genérico possível, o que é possível descarregando o que agora é código fora da árvore em módulos separados.

Como Ted Kjos explicado em Na Linux Plumbers Conference deste ano, "o grande esforço plurianual é retirar todo o código específico de hardware do kernel genérico e colocá-lo em módulos de fornecedores. Precisamos ter uma interface estável entre esses módulos do fornecedor e o kernel genérico para que eles possam ser enviados de forma assíncrona." O GKI 1.0 é essencialmente um "teste de conformidade".

Na verdade, a compatibilidade GKI significa que o dispositivo passa nos testes VTS e CTS-on-GSI+GKI com a Imagem Genérica do Sistema (GSI) e o kernel GKI instalado atualizando a imagem de inicialização GKI na partição de inicialização e a imagem do sistema GSI no sistema partição. O Vendor Test Suite, ou VTS, é um teste automatizado no qual todos os dispositivos devem passar para serem considerados compatíveis com o Project Treble. O Compatibility Test Suite, ou CTS, é necessário para acessar o conjunto de aplicativos do Google.

Os dispositivos podem ser fornecidos com um kernel de produto diferente e podem usar módulos carregáveis ​​que o GKI não fornece. No entanto, os kernels do produto e do GKI devem carregar módulos das mesmas partições vendor_boot e vendor. Portanto, todos os kernels de produtos devem ter a mesma interface de módulo de kernel binário (KMI).

O diagrama acima mostra o que o Google quer fazer e explica como pretende alcançar esse objectivo. Os módulos Generic Kernel e GKI farão parte do AOSP, e o GKI pode se comunicar com a estrutura Android e a Camada de Abstração de Hardware (HAL) que um fornecedor pode implementar. O código proprietário específico que um fornecedor deseja no kernel (por exemplo, drivers de câmera) será, em vez disso, enviado para um módulo do fornecedor que se tornará uma extensão do GKI por meio do KMI.

Como o GKI pode ajudar a resolver o problema de fragmentação do Android

O Google tem trabalhado muito para agilizar o processo de desenvolvimento de smartphones. Cada OEM deseja ter sua própria identidade de marca e cada OEM deseja poder ter a propriedade de seus dispositivos. Ao contrário do programa Android One, os smartphones Android podem ser praticamente o que quiserem, desde que cumpram o conjunto de regras que o Google estabelece para receber uma licença GMS. No entanto, no passado, o Google não fez muito para controlar o desenvolvimento de dispositivos Android, com mudanças como Project Treble, Mainline e agora o GKI sendo muito mais recente no Android história.

Mas isso ajudará? Deveria servir, embora seja provável que seja um assunto de vários anos que dará frutos visíveis no futuro. Isso se aplicará apenas a dispositivos lançados com Android 12, o que significa que veremos dispositivos que não possuem GKI nos próximos anos. Isso também foi uma crítica ao Project Treble quando foi anunciado, embora obviamente todos os dispositivos lançados hoje em dia o suportem. Essas coisas levam tempo e, à medida que o Google lentamente controla o Android, o processo de desenvolvimento é facilitado para todos os OEMs em o ecossistema Android, mesmo que alguns deles prefiram manter o controle total sobre o kernel Linux usado no Android smartphones.