Como as partições A/B e as atualizações contínuas afetam o desenvolvimento personalizado no XDA

click fraud protection

Você já deve ter ouvido falar de atualizações contínuas antes. Envolve algo chamado “partições A/B”. O que é e como afeta o desenvolvimento personalizado no XDA?

Quando o Android Nougat foi lançado, nos fez falar sobre todos os tipos de novos recursos. Temos uma interface de usuário recém-atualizada para iniciantes, juntamente com os tão esperados recursos de múltiplas janelas e suporte à API Vulkan Graphics. Mas uma adição oculta passou pela cabeça da maioria dos usuários. O Android Nougat introduziu "atualizações contínuas" em dispositivos que suportam partições A/B. A grande maioria dos dispositivos Android existentes (excluindo o novo Google Pixel e Google Pixel XL) não tinham partições A/B na época e, portanto, não podiam aproveitar as vantagens de atualizações contínuas. A premissa básica desse recurso é que o dispositivo tenha um segundo conjunto de sistema, inicialização, fornecedor e outras partições importantes, e quando você obtém um OTA update, a atualização acontece em segundo plano enquanto o segundo conjunto de partições é corrigido, o que permite reinicializar em uma versão de software atualizada sem problemas. Se uma atualização falhar, você retornará a uma versão funcional, o que significa que as empresas terão menos dores de cabeça e os consumidores estarão mais protegidos.

O suporte a atualizações contínuas não é um requisito para nenhum novo dispositivo Android, ao contrário do Project Treble. Como tal, a grande maioria dos novos dispositivos Android não suporta o recurso. Mantemos uma lista de todos os dispositivos suportados até agora, e está claro que esse recurso não é amplamente suportado. Isso é uma pena porque as partições A/B trazem muitos benefícios tanto para usuários regulares quanto para usuários avançados. No entanto, o recurso tem uma má reputação na comunidade de entusiastas porque parece dificultar o desenvolvimento do Android e a atualização de modificações personalizadas. Na verdade, esse não é o caso, então queríamos desmistificar as atualizações contínuas e explicar como as partições A/B afetam o desenvolvimento personalizado no XDA.

Muito obrigado ao membro sênior do XDA npjohnson, a contribuidor á LineageOS e mantenedor do Motorola Moto Z2 Force, que nos ajudou a verificar este artigo.


Partições em um dispositivo Android

Uma partição é simplesmente uma seção discreta no armazenamento interno do telefone onde os dados são mantidos. O tipo de dados mantidos em cada partição depende do hardware, do sistema operacional e de muitos outros fatores. O bootloader terá um, o sistema (sistema operacional Android) terá um, os dados do usuário terão um... e assim por diante. Quando você vê pessoas falando sobre "/system" e "/cache", elas estão se referindo aos nomes dessas partições. O OnePlus 6, por exemplo, tem 72 partições. Parece muito, mas o OnePlus 6 é um dos dispositivos que suporta atualizações contínuas, o que significa que muitas dessas partições são simplesmente duplicatas umas das outras.

Saída parcial das partições no OnePlus 6. Algumas partições A/B estão sublinhadas para fins de demonstração.

Existem muitas partições em um dispositivo com as quais você nunca precisará se preocupar como usuário. Muitas dessas partições nunca são modificadas ao atualizar ROMs, kernels, recuperações ou modificações personalizadas como Magisk ou Xposed. Muitas dessas partições não serão utilizadas para nossos propósitos ou serão muito perigosas para serem tocadas, a menos que você saiba o que está fazendo (XLOADER e OEMINFO no Huawei/Honor dispositivos vêm à mente.) Para a grande maioria dos usuários do Android, as partições com as quais lidamos principalmente são sistema, inicialização, recuperação, dados do usuário e, mais recentemente, fornecedor e vbmeta. Aqui está uma breve explicação da finalidade de cada partição:

  • sistema - contém o sistema operacional Android, bibliotecas do sistema, aplicativos do sistema e outras mídias do sistema, como animações de inicialização, papéis de parede de ações, toques, etc.
  • boot - contém o kernel, ramdisk e em dispositivos A/B também a recuperação
  • recuperação - mantém a recuperação, onde o TWRP é mais comumente atualizado em dispositivos somente A (dispositivos A/B não têm uma partição de recuperação dedicada)
  • userdata - contém todos os dados do seu aplicativo, sistema e armazenamento interno
  • fornecedor - contém HALs específicos da plataforma e do dispositivo, os arquivos necessários para o sistema operacional Android se comunicar com o hardware subjacente
  • vbmeta - a partição para Android Verified Boot 2.0 que verifica a integridade do processo de inicialização

