Google 致力于为黑人社区推动种族平等。查看具体举措
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Atualizações de sistema não A / B

Em dispositivos Android mais antigos sem partições A / B, o espaço flash normalmente contém as seguintes partições:

bota
Contém o kernel Linux e um sistema de arquivos raiz mínimo (carregado em um disco RAM). Ele monta o sistema e outras partições e inicia o tempo de execução localizado na partição do sistema.
sistema
Contém aplicativos e bibliotecas do sistema que possuem código-fonte disponível no Android Open Source Project (AOSP). Durante a operação normal, esta partição é montada como somente leitura; seu conteúdo muda apenas durante uma atualização OTA.
fornecedor
Contém aplicativos e bibliotecas do sistema que não têm código-fonte disponível no Android Open Source Project (AOSP). Durante a operação normal, esta partição é montada como somente leitura; seu conteúdo muda apenas durante uma atualização OTA.
dados do usuário
Armazena os dados salvos por aplicativos instalados pelo usuário, etc. Esta partição normalmente não é afetada pelo processo de atualização OTA.
esconderijo
Área de retenção temporária usada por alguns aplicativos (acessar esta partição requer permissões de aplicativos especiais) e para armazenamento de pacotes de atualização OTA baixados. Outros programas usam esse espaço com a expectativa de que os arquivos possam desaparecer a qualquer momento. Algumas instalações de pacotes OTA podem resultar na limpeza completa desta partição. O cache também contém os logs de atualização de uma atualização OTA.
recuperação
Contém um segundo sistema Linux completo, incluindo um kernel e o binário de recuperação especial que lê um pacote e usa seu conteúdo para atualizar as outras partições.
misc
Partição minúscula usada pela recuperação para esconder algumas informações sobre o que está fazendo no caso de o dispositivo ser reiniciado enquanto o pacote OTA está sendo aplicado.

Vida de uma atualização OTA

Uma atualização OTA típica contém as seguintes etapas:

  1. O dispositivo realiza verificação regular com servidores OTA e é notificado sobre a disponibilidade de uma atualização, incluindo a URL do pacote de atualização e uma string de descrição para mostrar ao usuário.
  2. Atualize os downloads para um cache ou partição de dados, e sua assinatura criptográfica é verificada em relação aos certificados em /system/etc/security/otacerts.zip . O usuário é solicitado a instalar a atualização.
  3. O dispositivo é reinicializado no modo de recuperação, no qual o kernel e o sistema na partição de recuperação são inicializados em vez do kernel na partição de inicialização.
  4. O binário de recuperação é iniciado por init. Ele encontra argumentos de linha de comando em /cache/recovery/command que apontam para o pacote baixado.
  5. A recuperação verifica a assinatura criptográfica do pacote em relação às chaves públicas em /res/keys (parte do disco RAM contido na partição de recuperação).
  6. Os dados são retirados do pacote e usados ​​para atualizar as partições de inicialização, sistema e / ou fornecedor conforme necessário. Um dos novos arquivos deixados na partição do sistema contém o conteúdo da nova partição de recuperação.
  7. O dispositivo é reinicializado normalmente.
    1. A partição de inicialização recém-atualizada é carregada e montada e começa a executar binários na partição do sistema recém-atualizada.
    2. Como parte da inicialização normal, o sistema verifica o conteúdo da partição de recuperação em relação ao conteúdo desejado (que foi armazenado anteriormente como um arquivo em /system ). Eles são diferentes, portanto, a partição de recuperação é atualizada com o conteúdo desejado. (Em inicializações subsequentes, a partição de recuperação já contém o novo conteúdo, portanto, nenhum reflash é necessário.)

A atualização do sistema está concluída! Os logs de atualização podem ser encontrados em /cache/recovery/last_log. #

Pacotes de atualização

Um pacote de atualização é um arquivo .zip que contém o binário executável META-INF/com/google/android/update-binary . Depois de verificar a assinatura no pacote, a recovery extrai esse binário para /tmp e executa o binário, passando os seguintes argumentos:

  • Atualize o número da versão binária da API . Se os argumentos passados ​​para o binário de atualização mudarem, esse número será incrementado.
  • Descritor de arquivo do canal de comando . O programa de atualização pode usar esse canal para enviar comandos de volta ao binário de recuperação, principalmente para alterações da IU, como indicar o progresso para o usuário.
  • Nome de arquivo do arquivo .zip pacote de atualização .

Um pacote de atualização pode usar qualquer binário vinculado estaticamente como binário de atualização. As ferramentas de construção de pacote OTA usam o programa atualizador ( bootable/recovery/updater ), que fornece uma linguagem de script simples que pode realizar muitas tarefas de instalação. Você pode substituir qualquer outro binário em execução no dispositivo.

Para obter detalhes sobre o binário do atualizador, a sintaxe do edify e as funções internas, consulte Por dentro dos pacotes OTA .

Migrando de versões anteriores

Ao migrar da versão Android 2.3 / 3.0 / 4.0, a principal mudança é a conversão de todas as funcionalidades específicas do dispositivo de um conjunto de funções C com nomes predefinidos para objetos C ++. A tabela a seguir lista as funções antigas e os novos métodos que têm uma finalidade aproximadamente equivalente:

Função C Método C ++
device_recovery_start () Device :: RecoveryStart ()
device_toggle_display ()
device_reboot_now ()
RecoveryUI :: CheckKey ()
(também RecoveryUI :: IsKeyPressed ())
device_handle_key () Device :: HandleMenuKey ()
device_perform_action () Device :: InvokeMenuItem ()
device_wipe_data () Device :: WipeData ()
device_ui_init () ScreenRecoveryUI :: Init ()

A conversão de funções antigas em novos métodos deve ser razoavelmente direta. Não se esqueça de adicionar a nova função make_device() para criar e retornar uma instância de sua nova subclasse Device.