Esta página foi traduzida pela API Cloud Translation.

Atualizações do 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 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.
dados do usuário: Armazena os dados salvos por aplicativos instalados pelo usuário, etc. Esta partição normalmente não é tocada pelo processo de atualização OTA.
esconderijo: Área de retenção temporária usada por alguns aplicativos (acessar esta partição requer permissões especiais do aplicativo) 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 eliminação 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.
diversos: Pequena partição usada pela recuperação para armazenar algumas informações sobre o que está fazendo caso o dispositivo seja 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:

O dispositivo realiza check-in 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.
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.
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.
O binário de recuperação é iniciado pelo init. Ele encontra argumentos de linha de comando em /cache/recovery/command que apontam para o pacote baixado.
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).
Os dados são extraídos 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.
O dispositivo reinicia normalmente.
1. A partição de inicialização recém-atualizada é carregada e é montada e inicia a execução de binários na partição de 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, então a partição de recuperação é atualizada com o conteúdo desejado. (Nas inicializações subsequentes, a partição de recuperação já contém o novo conteúdo, portanto, não é necessário reflash.)

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

Atualizar pacotes

Um pacote de atualização é um arquivo .zip que contém o binário executável META-INF/com/google/android/update-binary . Após 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 da API binária . Se os argumentos passados para o binário de atualização forem alterados, esse número será incrementado.
Descritor de arquivo do canal de comando . O programa de atualização pode usar esse pipe para enviar comandos de volta ao binário de recuperação, principalmente para alterações na interface do usuário, como indicar o progresso ao usuário.
Nome de arquivo do arquivo .zip do pacote de atualização .

Um pacote de atualização pode usar qualquer binário vinculado estaticamente como o binário de atualização. As ferramentas de construção de pacotes 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 Inside OTA Packages .

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 servem a um propósito aproximadamente equivalente:

função C	Método C++
device_recovery_start()	Dispositivo::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()	Dispositivo::WipeData()
device_ui_init()	ScreenRecoveryUI::Init()

A conversão de funções antigas para novos métodos deve ser razoavelmente simples. 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.