Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Atualizações de sistema A / B (contínuas)

As atualizações A / B do sistema, também conhecidas como atualizações contínuas, garantem que um sistema de inicialização viável permaneça no disco durante uma atualização over-the-air (OTA) . Essa abordagem reduz a probabilidade de um dispositivo inativo após uma atualização, o que significa menos substituições e reflashes de dispositivo em centros de reparo e garantia. Outros sistemas operacionais de nível comercial, como o ChromeOS, também usam atualizações A / B com êxito.

Para obter mais informações sobre as atualizações do sistema A / B e como elas funcionam, consulte Seleção de partição (slots) .

As atualizações do sistema A / B oferecem os seguintes benefícios:

  • As atualizações OTA podem ocorrer enquanto o sistema está funcionando, sem interromper o usuário. Os usuários podem continuar a usar seus dispositivos durante uma OTA - o único tempo de inatividade durante uma atualização é quando o dispositivo é reinicializado na partição de disco atualizada.
  • Após uma atualização, a reinicialização não demora mais do que uma reinicialização normal.
  • Se uma OTA não for aplicada (por exemplo, devido a um flash ruim), o usuário não será afetado. O usuário continuará executando o sistema operacional antigo e o cliente estará livre para tentar novamente a atualização.
  • Se uma atualização OTA for aplicada, mas não conseguir inicializar, o dispositivo será reinicializado na partição antiga e permanecerá utilizável. O cliente está livre para tentar novamente a atualização.
  • Quaisquer erros (como erros de E / S) afetam apenas o conjunto de partição não utilizado e podem ser repetidos. Esses erros também se tornam menos prováveis ​​porque a carga de E / S é deliberadamente baixa para evitar degradar a experiência do usuário.
  • As atualizações podem ser transmitidas para dispositivos A / B, eliminando a necessidade de baixar o pacote antes de instalá-lo. Streaming significa que não é necessário que o usuário tenha espaço livre suficiente para armazenar o pacote de atualização em /data ou /cache .
  • A partição de cache não é mais usada para armazenar pacotes de atualização OTA, portanto, não há necessidade de garantir que a partição de cache seja grande o suficiente para atualizações futuras.
  • O dm-verity garante que um dispositivo inicializará uma imagem não corrompida. Se um dispositivo não inicializar devido a um problema de OTA ou dm-verity incorreto, o dispositivo pode reiniciar em uma imagem antiga. (A inicialização verificada do Android não requer atualizações A / B.)

Sobre atualizações do sistema A / B

As atualizações A / B requerem mudanças tanto no cliente quanto no sistema. O servidor de pacotes OTA, entretanto, não deve exigir alterações: os pacotes de atualização ainda são servidos por HTTPS. Para dispositivos que usam a infraestrutura OTA do Google, as alterações do sistema são todas em AOSP e o código do cliente é fornecido pelo Google Play Services. Os OEMs que não usam a infraestrutura OTA do Google poderão reutilizar o código do sistema AOSP, mas precisarão fornecer seu próprio cliente.

Para OEMs que fornecem seu próprio cliente, o cliente precisa:

  • Decida quando fazer uma atualização. Como as atualizações A / B acontecem em segundo plano, elas não são mais iniciadas pelo usuário. Para evitar interromper os usuários, é recomendado que as atualizações sejam agendadas quando o dispositivo estiver no modo de manutenção inativo, como durante a noite e em Wi-Fi. No entanto, seu cliente pode usar qualquer heurística que desejar.
  • Verifique com seus servidores de pacotes OTA e determine se uma atualização está disponível. Deve ser basicamente igual ao código do cliente existente, exceto que você desejará sinalizar que o dispositivo oferece suporte a A / B. (O cliente do Google também inclui um botão Verificar agora para que os usuários verifiquem a atualização mais recente.)
  • Chame update_engine com o URL HTTPS para seu pacote de atualização, supondo que um esteja disponível. update_engine irá atualizar os blocos brutos na partição atualmente não usada conforme ele faz o stream do pacote de atualização.
  • Relate sucessos ou falhas de instalação para seus servidores, com base no código de resultado update_engine . Se a atualização for aplicada com sucesso, update_engine dirá ao bootloader para inicializar no novo sistema operacional na próxima reinicialização. O carregador de inicialização irá retornar para o sistema operacional antigo se o novo sistema operacional falhar ao inicializar, portanto, nenhum trabalho é necessário do cliente. Se a atualização falhar, o cliente precisa decidir quando (e se) deve tentar novamente, com base no código de erro detalhado. Por exemplo, um bom cliente poderia reconhecer que um pacote OTA parcial ("diff") falha e tentar um pacote OTA completo.