Os OEMs de dispositivos podem alterar seus esquemas de partição para usar o layout que desejarem. Por exemplo, a Huawei divide a partição de inicialização em ramdisk_recovery e kernel. Existem também muitas partições extras que podem conter outros aplicativos do sistema, como cust, product e oem, e enquanto estes são seguros para modificar, geralmente não é recomendado se você quiser facilitar o retorno ao estoque. Então, onde as partições A/B desempenham um papel?


O esquema de partição A/B

Como as atualizações funcionam em dispositivos com atualizações contínuas

A imagem muito simples que fiz abaixo ilustra como uma atualização é tratada em um dispositivo com suporte a partição A/B. A partição ilustrada é a partição do sistema, embora outras partições, como boot e vendor, também possam ser atualizadas com qualquer atualização OTA de um OEM. Este processo de atualização ocorre não apenas com as principais atualizações de versão do Android, mas também com atualizações de patches de segurança.

  1. Começamos com duas partições de sistema, system_a e system_b, ambas na mesma versão do Android.
  2. Supondo que system_a esteja ativo, a atualização OTA corrigirá system_b, a partição inativa, em segundo plano.
  3. system_a é definido como inativo e system_b torna-se ativo quando o usuário é reinicializado.
  4. A partição agora inativa, system_a, será atualizada quando a próxima atualização OTA for lançada.

Quais são os benefícios deste processo de atualização?

  1. Se uma atualização falhar, o dispositivo retornará à versão funcional no outro slot.
  2. Seus dados são mantidos perfeitamente intactos, mesmo que a atualização seja interrompida, pois há apenas uma partição (userdata) que abriga seus dados.
  3. Streaming de atualização: se sua partição de dados estiver cheia, a atualização poderá ser baixada e transmitida para o slot inativo. É um recurso muito interessante e significa que você não precisa desperdiçar nenhum armazenamento temporário com suas atualizações. É por isso que não há partição de cache em dispositivos A/B, pois eles não são mais necessários.

Qual o impacto do esquema de particionamento A/B no armazenamento de um dispositivo?

O fato de atualizações contínuas resultarem em muitas partições duplicadas significa que você está perdendo muito espaço de armazenamento? De jeito nenhum. O Google diz que os dispositivos com suporte contínuo para atualização devem cair apenas algumas centenas de megabytes graças à remoção das partições /cache e /recovery. A remoção de ambos equilibra o custo de adição de um segundo conjunto de partições. De acordo com o Google, a imagem do sistema A/B do Pixel tem metade do tamanho da imagem do sistema somente A. A maior parte do uso adicional de armazenamento vem, na verdade, da adição de uma partição de segundo fornecedor. Isso faz sentido, já que a partição do fornecedor abriga todos os binários proprietários usados ​​pelos OEMs (parte do Projeto Treble), por isso espera-se que ocupe bastante espaço. Embora o Google não recomende particionamento A/B em dispositivos com 4 GB de armazenamento (já que representa quase 10% do armazenamento total disponível), eles o recomendam em dispositivos com 8 GB e superiores.

Aqui está um detalhamento do espaço de armazenamento usado em um Google Pixel com e sem partições A/B.

Tamanhos de partição

A/B

Somente A

Carregador de inicialização

50MB*2

50 MB

Bota

32MB*2

32 MB

Recuperação

32 MB

Cache

100 MB

Rádio

70MB*2

70 MB

Fornecedor

300MB*2

300MB

Sistema

2.048 MB*2

4.096 MB

Total

5.000 MB

4680 MB

O que aconteceu com a partição de recuperação?

O kernel Linux subjacente em dispositivos Android é o que permite ao Android reconhecer e usar o hardware corretamente em um smartphone. Em dispositivos Android somente A, você geralmente tem duas versões do kernel: uma está compactada dentro da partição de recuperação, enquanto a outra está na partição de inicialização. Em dispositivos A/B que suportam atualizações contínuas, a recuperação agora está dentro da imagem de inicialização junto com o kernel. A principal função da recuperação era instalar atualizações, mas como isso é feito pelo próprio sistema (update_engine) enquanto o Android é inicializado, a partição de recuperação dedicada não é mais necessária.

