O Android 11 virá com o DSU Loader nas Opções do desenvolvedor que permitirá que você baixe e instale GSIs compatíveis automaticamente! Leia mais!
Um bom ecossistema de aplicativos é um dos pilares mais importantes do sucesso de um sistema operacional. Tanto o Google quanto a Apple reconhecem o valor de ter bons aplicativos em suas plataformas e, portanto, ambas as empresas tentam equilibrar as necessidades de seus usuários e de seus desenvolvedores de aplicativos. Os usuários continuam pressionando por mudanças nos sistemas operacionais e, embora a maioria das pessoas aprecie novos recursos, esses as mudanças nem sempre são divertidas para os desenvolvedores de aplicativos, pois podem alterar muitas das funcionalidades principais e comportamento. Para desenvolvedores que trabalham constantemente para manter seus aplicativos relevantes, lidar com essas mudanças aumenta sua crescente lista de trabalho. Mesmo que essas alterações não afetem diretamente seus aplicativos, os desenvolvedores ainda precisam garantir que seus aplicativos funcionem na nova atualização do sistema operacional. O Google fez muitas mudanças ao longo dos anos para tornar esse processo mais fácil para os desenvolvedores de aplicativos Android e, agora, um novo recurso no Android 11, chamado DSU Loader, tornará ainda mais fácil para os desenvolvedores de aplicativos testarem seus aplicativos no novo Android versões.
Começa com o Projeto Treble
O Projeto Treble, introduzido no Android 8.0, é um grande re-arquitetura do sistema operacional Android. O objetivo do Projeto Treble era dividir o sistema operacional Android em duas grandes partes: a estrutura e a implementação do fornecedor ("fornecedor" aqui refere-se ao fabricante de qualquer componente de hardware proprietário encontrado em um dispositivo, geralmente referindo-se ao silício). A estrutura do sistema operacional Android é o próprio sistema operacional, incluindo todos os aplicativos do sistema, a interface do usuário e seus componentes e as APIs compartilhadas entre os dispositivos Android. A implementação do fornecedor contém as HALs (Hardware Abstraction Layers) do fornecedor, o kernel do Linux e os módulos do kernel do Linux.
Como os OEMs enviam smartphones com muitos componentes de hardware diferentes de muitos fornecedores diferentes, eles precisam fazer muito trabalho apenas para colocar o hardware em funcionamento em uma única versão do sistema operacional Android. Então, com cada nova atualização do sistema operacional Android, eles precisam trabalhar ainda mais para garantir que seu hardware funcione com a nova versão. Mas com o Project Treble padronizando a ABI (Application Binary Interface) entre a estrutura do sistema operacional Android e HALs para uma versão específica do Android, Os OEMs do Android podem começar a testar atualizações para seus dispositivos sem precisar esperar que os fabricantes de silício e outros fabricantes de componentes atualizem seu lado do o código. Essa mudança acelerou visivelmente a maneira como as atualizações do Android são tratadas.
Essa é a essência do que o Project Treble fez para as atualizações do Android, mas o que é mais importante para o aplicativo desenvolvedores aqui é que o Treble habilitou o uso de imagens genéricas do sistema (GSIs) para compatibilidade teste.
O surgimento de GSIs
Para que os OEMs testem se implementaram corretamente o Project Treble, o Google exige que o OEM seja capaz de inicializar uma compilação limpa do Android a partir do AOSP no dispositivo. Essa compilação limpa do Android é chamada de Generic System Image ou GSI. Se o GSI inicializar e o hardware mais básico funcionar corretamente, o OEM saberá que seu dispositivo atende aos requisitos do Project Treble. O objetivo inicial dos GSIs era testar a compatibilidade do Treble, mas como vimos com a comunidade de desenvolvimento aqui no XDA-Developers, eles podem ser usados para outros fins. Vimos como os GSIs pode essencialmente permitir que dispositivos com Android UXs pesados aproveitem a versão mais recente do Android com recursos funcionais poucos dias após um novo lançamento. Mas o Google vislumbra outro propósito por trás do GSI: dar aos desenvolvedores de aplicativos a capacidade de testar seus aplicativos em uma nova versão do Android em um dispositivo físico que eles já possuam.
Com o Android 10, o Google lançou suas próprias compilações GSI para desenvolvedores. O Google consolidou a ideia de que os desenvolvedores de aplicativos devem usar um GSI para inicializar uma compilação limpa do Android em seu próprio hardware, tornando mais fácil testar o comportamento de seu aplicativo em relação ao Android padrão. Este método, portanto, adicionado às opções existentes de testar a compatibilidade do aplicativo no Android padrão sem alterações de comportamento do OEM, sendo os outros usando um smartphone Pixel, usando o Android Emulator oficial no Android Studio ou implementando compilações de aplicativos em uma instância de dispositivo na nuvem.
Apesar de toda a conveniência que os GSIs trouxeram, sua instalação ainda era um processo complicado. Os desenvolvedores de aplicativos podem não se sentir confortáveis com a atualização manual de uma imagem do sistema em um dispositivo Android, pois isso é algo com o qual apenas amadores ou desenvolvedores de sistema operacional Android estarão familiarizados. A instalação de um GSI exigia o flash de uma imagem do sistema em fastboot, o que requer a desativação do Android Verified Boot e o desbloqueio do bootloader. O desbloqueio do bootloader, por sua vez, requer uma limpeza completa dos dados do usuário. E como todos sabemos, não há exatamente um único processo ou guia para desbloquear o bootloader de todos os dispositivos Android existentes, portanto, não há consistência a ser encontrada. Por exemplo, os dispositivos Samsung não têm inicialização rápida, enquanto os dispositivos Xiaomi fazem você pular alguns obstáculos para desbloquear o bootloader. É uma bagunça conveniente que tem o potencial de ser desembaraçada em algo mais simples.
É aqui que entram as Atualizações Dinâmicas do Sistema.
Atualizações dinâmicas do sistema simplesmente instalando GSIs
O Google percebeu que o método atual de instalação de GSIs não era uma solução perfeita, então eles começaram a trabalhar em uma solução melhor. No Android 10, Google começou a testar atualizações dinâmicas do sistema, ou DSU. O DSU é uma nova maneira de instalar temporariamente um GSI sem a necessidade de usar comandos fastboot para atualizar uma imagem do sistema, substituindo a instalação original. Com o DSU, você pode inicializar em um GSI, testar seu aplicativo e, em seguida, reiniciar convenientemente em sua instalação original que permaneceu intocada.
A razão pela qual o DSU pode instalar um GSI sem tocar na instalação original é que ele cria novas imagens de sistema e partição de dados que são temporariamente armazenadas em /data/gsi. Essas imagens são montadas durante a inicialização, em vez do sistema original e das partições de dados. Como o telefone precisa de espaço de armazenamento adicional para essas novas imagens temporárias, seu telefone deve ter "partições lógicas" a bordo, que são partições redimensionáveis dinamicamente. As partições lógicas são um novo sistema de particionamento de espaço de usuário para Android, obrigatório para dispositivos iniciados com o Android 10. Se o seu dispositivo foi iniciado com o Android 10, ele deve oferecer suporte à instalação de GSIs por meio do DSU.
No Android 10, tudo o que você precisa fazer para instalar um GSI via DSU é alterar uma propriedade do sistema e, em seguida, iniciar o DynamicSystemUpdatesInstallationService enviando uma intenção com o caminho para o GSI como uma intenção extra.
Embora esse processo possa parecer estranho, é muito mais fácil e menos intrusivo quando comparado ao uso de comandos fastboot e lidar com o incômodo de tudo, incluindo a instalação original, sendo limpo. Você precisa de algum conhecimento de ADB e intenções para usar o DSU, mas isso não deve ser um problema para a maioria dos desenvolvedores de aplicativos. Ainda assim, não há razão para que o processo não seja ainda mais simples. Além disso, existe o fato de que a instalação de um GSI por meio do DSU ainda exige que você desbloqueie o bootloader, limpando todos os dados do usuário no processo. Para esse fim, o Google implementou alterações para melhorar os dois aspectos da instalação do GSI. No Android 11, eles eliminaram a necessidade de usar a linha de comando para instalar um GSI. Separadamente, eles também possibilitaram a instalação de um GSI sem desbloquear o bootloader.
Carregador DSU no Android 11
O DSU Loader é uma nova ferramenta presente nas Opções do desenvolvedor do Android 11 que permite download e instalar o GSI mais recente do Google sem a necessidade de inserir nenhum comando fastboot ou ADB. Basta tocar na opção DSU Loader em Configurações e uma caixa de diálogo aparecerá com uma lista de GSIs suportados diretamente do Google. Esses GSIs suportados serão baseados em seu sistema operacional e arquitetura atuais, portanto, você só pode instalar GSIs mais recentes que a versão do seu sistema operacional e que correspondam à sua arquitetura SoC. Basta escolher o GSI que deseja instalar e ele será baixado dos servidores do Google e instalado em segundo plano automaticamente.
Com o DSU Loader, os desenvolvedores nunca precisam tocar na linha de comando para instalar um GSI. Pelo menos, esse é o sonho, porque ainda há um problema a ser resolvido.
O caminho a seguir
Atualmente, para instalar um GSI via DSU Loader, você precisa de um bootloader desbloqueado. Embora isso possa anular o propósito de todo o calvário, não é para ser assim, e nos dizem que será consertado. O Google planejou que os usuários possam inicializar GSIs assinados pelo Google por meio do DSU sem a necessidade de desbloquear o gerenciador de inicialização. Na verdade, o Google exige que todos os dispositivos de inicialização do Android 10 incluem as chaves públicas Android Verified Boot de Android 10, Android 11 e Android 12 GSIs assinados pelo Google. Incluir as chaves públicas do AVB no ramdisk do dispositivo garantirá que o AVB não rejeitará o GSI que você está tentando inicializar. É por isso que o método atual envolve desbloquear o bootloader - ao atualizar uma imagem vbmeta vazia para a partição vbmeta, você desativa o AVB para que ele não rejeite o GSI que você está prestes a atualizar. Desativar o AVB é um grande risco de segurança, pois significa que qualquer modificação partição system/boot/product/vendor pode ser carregada no dispositivo, e é por isso que o Google quer fazer acabar com essa exigência.
Então, quando você pode esperar inicializar um GSI por meio do DSU sem precisar desbloquear o gerenciador de inicialização ou usar qualquer ferramenta de linha de comando? Esperamos que em breve, como o Google mencionou para nós, eles tinham alguns problemas para resolver com as visualizações iniciais do desenvolvedor do Android 11 antes que pudessem fazer tudo funcionar corretamente. Seguindo em frente, pode-se esperar instalar futuros GSIs do Developer Preview via DSU sem a necessidade de desbloquear o bootloader. Talvez quando as visualizações do desenvolvedor do Android 12 forem disponibilizadas, você poderá inicializá-lo totalmente usando o DSU Loader nas opções do desenvolvedor do Android 11. Para desenvolvedores de aplicativos, isso significa que haverá outra maneira de testar seus aplicativos em hardware físico executando uma nova versão do Android.