Opcionalmente, o cliente pode:

  • Mostra uma notificação solicitando que o usuário reinicie. Se você deseja implementar uma política em que o usuário é encorajado a atualizar rotineiramente, esta notificação pode ser adicionada ao seu cliente. Se o cliente não solicitar aos usuários, eles obterão a atualização na próxima vez que reiniciarem. (O cliente do Google tem um atraso configurável por atualização.)
  • Mostra uma notificação informando aos usuários se eles inicializaram em uma nova versão do sistema operacional ou se eles deveriam fazer isso, mas voltaram para a versão antiga do sistema operacional. (O cliente do Google normalmente não faz isso.)

No lado do sistema, as atualizações do sistema A / B afetam o seguinte:

  • Seleção de partição (slots), o daemon update_engine e interações do carregador de inicialização (descritas abaixo)
  • Processo de construção e geração de pacote de atualização OTA (descrito em Implementando atualizações A / B )

Seleção de partição (slots)

As atualizações do sistema A / B usam dois conjuntos de partições denominados slots (normalmente slot A e slot B). O sistema é executado no slot atual , enquanto as partições no slot não utilizado não são acessadas pelo sistema em execução durante a operação normal. Esta abordagem torna as atualizações resistentes a falhas, mantendo o slot não utilizado como um fallback: Se ocorrer um erro durante ou imediatamente após uma atualização, o sistema pode reverter para o slot antigo e continuar a ter um sistema funcionando. Para atingir esse objetivo, nenhuma partição usada pelo slot atual deve ser atualizada como parte da atualização OTA (incluindo partições para as quais há apenas uma cópia).

Cada slot tem um atributo inicializável que indica se o slot contém um sistema correto a partir do qual o dispositivo pode inicializar. O slot atual é inicializável quando o sistema está em execução, mas o outro slot pode ter uma versão antiga (ainda correta) do sistema, uma versão mais recente ou dados inválidos. Independentemente de qual seja o slot atual , há um slot que é o slot ativo (aquele que o carregador de inicialização irá inicializar na próxima inicialização) ou o slot preferido .

Cada slot também possui um atributo de sucesso definido pelo espaço do usuário, que é relevante apenas se o slot também for inicializável. Um slot bem-sucedido deve ser capaz de inicializar, executar e atualizar-se. Um slot inicializável que não foi marcado como bem sucedido (após várias tentativas foram feitas para inicializar a partir dele) deve ser marcado como não inicializável pelo bootloader, incluindo a mudança do slot ativo para outro slot inicializável (normalmente para o slot em execução imediatamente antes da tentativa de inicialização para o novo e ativo). Os detalhes específicos da interface são definidos em boot_control.h .

Atualizar daemon do motor

As atualizações de sistema A / B usam um daemon de segundo plano chamado update_engine para preparar o sistema para inicializar em uma versão nova e atualizada. Este daemon pode realizar as seguintes ações:

  • Leia a partir das partições A / B do slot atual e grave todos os dados nas partições A / B do slot não utilizadas, conforme instruído pelo pacote OTA.
  • Chame a interface boot_control em um fluxo de trabalho predefinido.
  • Execute um programa de pós-instalação da nova partição depois de gravar todas as partições de slot não utilizadas, conforme instruído pelo pacote OTA. (Para obter detalhes, consulte Pós-instalação ).