Para instalar uma recuperação personalizada em dispositivos A/B, precisamos modificar a partição de inicialização e substituir a recuperação de estoque pela nossa própria. É por isso que para instalar o TWRP você precisa primeiro usar um comando fastboot para inicializar uma imagem de inicialização personalizada e então atualize o script de instalação do TWRP, pois o fastboot não pode corrigir partições - apenas atualize-as completamente. Você poderia tecnicamente pré-corrigir sua imagem de inicialização existente com TWRP e depois atualizá-la via fastboot, mas isso é mais problemático do que vale a pena. O script do instalador do TWRP corrige as partições boot_a e boot_b para instalar o TWRP.

Curiosidade: o update_engine do Android, que lida com atualizações contínuas, é basicamente extraído diretamente do Chrome OS. Apenas recentemente foram strings contendo "Chrome OS" removidas do log do update_engine para evitar confusão para quem verifica o logcat.

Meu smartphone Android suporta partições A/B para atualizações contínuas?

Enquanto nós mantenha uma lista de todos os dispositivos que o apoiam, você também pode verificar facilmente por si mesmo.


Como as atualizações contínuas afetam o desenvolvimento personalizado?

Percepção do usuário sobre partições A/B

Consideradas um obstáculo ao desenvolvimento de software personalizado por muitos usuários, as atualizações contínuas são, na verdade, uma vantagem para os desenvolvedores. A razão pela qual os dispositivos A/B são percebidos como tendo suporte de desenvolvimento deficiente se resume ao preço dos primeiros dispositivos A/B. Afinal, os dispositivos Google Pixel foram alguns dos primeiros a suportar atualizações contínuas e, em comparação com os smartphones Nexus do passado, eram relativamente caros. Além disso, graças à miríade de melhorias que o Google vem fazendo no sistema operacional Android, que criou ROMs personalizados e modificações menos populares em dispositivos Google, os smartphones Google Pixel não decolaram em nossos fóruns tão bem quanto o Nexus smartphones. Uma combinação de fatores externos levou a uma diminuição no desenvolvimento personalizado nos smartphones Google Pixel, embora a maioria dos usuários tenha optado por culpar o suporte à partição A/B. Compare a disponibilidade de desenvolvimento personalizado em dispositivos como o Google Pixel com dispositivos como o Xiaomi Mi A1 em nossos fóruns.

Além disso, a falta de compreensão de como as partições A/B mudaram a maneira como os usuários precisam instalar ROMs, kernels, recuperações e modificações personalizadas fez com que o suporte à partição A/B se tornasse impopular. Com a recuperação agora dentro da imagem de inicialização, atualizar modificações na ordem errada, como Magisk ou Xposed, pode causar conflitos e levar a um bootloop. A ordem em que você atualiza esses mods pode ser importante, embora no caso de ROMs personalizados você não precise se preocupar com o slot em que está atualizando. Ao contrário da crença comum, o script de instalação da maioria das ROMs personalizadas não pisca em ambos os slots. Na maioria das vezes, você não precisa se preocupar com isso, pois não precisa trocar de slot manualmente.

Como os desenvolvedores veem as partições A/B

Ao construir uma ROM, os desenvolvedores podem usar ambas as partições para testar compilações separadas. Se um deles não funcionar, eles podem simplesmente voltar para a partição funcional e reconstruir sua ROM. Os desenvolvedores também podem testar regressões simplesmente instalando uma atualização, trocando a partição ativa e comparando as duas sem precisar limpar os dados. Veja como a equipe do LineageOS vê o suporte à partição A/B:

"Muitos na comunidade Android criticaram o A/B como sendo 'difícil de suportar' e 'não amigável ao desenvolvedor', quando na verdade, implementado corretamente, é mais fácil de apoiar e igualmente amigável ao desenvolvedor." - jrizzoli, Log de alterações do LineageOS 19

A dificuldade inicial com o suporte A/B para desenvolvedores veio da modificação de suas ferramentas existentes para oferecer suporte a esses dispositivos. O desenvolvedor do Magisk, topjohnwu, adicionou suporte oficial para o Google Pixel um ano depois de ter sido lançado - não porque fosse difícil, mas porque levou um ano para ele realmente obter o dispositivo para trabalho em. Suporte TWRP veio bem rápido em dispositivos A/B depois que o desenvolvedor líder, Dees_Troy, deu uma olhada nisso. Lineage OS 15.1 agora suporta Dispositivos A/B depois que os voluntários encontraram tempo para corrigir seu script addon.d.

