Atualizações dinâmicas do sistema no Android Q: como o Project Treble melhorará as versões futuras do Android

Juntamente com o lançamento do Android 8.0 Oreo, o Google revelou Projeto Agudos: uma grande rearquitetura na forma como a estrutura do sistema operacional Android e os HALs do fornecedor e o kernel Linux se comunicam. Treble é uma iniciativa importante projetada para reduzir a versão da plataforma Android e fragmentação de patches de segurança, e todos os dispositivos da marca Android lançados com Android Pie são obrigados a oferecer suporte ao Project Treble. OEMs e fornecedores testam a compatibilidade do Treble inicializando uma imagem genérica do sistema (GSI) - uma versão pura do Android do AOSP - e passando o Conjunto de testes de fornecedores (VTS) e imagem de sistema genérica do conjunto de testes de compatibilidade (CTS-on-GSI). O GSI provou ser útil não apenas por permitir que engenheiros de software que trabalham para OEMs testem a compatibilidade do Treble, mas também abriu a porta para um

grande comunidade de ROM personalizada no XDA. Para o lançamento do Android Q, o Google quer tornar os GSIs úteis para outro grupo: desenvolvedores de aplicativos.

Desde a primeira versão estável e a queda do código-fonte de qualquer versão da plataforma Android geralmente vem em agosto, os desenvolvedores que desejam testar a próxima versão do Android em um dispositivo real geralmente precisam de acesso a um smartphone do Google se não quiserem esperar que a atualização chegue ao seu próprio hardware. No entanto, o Google trabalhou com OEMs para trazer uma Android P beta para vários dispositivos no ano passado, e eles acompanharam isso este ano com um AndroidQ beta. Juntamente com uma versão beta oficial do Android Q, o Google este ano também lançou um Q beta oficial GSI portanto, qualquer desenvolvedor com um dispositivo compatível com o Project Treble pode instalar a versão Q mais recente sem ter que esperar meses para que a compilação chegue aos seus dispositivos. Essa nova maneira de testar a próxima versão do Android oferece aos desenvolvedores mais oportunidades e, portanto, mais tempo para testar seus aplicativos. grandes mudanças no Android.

Infelizmente, o método atual de instalando um GSI pode ser difícil. Requer o desbloqueio do bootloader – o que significa limpar todos os dados do usuário e/ou anular a garantia – e exibir uma imagem por meio do protocolo fastboot. Não é um processo rápido e simples para um desenvolvedor de aplicativos, se seu dispositivo ainda permite desbloquear o bootloader. É por isso que, para o últimos meses, o Google trabalhou em uma nova maneira de inicializar GSIs. Insira um novo recurso chamado Dynamic System Update ou DSU.

(Esse recurso foi desenvolvido anteriormente sob os nomes “Live Image”, “Dynamic Android” e “Android on Tap”, então não se surpreenda se o Google o chamar de outra coisa em algumas semanas ou meses.)

Atualizações dinâmicas do sistema no Android Q

O objetivo do recurso DSU é permitir que um desenvolvedor inicialize em um GSI sem interferir na instalação atual. Isso significa que o bootloader não precisa ser desbloqueado e os dados do usuário não precisam ser apagados. O processo de instalação também é bastante simplificado, pois o Google fornece uma interface de linha de comando via ADB e um aplicativo que pode ser controlado por intenções. Esta é a aparência de inicializar um GSI usando DSU:

Neste vídeo*, um Google Pixel 3 XL executando o Android Q beta 3 é reinicializado em um GSI. Nesse ambiente, um desenvolvedor de aplicativo pode instalar e testar seu aplicativo quanto à compatibilidade da Q API. Quando terminarem os testes, eles podem simplesmente reiniciar o software Q beta 3 normal no dispositivo. Você está basicamente inicializando um GSI para poder testar seu aplicativo com segurança!