Como o daemon update_engine não está envolvido no processo de inicialização em si, ele é limitado no que pode fazer durante uma atualização pelas políticas e recursos do SELinux no slot atual (tais políticas e recursos não podem ser atualizados até que o sistema inicialize em um nova versão). Para manter um sistema robusto, o processo de atualização não deve modificar a tabela de partição, o conteúdo das partições no slot atual ou o conteúdo de partições não A / B que não podem ser apagadas com uma redefinição de fábrica.

Fonte de atualização do motor

A fonte update_engine está localizada em system/update_engine . Os arquivos A / B OTA dexopt são divididos entre installd e um gerenciador de pacotes:

Para obter um exemplo /device/google/marlin/device-common.mk , consulte /device/google/marlin/device-common.mk .

Atualizar registros do motor

Para versões do Android 8.x e anteriores, os logs update_engine podem ser encontrados no logcat e no relatório de bug. Para disponibilizar os logs update_engine no sistema de arquivos, aplique as seguintes alterações em sua compilação:

Essas alterações salvam uma cópia do log update_engine mais recente em /data/misc/update_engine_log/update_engine. YEAR - TIME . Além do registro atual, os cinco registros mais recentes são salvos em /data/misc/update_engine_log/ . Os usuários com o ID do grupo de log poderão acessar os logs do sistema de arquivos.

Interações do bootloader

O boot_control HAL é usado por update_engine (e possivelmente outros daemons) para instruir o bootloader de onde inicializar. Cenários de exemplo comuns e seus estados associados incluem o seguinte:

  • Caso normal : o sistema está funcionando a partir de seu slot atual, slot A ou B. Nenhuma atualização foi aplicada até agora. O slot atual do sistema é inicializável, bem-sucedido e o slot ativo.
  • Atualização em andamento : O sistema está sendo executado a partir do slot B, então o slot B é inicializável, bem-sucedido e ativo. O slot A foi marcado como não inicializável porque o conteúdo do slot A está sendo atualizado, mas ainda não foi concluído. Uma reinicialização neste estado deve continuar inicializando a partir do slot B.
  • Atualização aplicada, reinicialização pendente : O sistema está sendo executado a partir do slot B, o slot B é inicializável e bem-sucedido, mas o slot A foi marcado como ativo (e, portanto, está marcado como inicializável). O slot A ainda não foi marcado como bem-sucedido e algumas tentativas de inicialização a partir do slot A devem ser feitas pelo bootloader.
  • Sistema reinicializado em uma nova atualização : O sistema está executando a partir do slot A pela primeira vez, o slot B ainda é inicializável e bem-sucedido, enquanto o slot A é apenas inicializável e ainda está ativo, mas sem sucesso. Um daemon de espaço do usuário, update_verifier , deve marcar o slot A como bem-sucedido após algumas verificações serem feitas.

Suporte para atualização de streaming

Os dispositivos do usuário nem sempre têm espaço suficiente em /data para baixar o pacote de atualização. Como nem os OEMs nem os usuários desejam perder espaço em uma partição /cache , alguns usuários ficam sem atualizações porque o dispositivo não tem onde armazenar o pacote de atualização. Para resolver esse problema, o Android 8.0 adicionou suporte para streaming de atualizações A / B que gravam blocos diretamente na partição B conforme são baixados, sem a necessidade de armazenar os blocos em /data . As atualizações de streaming A / B quase não precisam de armazenamento temporário e requerem armazenamento apenas o suficiente para cerca de 100 KiB de metadados.

Para habilitar atualizações de streaming no Android 7.1, escolha os seguintes patches:

Esses patches são necessários para oferecer suporte a atualizações A / B de streaming no Android 7.1 e posterior, seja usando o Google Mobile Services (GMS) ou qualquer outro cliente de atualização.