Como atualizar um dispositivo A/B que possui recuperação personalizada, kernel ou outros mods

ROMs personalizadas

Atualizar atualizações em um dispositivo com uma ROM personalizada significa que você também terá que ter cuidado com qual slot está atualizando, certo? Não exatamente. Na verdade, o TWRP cuidará de muito disso para você e o padrão é o slot inativo para atualizar uma ROM personalizada. Se o seu slot ativo for A e você atualizar uma ROM personalizada, na verdade você estará atualizando para o slot B. Quando você reinicia, o slot ativo agora é B. Os desenvolvedores podem modificar o script de instalação e atualizar para ambos os slots para facilitar para o usuário final, embora a maioria dos scripts de instalação de ROM personalizados atualmente atualizem apenas para um único slot. Por último, ROMs personalizadas podem implementar um atualizador A/B em sua ROM para que os usuários nem precisem mexer atualizando manualmente – o LineageOS 15.1 mais recente inclui uma ferramenta Lineage Updater e XDA Senior Member EUA-RedDragon fez um atualizador A/B genérico que outros desenvolvedores podem usar.

ROMs de estoque

Mas não é problemático se o seu dispositivo estiver executando a ROM padrão com várias modificações e você quiser instalar uma atualização sem perder todos esses mods? Pode ser que você não saiba as etapas corretas para instalar uma atualização. No OnePlus 6, por exemplo, você não pode atualizar um OTA incremental em seu dispositivo modificado porque o OTA incremental tentará corrigir sua imagem de inicialização modificada. Portanto, você provavelmente acabará com um bootloop e é por isso que precisará atualizar a atualização completa da ROM para substituir completamente sua imagem de inicialização modificada. Aqui estão as etapas gerais que você precisa seguir para instalar uma atualização do OxygenOS em seu OnePlus 6, mantendo TWRP, Magisk e, opcionalmente, um kernel personalizado.

  1. Baixei o mais recente ROM completa fecho eclair
  2. Atualize o zip completo da ROM na recuperação
  3. (Opcional) Kernel personalizado do Flash
  4. Instalador Flash TWRP
  5. Reinicie direto para recuperação
  6. Magisk Flash

Nos dispositivos Google Pixel, você pode atualize a imagem de fábrica sem limpar os dados, inicialize o TWRP, instale o TWRP por meio do script de instalação e instale o Magisk.

Extraindo uma atualização para atualizar imagens de partições individuais

Os arquivos de atualização para muitos dispositivos A/B são um pouco diferentes em comparação com dispositivos somente A. Eles não são mais apenas um arquivo zip contendo muitas imagens (excluindo as imagens de fábrica do Google e da Razer); em vez disso, estão na forma de um arquivo payload.bin. Você pode extrair esse arquivo e atualizar cada parte manualmente, mas isso requer uma ferramenta especial para fazer isso. Se você estiver interessado em aprender como fazer isso no OnePlus 6, Xiaomi Mi A1 e muitos outros dispositivos A/B, continue lendo.

Configurando para extrair payload.bin

  1. Certifique-se de ter o Python 3.6 instalado.
  2. Baixe payload_dumper.py e update_metadata_pb2.py aqui.
  3. Extraia seu zip OTA e coloque payload.bin na mesma pasta desses arquivos.
  4. Abra o PowerShell, prompt de comando ou Terminal dependendo do seu sistema operacional.
  5. Digite o seguinte comando: python -m pip install protobuf
  6. Quando terminar, digite este comando: python payload_dumper.py payload.bin
  7. Isso começará a extrair as imagens do arquivo payload.bin para a pasta atual em que você está.

Você pode atualizar cada uma dessas imagens separadamente agora via fastboot, se desejar. A próxima seção mostra como fazer isso.

Usando fastboot para fazer flash de imagens em um dispositivo que suporta atualizações contínuas

Existem vários comandos exclusivos para dispositivos do sistema de partição A/B. Você pode alterar seu slot ativo e atualizar para slots específicos. Se você tem um Projeto Treble-dispositivo compatível e quer aprender como Imagens genéricas do sistema flash, você deve estar familiarizado com esses comandos. Dê uma olhada na tabela abaixo.

Comandos de inicialização rápida

Comando

Obtenha o slot ativo atual

fastboot getvar tudo | grep "current-slot"Se você estiver em um PC com Windows, o comando "grep" não funcionará.

Definir outro slot como ativo

fastboot set_active outro

Definir o slot especificado como ativo