*Gravamos este vídeo no Google I/O 2019 quando o DSU ainda não estava disponível publicamente, então a versão Q beta 3 do Pixel 3 XL filmado foi ligeiramente modificada pelo Google para incluir suporte ao DSU. Os dispositivos que executam o Q beta 4 e posterior são elegíveis para oferecer suporte ao DSU se atenderem aos requisitos abaixo.

Requisitos para atualizações dinâmicas do sistema

Colocar em funcionamento o que é essencialmente inicialização dupla não foi uma tarefa fácil para o Google. Grandes mudanças tiveram que ser feitas na forma como as partições são gerenciadas no Pixel 3, a plataforma de teste do Google para DSU. Assim, o primeiro requisito importante para suporte DSU é que o dispositivo suporte partições dinâmicas. As partições dinâmicas envolvem uma partição real de armazenamento dividida em partições lógicas redimensionáveis, como sistema, fornecedor, ODM, OEM, produto, etc. Durante a instalação de um GSI, o espaço é reservado para novas partições de sistema e userdata, retirando blocos não utilizados da partição userdata existente. Como essas novas partições podem ter vários gigabytes de tamanho, o suporte DSU só faz sentido com partições lógicas. partições, caso contrário, um dispositivo precisaria reservar permanentemente vários gigabytes de espaço de armazenamento para GSI instalações.

Outros requisitos incluem um ramdisk, que decide se deseja inicializar na recuperação, no sistema ou em uma partição lógica, e uma partição de metadados para armazenar os metadados do GSI. Em geral, os blocos de construção para suporte DSU são os requisitos de lançamento do Android Q, de acordo com o líder do Projeto Treble, Iliyan Malchev. Não temos certeza se tudo o que é necessário para suportar DSU é um requisito de lançamento do Android Q, mas podemos presumir que a maioria, se não todos, os dispositivos lançados com Android Q pode oferecer suporte ao DSU, mesmo que o Google não exija isso no momento. Até agora, apenas o Pixel 3, Pixel 3 XL, Pixel 3a e Pixel 3a XL têm partições dinâmicas e, desses dispositivos, apenas o Pixel 3 e o Pixel 3 XL suportam DSU no Android Q beta 4. Embora o suporte DSU não seja necessário, o Google espera que os OEMs habilitem o recurso de qualquer maneira, porque isso simplifica o teste seguro de compatibilidade do Treble. Por exemplo, um engenheiro de software OEM pode colocar um GSI em um cartão SD para que eles possam inicializar rapidamente em vários dispositivos para testar a compatibilidade do Treble.

Segurança para atualizações dinâmicas do sistema

Como o DSU introduz essencialmente um segundo sistema operacional no mix, o Google precisa garantir que essa nova instalação não possa ser adulterada para quebrar a integridade do dispositivo. Assim, o as mesmas proteções básicas de segurança da instalação original estão em vigor para a instalação do GSI: Políticas de inicialização verificada do Android e SELinux. Além disso, apenas aplicativos com a assinatura INSTALL_DYNAMIC_SYSTEM | permissão privilegiada podem iniciar um GSI instalação, enquanto aplicativos com a permissão de assinatura MANAGE_DYNAMIC_SYSTEM podem ativar/desativar ou limpar um GSI instalação. Isso significa que apenas aplicativos confiáveis ​​em nível de sistema podem funcionar com DSU.

Para garantir que os dados originais do usuário sejam protegidos, o Google adicionou um mecanismo de proteção extra no Android Q. Chamado "Ponto de verificação," o recurso protege contra a destruição de dados do usuário, restaurando as partições com pontos de verificação ao seu estado original. Os pontos de verificação são úteis não apenas para DSU. Eles também são usados ​​para proteger contra falhas Linha principal do projeto Módulo APEX e A/B Atualizações OTA. (Dispositivos com partições A/B já possuem proteção contra reversão, mas essas reversões exigem redefinições de dados de fábrica, enquanto os pontos de verificação de dados do usuário não.)

Instalando um GSI

Se o seu dispositivo suportar DSU como a série Pixel 3, será fácil instalar um GSI. Primeiro, você precisa se certificar de que o sinalizador do recurso Sistema Dinâmico está habilitado de duas maneiras:

1. Se você estiver em uma compilação userdebug, habilite o sinalizador settings_dynamic_android em Configurações > Sistema > Opções do desenvolvedor > Sinalizadores de recurso.
2. Se você estiver em uma versão de usuário, execute o seguinte comando adb shell:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Em seguida, baixe o GSI beta do Android Q mais recente em Google ou o OEM do seu dispositivo. (A DSU só permite a instalação de GSIs assinados pelo Google ou por um OEM.) Após o download, use simg2img para converter a imagem esparsa em uma imagem bruta. Use gzip para compactar a imagem bruta e, em seguida, copie o arquivo resultante para um local no seu dispositivo armazenamento externo (por exemplo, /data/media/0/Download) ou um meio de armazenamento externo real (como um SD físico cartão). Por último, inicie o aplicativo DynamicSystemInstallationService com a intenção correta para iniciar a instalação:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Depois de clicar em reiniciar, você inicializará no GSI. A usabilidade do dispositivo no GSI depende de quão bem o OEM do seu dispositivo implementou o Treble (ou melhor, quão pouco eles violaram o Treble compatibilidade.) Alguns dispositivos funcionarão melhor com GSIs do que outros, mas em geral, não espere usar esta instalação diariamente motorista. Você deve testar seu aplicativo e depois reinicializá-lo. Se quiser permanecer na instalação do GSI para testes adicionais, você pode usar o gsi_tool comando shell.

As instruções completas de instalação do GSI para DSU podem ser encontradas aqui. Bugs podem ser arquivados no Rastreador de problemas do Google,Reddit, ou Estouro de pilha.

A razão por trás das atualizações dinâmicas do sistema

Quando falei com Iliyan Malchev no Google I/O, ele reiterou o que Hung-ying Tyan, da equipe Treble, disse sobre o acesso antecipado ao GSI em Android Dev Summit de novembro. Google criou DSU para solicitar feedback de um público tão amplo quanto possível. O objetivo é melhorar a qualidade do GSI, que por sua vez melhora a qualidade da futura versão do Android já que um GSI é a forma mais pura de Android. Atualmente, o Google é a única empresa que testa a compatibilidade da próxima versão do GSI (por exemplo, quão bem a imagem do sistema Android Q funciona sobre o Android P implementação do fornecedor), mas à medida que mais pessoas atualizam GSIs e fornecem feedback, os OEMs podem corrigir violações de compatibilidade do Treble para que os GSIs funcionem ainda melhor no futuro. Iliyan diz que há grande interesse de OEMs e fornecedores como a Qualcomm em reutilizar imagens de fornecedores da versão anterior do Android com a imagem do sistema da próxima versão. Iniciativas como a DSU ajudam o Google e os OEMs a preencher a lacuna na cobertura de testes automatizados como VTS e CTS-on-GSI. Assim, o Google consegue mais testadores beta para dar feedback sobre o próximo lançamento do Android, ao mesmo tempo que ouve sobre violações de compatibilidade do Treble para que os OEMs possam melhorar seu trabalho.

A adição de atualizações dinâmicas do sistema no Android Q é bem-vinda, mas não será a solução de inicialização dupla que alguns de vocês esperam. Conforme mencionado anteriormente, apenas imagens de sistema assinadas pelo Google ou OEMs podem ser instaladas. Quando perguntei a Iliyan sobre a possibilidade de estender o DSU para suportar um ecossistema de Android alternativo sistemas, ele disse que é tecnicamente possível fazê-lo, já que o DSU é simplesmente um canal para entregar o sistema imagens. Qualquer OEM pode usá-lo como quiser desde que o resultado final seja compatível com Android. O Google não criou uma alternativa ao sistema OTA aqui, e o DSU não se destina a ser usado para inicialização dupla verdadeira. Independentemente disso, o trabalho que o Google fez no Treble está tornando o Android mais modular, então eu não ficaria surpreso se a inicialização dupla nativa se tornasse realidade no futuro.