Vida de uma atualização A / B

O processo de atualização começa quando um pacote OTA (referido no código como uma carga útil ) está disponível para download. As políticas no dispositivo podem adiar o download da carga útil e o aplicativo com base no nível da bateria, atividade do usuário, status de carregamento ou outras políticas. Além disso, como a atualização é executada em segundo plano, os usuários podem não saber que uma atualização está em andamento. Tudo isso significa que o processo de atualização pode ser interrompido a qualquer momento devido a políticas, reinicializações inesperadas ou ações do usuário.

Opcionalmente, os metadados no próprio pacote OTA indicam que a atualização pode ser transmitida; o mesmo pacote também pode ser usado para instalação sem streaming. O servidor pode usar os metadados para informar ao cliente que está transmitindo, para que o cliente entregue o OTA para o update_engine corretamente. Os fabricantes de dispositivos com seu próprio servidor e cliente podem habilitar atualizações de streaming garantindo que o servidor identifique que a atualização é streaming (ou assume que todas as atualizações são streaming) e o cliente faz a chamada correta para update_engine para streaming. Os fabricantes podem usar o fato de que o pacote é da variante de streaming para enviar um sinalizador ao cliente para acionar a transferência para o lado da estrutura como streaming.

Depois que uma carga útil está disponível, o processo de atualização é o seguinte:

Degrau Atividades
1 O slot atual (ou "slot de origem") é marcado como bem-sucedido (se ainda não estiver marcado) com markBootSuccessful() .
2 O slot não utilizado (ou "slot de destino") é marcado como não inicializável chamando a função setSlotAsUnbootable() . O slot atual é sempre marcado como bem-sucedido no início da atualização para evitar que o bootloader volte para o slot não utilizado, que logo terá dados inválidos. Se o sistema atingiu o ponto em que pode começar a aplicar uma atualização, o slot atual é marcado como bem-sucedido, mesmo se outros componentes principais estiverem quebrados (como a IU em um loop de falha), pois é possível enviar um novo software para consertá-los problemas.

A carga útil de atualização é um blob opaco com as instruções para atualizar para a nova versão. A carga útil de atualização consiste no seguinte:
  • Metadados . Uma parte relativamente pequena da carga útil de atualização, os metadados contêm uma lista de operações para produzir e verificar a nova versão no slot de destino. Por exemplo, uma operação pode descompactar um determinado blob e gravá-lo em blocos específicos em uma partição de destino ou ler de uma partição de origem, aplicar um patch binário e gravar em certos blocos em uma partição de destino.
  • Dados extras . Como a maior parte da carga útil de atualização, os dados extras associados às operações consistem no blob compactado ou patch binário nesses exemplos.
3 Os metadados da carga útil são baixados.
4 Para cada operação definida nos metadados, em ordem, os dados associados (se houver) são baixados para a memória, a operação é aplicada e a memória associada é descartada.
5 Todas as partições são lidas novamente e verificadas em relação ao hash esperado.
6 A etapa de pós-instalação (se houver) é executada. No caso de um erro durante a execução de qualquer etapa, a atualização falha e é tentada novamente com uma carga útil diferente. Se todas as etapas até agora foram bem-sucedidas, a atualização é bem-sucedida e a última etapa é executada.
7 O slot não utilizado é marcado como ativo chamando setActiveBootSlot() . Marcar o slot não utilizado como ativo não significa que a inicialização será concluída. O bootloader (ou o próprio sistema) pode alternar o slot ativo de volta se ele não ler um estado de sucesso.
8 A pós-instalação (descrita abaixo) envolve a execução de um programa da versão "nova atualização" enquanto ainda é executado na versão anterior. Se definido no pacote OTA, esta etapa é obrigatória e o programa deve retornar com o código de saída 0 ; caso contrário, a atualização falhará.
9 Depois que o sistema inicializa com sucesso o suficiente no novo slot e conclui as verificações pós-reinicialização, o slot atual agora (anteriormente o "slot de destino") é marcado como bem-sucedido chamando markBootSuccessful() .

