Criando e aplicando pacotes de atualização do Firefox OS

Essa atividade é dividida em quatro tarefas:

1. Compilar um pacote de atualização incremental da versão(ões) anteriores para uma nova versão em uma máquina de compilacão.
2. Encontrar o pacote de atualização correto.
3. Baixar a atualização.
4. Aplicar a atualização dos arquivos existentes no dispositivo.

Cada uma das etapas está descrita abaixo.

Tipos de atualização

São dois tipos de atualização a saber: FOTA e Gecko/Gaia OTA. Vamos verificar a diferença entre elas

Atualização FOTA

É possível atualizar o Firefox OS inteiro através da atualização FOTA, a tecnologia usada é compartilhada do projeto Android. Os locais no disco rígido do telefone podem ser alterados usando a alteração incluindo a partição do sistema, kernel, modem, imagem de recuperação usada para atualização, ou qualquer outro arquivo no dispositivo.

Firefox OS não depende de um cliente FOTA em particular, a interface é abstraída através de uma API que chamamos librecovery. Portanto nós recomendamos usar o cliente de recuperação GOTA (veja abaixo para mais detalhes), e assumiremos a utilização do FOTA a partir de agora.

O pacote de atualização FOTA consiste-se principalmente de um arquivo chamado update.zip. Esse pacote possui:

• Um conjunto de "diffs" binários e novos arquivos necessários para a atualizção do cliente para a nova versão do software
• Um script de atualização que controla como os "diffs" e novos arquivos serão carregados no cliente
• Uma assinatura interna usada para verificar o pacote de atualização

O formato e o conjunto de arquivo são os mesmos que os usados em uma atualização normal do Android, exceto pelo fato de que o Firefox OS adicionamente envolve o pacote update.zip  em um invólucro mar (MAR é o acrônimo de Mozilla ARchive). Esse invólucro mar possibilita um nível adicional de verificação que será explicado abaixo.

Atualização Gecko/Gaia OTA

A outra opção é atualizar apenas os arquivos do Gecko e o Gaia em um dispositivo Firefox OS através de um mecanismo que nós chamamos atualizações Gecko/Gaia OTA. Todos os arquivos Gecko e Gaia — compreendendo o Gecko runtime core e as interfaces de usuário do dispositivo — estão no diretório do dispositivo /system/b2g. Esse é o único diretório que o OTA pode fazer alterações.

As atualizações Gecko/Gaia OTA utilizam a mesma tecnologia utilizada pela atualização do navegador Firefox para desktop. Muito parecido com os pacotes  FOTA update.zip discutidos acima, as atualizações OTA consiste-se de um arquivo MAR contendo um conjunto de diffs binários e novos arquivos necessários para atualizar o cliente com uma nova versão.

O cliente Gecko verifica a integridade dos arquvios MARs que foram baixados e os MARs podem ser assinados por múltiplas partes.

Por que ter duas tecnologias de atualizações?

Atualizações OTA não são tão abrangentes as atualizações FOTA, mas são muito mais amigáveis e fáceis de usar, e geralmente o processo de atualização funciona bem.

• Atualizações Gecko/Gaia OTA podem ser aplicadas "em segundo plano", enquanto o Firefox OS continua a funcionar normalmente. Isso proporciona um experiência do usuário muito melhor uma vez que não é necessário reiniciar o telefone e esperar enquanto a atualização é aplicada. Quando o processo termina a única coisa que o usuário precisa fazer é concordar em reiniciar o processo principal b2g. Isso leva apenas alguns segundos, em vez dos minutos normalmente necessários para aplicar as atualizações FOTA.
• Normalmente, mas nem sempre, os pacotes de atualização Gecko/Gaia OTA são menores que os pacotes FOTA. Isso significa que os usuários podem ter menos dados para baixar.

É claro que se você precisar atualizar arquivos fora do Gecko/Gaia, você terá que usar o roteiro do pacote completo FOTA.

Seguindo, vamos verificar o processo de compilação do pacote.

Compilando os pacotes de atualização

A compilação das atualizações é o processo de gerar os arquivos necessários para atualizar os clientes Firefox OS da versão X do software para a nova versão Y. O pacote de atualização necessário depende de quais arquivos foram alterados entre a versão X e a versão Y.

• se somente arquivos do diretório /system/b2g foram alterados, vamos gerar uma atualização Gecko/Gaia OTA
• Se algum arquivo que não seja do diretório /system/b2g é alterado, nós vamos gerar uma atualização FOTA

Para gerar um pacote de atualização incremental (seja para atualização FOTA ou Gecko/Gaia OTA), nossas ferramentas necessitam compilações completas de ambas as versões X e Y (nova e a anterior). Compilação completa significa que o pacote inclui todos os arquivos necessários para fazer o flash no cliente. Quando nós produzimos uma compilação completa da versão X, nós não sabemos quais as futuras versões nós atualizaremos a partir da versão X. Por isso, nós compilamos ambos os pacotes para cada versão. Isso possibilita criar pacotes incrementais.

Numa visão geral, o processo de compilação é semalhante a isso:

1. Com o software versão X
   • Gerar um arquivo completo MAR do Gecko/Gaia OTA para o conteúdo do diretório /system/b2g.
   • Gerar arquivo completo update.zip do FOTA e arquivos zip específicos para as partições do dispositivo.
2. Com o software versão Y
   • Gerar um arquivo completo  MAR do Gecko/Gaia OTA do diretório /system/b2g.
   • Gerar um arquivo completo update.zip do FOTA e arquivos zip específicos para as partições do dispositivo.
3. Se apenas os arquivos do diretório /system/b2g foram alterados, gerar uma atualização incremental Gecko/Gaia OTA MAR da versão X para a versão Y.
4. Caso contrário, gerar um arquivo update.zip da atualização incremental FOTA da versão X para a versão Y. Empacote a atualização incremental FOTA update.zip em um MAR para entrega ao cliente B2G.
5. Assine os pacotes como exigido pelos acordos de entrega.

A sub-sessão abaixo descreve como usar as ferramentas do B2G para implementar cada uma dessas etapas.

Gerando uma atualização Gecko/Gaia OTA

completa em MAR

Execute gecko-update-full para gerar um MAR completo da última compilação bem sucedida do b2g. Para colocar o MAR em $b2g/objdir-gecko/dist/b2g-update/b2g-gecko-update.mar, use os seguintes comandos:

$ cd $b2g
$ ./build.sh gecko-update-full
$ cp objdir-gecko/dist/b2g-update/b2g-gecko-update.mar <destination>

Gerando uma atualização FOTA zip completa e arquivos de destino

O alvo padrão no sistema de compilação b2g irá gerar um FOTA update.zip / arquivos de destino zip quando o kernel binário tiver sido copiado para a localização apropriada embaixo do diretório vendor/. Isso habilita a imagem de boot, imagem de recuperação e a geração do update.zip.

• O arquivo completo do FOTA update.zip é gerado em out/target/product/$DEVICE/$DEVICE-ota-$VARIANT.$USER.zip
• O arquivo zip de destino é gerado em out/target/product/$DEVICE/obj/PACKAGING/target_files_intermediates/$DEVICE-target_files-$VARIANT.$USER.zip

Os comandos a seguir realizam essa etapa:

$ cd $b2g
$ ./build.sh target-files-package
$ cp out/target/product/$DEVICE/obj/PACKAGING/target_files_intermediates/$DEVICE-target_files-$VARIANT.$USER.zip <destination>

Os valores das variáveis nos comandos listados acima devem ser preenchidos dessa forma:

Gerando um MAR da atualização incremental OTA

Nesse exemplo, nós assumimos que estamos gerando uma atualização do software versão X para versão Y. A localização do MAR completo da compilação Gecko/Gaia OTA da versão X usando as instruções acima será chamado de $MAR_X. Isso deve ser um caminho no servidor de compilacão como por exemplo /home/build/b2g/versions/X/update.mar. De forma similiar, a localização do MAR completo da versão Y será chamado de $MAR_Y.

A ferramenta build-gecko-mar.py vair gerar uma MAR da atualização incremental usando $MAR_X e $MAR_Y. Nós chamaremos o destino do arquivo gerado de $GENERATED_INCREMENTAL_MAR_X_Y. Use os seguintes comandos para essa etapa:

$ cd $b2g
$ ./tools/update-tools/build-gecko-mar.py --from $MAR_X --to $MAR_Y $GENERATED_INCREMENTAL_MAR_X_Y

Gerando um update.zip da atualização incremental FOTA

Nesse exemplo, nós assumimos que estamos gerando uma atualização do software versão X para versão Y. A localização do arquivo zip completo do FOTA compilado do software vesrão X usando as instruções acima será chamado $TARGET_FILES_X. Esse deve ser o caminho no servidor de compilação como /home/build/b2g/versions/X/target_files.zip. De forma semelhante, a localização do zip destino do FOTA completo construido da versão Y será chamado $TARGET_FILES_Y.

A ferramenta build/tools/releasetools/ota_from_target_files irá gerar um FOTA incremental no arquivo update.zip usando $TARGET_FILES_X e $TARGET_FILES_Y. Nós chamamos o arquivo intermediário de  $INTERMEDIATE_FOTA_UPDATE_FOTA_X_Y.

Depois do arquivo update.zip ter sido gerado, a última etapa é empacotá-lo em um arquvio MAR para entrega ao cliente b2g. A ferramenta tools/update-tools/build-fota-mar.p executa essa etapa. Nós chamaremos o destino desse arquivo gerado de $GENERATED_INCREMENTAL_FOTA_X_Y. Use os seguintes comandos para completar essa etapa:

$ cd $b2g
$ ./build/tools/releasetools/ota_from_target_files -v \
    -i $TARGET_FILES_X \
    -p out/host/$HOST_ARCH \
    -k $FOTA_SIGNING_KEY \
    $TARGET_FILES_Y \
    $INTERMEDIATE_FOTA_UPDATE_FOTA_X_Y
$ ./tools/update-tools/build-fota-mar.py $INTERMEDIATE_FOTA_UPDATE_FOTA_X_Y --output=$GENERATED_INCREMENTAL_FOTA_X_Y