fastboot set_active $OUfastboot --set-active=_$slotonde $ é a ou b

Imagem Flash para a partição especificada no slot atual

partição flash fastboot partição.img

Imagem Flash para a partição especificada no slot especificado

partição flash fastboot_a partição.img partição flash fastboot_b partição.img

(Observação: em dispositivos A/B, você pode especificar uma partição em um slot específico para fazer o flash ou pode omitir o sufixo do slot e ele piscará no slot ativo atual. Por exemplo, você pode substituir “partição” no comando flash por “sistema”, “sistema_a” ou “sistema_b”.)

Em PCs com Windows, você não pode usar o grep, então remova essa parte e procure por "slot atual".

Uma palavra sobre o projeto Treble e atualizações contínuas

Um equívoco comum é que o suporte ao Project Treble e o suporte à partição A/B estão relacionados entre si, mas esse não é realmente o caso. Ter um não implica o outro. O Motorola Moto Z2 Force usa um esquema de particionamento A/B, mas não oferece suporte a Treble. Por outro lado, o Honor 9 Lite suporta o Project Treble, mas é um dispositivo apenas A.

O Honor 9 Lite suporta Project Treble, mas não suporta atualizações contínuas

Perguntas frequentes/resumo

  • Quais são os benefícios do particionamento A/B?
    • O particionamento A/B permite que você atualize seu smartphone Android enquanto o usa, simplesmente reiniciando quando estiver pronto para inicializar a nova versão. Ele também atua como proteção contra tijolos – se a atualização der errado, você voltará à instalação funcional.
  • Ter particionamento A/B atrapalha o desenvolvimento?
    • Embora os desenvolvedores tenham demorado um pouco para se adaptar, a resposta é praticamente não. Na verdade, isso pode ajudar os desenvolvedores, pois eles podem inicializar sua ROM personalizada com a versão antiga e uma nova versão de teste para verificar regressões.
  • Como as partições A/B afetam mods como kernels personalizados, Magisk ou Xposed?
    • Você deve ter cuidado ao instalá-los, mas atualmente não há problemas. Magisk suporta oficialmente dispositivos com atualizações contínuas e, desde que você atualize as coisas na ordem certa, não deverá ter problemas. Certifique-se de atualizar o kernel personalizado antes de atualizar seus outros mods, e você estará pronto para prosseguir.
  • Posso atualizar duas ROMs diferentes em cada partição e inicialização dupla?
    • Em teoria, sim. Porém, surgem problemas por causa da partição de dados compartilhada, portanto, não é recomendado.
  • Ter um esquema de partição A/B significa que reduzi o armazenamento?
    • Não! O Google diz que os dispositivos que suportam atualizações contínuas sacrificam apenas algumas centenas de megabytes de armazenamento para suportá-las. Os benefícios superam esse custo.
  • Meu dispositivo suporta partições A/B, isso significa que posso usar uma imagem genérica do sistema do Project Treble?
    • Não necessariamente. O projeto Treble e o suporte A/B não estão relacionados. O Motorola Moto Z2 Force não suporta Project Treble, mas suporta o esquema de partição A/B.
  • Meu dispositivo suporta o Project Treble. Isso significa que tenho um esquema de partição A/B?
    • Isso não é sempre o caso. O Honor 9 Lite é um excelente exemplo, pois suporta o Project Treble, mas não possui um esquema de partição A/B.
  • Por que preciso inicializar o TWRP com fastboot primeiro e depois atualizá-lo?
    • Isso se deve ao funcionamento do fastboot e ao fato de a partição de recuperação não existir mais. A recuperação é colocada dentro da partição de inicialização, então temos que modificar boot_a e boot_b. Você não pode corrigir uma partição no fastboot, apenas atualizá-la. Você poderia, em teoria, criar uma imagem de inicialização pré-atualizada e, em seguida, atualizá-la.
  • Há algum perigo com partições A/B? Como a proteção contra reversão afeta as coisas?
    • O Google fez o possível para que isso não fosse um problema, mas no caso do Motorola Moto Z2 Força, houve casos conhecidos de um dispositivo reativando o slot antigo após a atualização para Android Oreo. Isso significava que a proteção contra reversão entrou em ação e os proprietários de dispositivos só poderiam resgatar seus smartphones com recuperação EDL. O Google diz que a proteção contra reversão só entra em ação após a primeira inicialização, portanto, o slot precisa estar totalmente funcionando após uma atualização antes que você não possa mais fazer o downgrade.