Pós-instalação

Para cada partição onde uma etapa de pós-instalação é definida, update_engine monta a nova partição em um local específico e executa o programa especificado no OTA em relação à partição montada. Por exemplo, se o programa de pós-instalação for definido como usr/bin/postinstall na partição do sistema, esta partição do slot não utilizado será montada em um local fixo (como /postinstall_mount ) e o /postinstall_mount/usr/bin/postinstall comando /postinstall_mount/usr/bin/postinstall é executado.

Para que a pós-instalação seja bem-sucedida, o kernel antigo deve ser capaz de:

  • Monte o novo formato do sistema de arquivos . O tipo de sistema de arquivos não pode ser alterado a menos que haja suporte para ele no kernel antigo, incluindo detalhes como o algoritmo de compactação usado se estiver usando um sistema de arquivos compactado (ou seja, SquashFS).
  • Compreenda o formato do programa de pós-instalação da nova partição . Se estiver usando um binário Executable and Linkable Format (ELF), ele deve ser compatível com o kernel antigo (por exemplo, um novo programa de 64 bits rodando em um kernel antigo de 32 bits se a arquitetura mudou de compilações de 32 para 64 bits). A menos que o carregador ( ld ) seja instruído a usar outros caminhos ou construir um binário estático, as bibliotecas serão carregadas a partir da imagem do sistema antigo e não da nova.

Por exemplo, você pode usar um script de shell como um programa de pós-instalação interpretado pelo binário de shell do sistema antigo com um #! marcador na parte superior) e, em seguida, configure os caminhos da biblioteca do novo ambiente para executar um programa binário pós-instalação mais complexo. Alternativamente, você pode executar a etapa de pós-instalação a partir de uma partição menor dedicada para permitir que o formato do sistema de arquivos na partição principal do sistema seja atualizado sem incorrer em problemas de compatibilidade com versões anteriores ou atualizações graduais; isso permitiria aos usuários atualizar diretamente para a versão mais recente de uma imagem de fábrica.

O novo programa de pós-instalação é limitado pelas políticas SELinux definidas no sistema antigo. Como tal, a etapa de pós-instalação é adequada para executar tarefas exigidas pelo design em um determinado dispositivo ou outras tarefas de melhor esforço (ou seja, atualizar o firmware ou bootloader com capacidade A / B, preparar cópias de bancos de dados para a nova versão, etc. ) A etapa de pós-instalação não é adequada para correções de bug únicas antes da reinicialização que exigem permissões imprevistas.

Os selecionados dirige o programa Postinstall no postinstall contexto SELinux. Todos os arquivos na nova partição montada serão marcados com postinstall_file , independentemente de quais são seus atributos após a reinicialização nesse novo sistema. Mudanças nos atributos do SELinux no novo sistema não afetarão a etapa de pós-instalação. Se o programa de pós-instalação precisar de permissões extras, elas devem ser adicionadas ao contexto de pós-instalação.

Após reiniciar

Após a reinicialização, update_verifier aciona a verificação de integridade usando dm-verity. Essa verificação começa antes do zigoto para evitar que os serviços Java façam quaisquer alterações irreversíveis que impediriam um rollback seguro. Durante este processo, o bootloader e o kernel também podem disparar uma reinicialização se a inicialização verificada ou o dm-verity detectar qualquer corrupção. Após a conclusão da verificação, update_verifier marca a inicialização com êxito.

update_verifier lerá apenas os blocos listados em /data/ota_package/care_map.txt , que está incluído em um pacote A / B OTA ao usar o código AOSP. O cliente de atualização do sistema Java, como GmsCore, extrai care_map.txt , configura a permissão de acesso antes de reinicializar o dispositivo e exclui o arquivo extraído depois que o sistema inicializa com sucesso na nova versão.