Os valores das variáveis nos comandos listados acima devem ser preenchidos dessa forma:

Hospedagem e polling de atualizações no lado do cliente

Clientes Firefox OS fazem polling das atualizações através de um parsing do manifesto de atualização: update.xml. Os clientes Firefox OS são configurados para fazer o polling de atualizações em servidores específicos — eles consultam um caminho especialmente construído no servidor. HTTPS é o protocolo recomendado para consultar o servidor, embora HTTP também é suportado. O servidor e o caminho utilizado pelos clientes podem ser alterados entregando uma atualização para clientes existentes que altera o código do polling.

Nos exemplos abaixo, assumimos que as atualizações estão hospedadas no servidor updates.b2g.com.

A URL pesquisada pelo cliente comumente contém os seguintes parâmetros:

Entretando, existem mais valores que podem ser consultados para construir a consulta de URL de atualização.

O cliente Firefox usa os valores de onde as atualizações estão hospedadas para construir a URL para o polling em tempo de execução. Um exemplo dessa URL é:

https://updates.b2g.com/release/unagi1/18.0/20121203123456/update.xml

Se o servidor retornar um erro "404 Not Found" em resposta à requisição do cliente, então não há atulização disponível. Se o servidor retornar "200" e o arquivo manifesto, então há uma atualizacão disponível. O manifesto descreve a compilação recem-disponível, ou seja, a atualização que o cliente deve usar. Um exemplo de manifesto:

<?xml version="1.0"?>
<updates>
  <update type="major" appVersion="19.0" version="19.0" extensionVersion="19.0" buildID="20121210123456"
          licenseURL="https://www.mozilla.com/test/sample-eula.html"
          detailsURL="https://www.mozilla.com/test/sample-details.html">
    <patch type="partial" URL="https://updates.b2g.com/release/unagi1/18.0/20121203123456/update.mar"
           hashFunction="SHA512" hashValue="5111e033875752b7d9b32b4795152dea5ef954cb8a9d4a602dd19a923b464c43521287dcb5781faf3af76e6dc5e8a3dd9c13edea18c1f2c8f3bd89e17d103d6f"
           size="41901319"/>
  </update>
</updates>

Os campos no manifesto descrevem:

• metadata usado para mostrar a interface no cliente
• metadata sobre a versão recém-disponível
• a localização do pacote de atualização
• metadata usado para verificar o download do pacote de atualização

Usando os mecanismos acima descritos, os servidores podem hospedar pacotes de atualização para atualizar qualquer versão antiga cliente para a versão mais recente. Ou podem hospedar somente uma "atualização linear" na qual os clientes devem atualizar através de um caminho simples.

Os detalhes da interação entre os servidores de compilação e de atualização estão fora do escopo desse documento. E são altamente dependentes no ambiente produtivo.

Verificando e aplicando as atualizações

Após o cliente Firefox OS ter baixado a atualização e verificado a integridade do pacote, a etapa final é aplicar a atualização.

A primeira etapa consiste-se em verificar as assinaturas embutidas nos pacotes MAR. Isso é feito pelo próprio cliente Firefox OS após checar a integridade do pacote. O código usado para isso é o mesmo para atualizações FOTA ou Gecko/Gaia OTA.

Após as assinaturas terem sido verificadas, o processo de aplicar uma atualização diverge entre os tipos de pacotes. Vamos ver as diferenças entre os dois a partir de agora.

Aplicando atualizações Gecko/Gaia OTA

O cliente Firefox OS usa o executável updater para aplicar as atualizações. É parte da distribuição Gecko e é o mesmo código usado para aplicar as atualizações do Firefox Desktop. Como descrito acima, a atualização é aplicada enquanto o Firefox OS continua a rodar normalmente. Usuários podem fazer e receber ligações, executar aplicativos, navegar na internet, etc durante o processo de atualização.

Os detalhes específicos do updater estão além do escopo desse documento, mas seu funcionamento é aproximadamente descrito abaixo:

• Faz uma cópia do diretório /system/b2g.
• Aplica os patches binários, removendo arquivos antigos, e incluindo os novos como especificado no arquivo MAR.
• Reinicia o processo principal b2g para que utilize os novos arquivos.

Após reiniciar o processo b2g o usuário já está executando a nova versão do software cliente B2G.

Aplicando atualizações FOTA

O cliente FOTA é o responsável por aplicar a atualização. O cliente Gecko não interefer no processo que será aplicado chamando a API librecovery. O que acontece após essa etapa é específico de cada cliente FOTA.

Na implementação do librecovery usado pelo cliente FOTA, o pacote de atualização baixado é armazenado para ser aplicado e comandos especiais são enfileirados para recuperar o cliente. librecovery então inicializa o dispositivo no modo recovery no qual é executado o script que está dentro do arquivo update.zip que atualiza os arquivos e as partições necessárias. O cliente recovery pode necessitar reinicar o dispositivo diversas vezes para atualizar todos os arquivos.

Na inicialização final, o dispositivo estará com a nova versão do Firefox OS instalado.