Créer et appliquer des paquets de mise à jour B2G OS

Créer et appliquer une mise à jour se divise en quatre étapes :

1. Construire des paquets de mise à jour incrémentale à partir d'ancienne(s) version(s) vers une nouvelle version compilée sur un hôte.
2. Rechercher le bon paquet de mise à jour à télécharger sur le client.
3. Télécharger la mise à jour.
4. Appliquer la mise à jour aux fichiers existants sur l'appareil.

Chacune de ces étapes est abordée ci-dessous.

Prérequis

Pour construire et appliquer des mises à jour, vous devez vous assurer que votre build dispose de l'updater et des outils de mise à jour associés. Par défaut, ceux-ci ne sont présents que dans les variantes userdebug et user. Vous pouvez néanmoins forcer leur construction en ajoutant la ligne suivante dans votre fichier .userconfig :

export B2G_UPDATER=1

Pour signer les paquets de mise à jour, vous aurez besoin d'installer un environnement d'exécution Java (JRE) ou le kit de développement logiciel Java (JDK), et d'avoir la commande java accessible via le path par défaut.

Types de mise à jour

Il existe deux types de mise à jour à connaître : FOTA (Firmware Over-The-Air) et OTA Gecko/Gaia (Over-The-Air). Voyons les différences qu'il y a entre les deux.

Mises à jour FOTA

Le système B2G OS entier peut être actualisé via les mises à jour FOTA, la technologie sous-jacente qui est commune avec le projet Android. Parmi les emplacements du disque dur du téléphone qui peuvent être modifiés par les mises à jour FOTA figurent la partition système, le noyau, le modem en bande de base, l'image de recovery utilisée pour la mise à jour, ou tout autre fichier présent sur l'appareil.

B2G OS ne dépend pas d'un client FOTA en particulier, une API que nous appelons librecovery constituant une interface d'abstraction. Néanmoins, nous recommandons l'utilisation du client de recovery GOTA (voir plus bas pour plus de détails), et le texte présent se base sur le fait que GOTA est utilisé.

Les paquets de mise à jour FOTA consistent essentiellement en un fichier nommé update.zip. Ce paquet est constitué des éléments suivants

• Un ensemble de diffs binaires et de nouveaux fichiers requis pour mettre à jour le client vers la nouvelle version du logiciel
• Un "script de mise à jour" qui contrôle la façon dont les diffs et les nouveaux fichiers sont chargés sur le client
• Une signature interne servant à vérifier le paquet de mise à jour

Ce format et l'ensemble des fichiers sont identiques à ceux utilisés pour les mises à jour Android normales, excepté que B2G OS encapsule en plus le paquet update.zip dans un wrapper mar (MAR signifie Mozilla ARchive). Ce wrapper mar offre un degré supplémentaire de vérification, ce qui est expliqué plus bas.

Mises à jour OTA Gecko/Gaia

Autrement, il est possible de ne mettre à jour sur un appareil B2G OS que les fichiers de Gecko et Gaia, à travers un mécanisme que nous appelons mises à jour OTA Gecko/Gaia. L'ensemble des fichiers de Gecko et Gaia — ce qui comprend le cœur exécutif de Gecko et l'interface utilisateur de l'appareil — se trouve dans le répertoire /system/b2g de l'appareil. Il s'agit du seul répertoire auquel les mises à jour OTA peuvent apporter des modifications.

Les mises à jour OTA Gecko/Gaia utilisent la même technologie que celle mise en œuvre pour mettre à jour le navigateur web Firefox pour ordinateur de bureau. Un peu comme les paquets FOTA update.zip abordés plus haut, les mises à jour OTA consistent en un fichier MAR contenant un ensemble de diffs binaires et de nouveaux fichiers nécessaires à la mise à jour du client vers une version plus récente du logiciel.

Le client Gecko vérifie l'intégrité des MARs qu'il a téléchargés, ces derniers pouvant être signés par plusieurs parties.

Pourquoi avoir deux technologies de mise à jour ?

Les mises à jour OTA ne sont pas aussi complètes que les FOTA, mais elles sont beaucoup plus ergonomiques et simples à appliquer, et elles correspondront mieux à vos besoins concernant les mises à jour :

• Les mises à jour OTA Gecko/Gaia peut être appliquées "en arrière-plan" pendant que B2G OS continue à fonctionner normalement. Cela apporte une meilleure expérience utilisateur car les utilisateurs n'ont pas besoin de redémarrer leur téléphone ni d'attendre pendant que la mise à jour se fait. Au lieu de ça, la mise à jour est appliquée pendant que l'utilisateur continue à utiliser le téléphone, puis, une fois la mise à jour terminée, l'utilisateur a juste à accepter de redémarrer le processus b2g principal. Cela ne prend que quelques secondes, au lieu des minutes qu'il faut généralement attendre pour l'application des mises à jour FOTA.
• Les paquets de mise à jour OTA Gecko/Gaia peuvent parfois être plus petits que ceux des mises à jour FOTA, bien que ce ne soit pas toujours le cas ; ils ne seront par contre jamais plus gros. Cela signifie que les utilisateurs pourront quelquefois avoir moins de données à télécharger.

Bien sûr, s'il vous faut actualiser des fichiers autres que ceux de Gecko/Gaia, vous n'aurez pas d'autre choix que de passer par un paquet FOTA complet.

Voyons à présent la suite avec l'examen du processus de construction du paquet.

Construire des paquets de mise à jour

La construction des mises à jour est le processus consistant à générer les fichiers nécessaires à la mise à jour des clients B2G OS d'une version X du logiciel vers une nouvelle version Y. Le paquet de mise à jour requis pour le client dépend des fichiers qui ont été modifiés entre la version X et la version Y.

• Si seuls des fichiers présents dans /system/b2g ont été modifiés, il faudra générer une mise à jour OTA Gecko/Gaia
• Si un fichier situé ailleurs que dans /system/b2g a été changé, une mise à jour FOTA devra être générée

Pour générer un paquet de mise à jour incrémentale (que ce soit pour des mises à jour FOTA ou OTA Gecko/Gaia), nos outils nécessitent la construction complète de la version X et de la version Y. Une construction complète signifie que le paquet intègre tous les fichiers nécessaires au flashage d'un client. Lorsque nous produisons une construction complète pour la version X, nous ne savons pas quelle sera la future version vers laquelle il faudra effectuer la mise à jour de la version X . C'est pour cette raison que les paquets FOTA et les paquets Gecko/Gaia complets doivent être construits pour chaque version. Cela permet de générer aussi bien une mise à jour OTA Gecko/Gaia incrémentale qu'une mise à jour FOTA incrémentale si besoin, entre la version X et toutes les versions futures.

Schématiquement, le processus de construction d'un mise à jour ressemble à ceci :

1. Avec le logiciel version X
   • Générer un fichier MAR OTA Gecko/Gaia complet du contenu de /system/b2g.
   • Générer une archive zip des fichiers cibles pour la mise à jour FOTA complète, éventuellement signée, pour les partitions de l'appareil. Le zip des fichiers cibles est référencé plus bas sous le nom DEVICE-target_files-$VARIANT.$USER.zip, c'est un zip contenant les fichiers pour mettre à jour les répertoires du téléphone, dont SYSTEM/, BOOT/, etc. Un fichier FOTA complet update.zip peut être produit à partir du zip des fichiers cibles.
2. Avec le logiciel version Y
   • Générer un fichier MAR OTA Gecko/Gaia complet du contenu de /system/b2g.
   • Générer une archive zip des fichiers cibles pour la mise à jour FOTA complète, éventuellement signée, pour les partitions de l'appareil. Le zip des fichiers cibles est référencé plus bas sous le nom DEVICE-target_files-$VARIANT.$USER.zip, c'est un zip contenant les fichiers pour mettre à jour les répertoires du téléphone, dont SYSTEM/, BOOT/, etc. Un fichier FOTA complet update.zip peut être produit à partir du zip des fichiers cibles.
3. Si seuls des fichiers de /system/b2g ont changé, générer un fichier MAR pour une mise à jour OTA Gecko/Gaia incrémentale de la version X vers la version Y.
4. Sinon, générer un fichier FOTA incrémental update.zip de la version X vers la version Y. Intégrer cette mise à jour FOTA incrémentale update.zip dans un fichier MAR pour le distribuer auprès du client B2G.
5. Signer les paquets comme cela est requis pour les autorisations de distribution.

Les sous-sections ci-dessous décrivent comment utiliser les outils de B2G pour implémenter chacune de ces étapes.

Générer un fichier MAR complet de mise à jour OTA Gecko/Gaia

Pour générer un MAR de mise à jour OTA complète à partir de la dernière compilation de b2g réussie (e.g. que vous avez compilée vous-même), vous devez invoquer la cible gecko-update-full. Pour placer le MAR dans $b2g/objdir-gecko/dist/b2g-update/b2g-gecko-update.mar, utilisez les commandes suivantes :

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

Générer un fichier MAR de mise à jour FOTA complète

Pour générer un MAR de mise à jour FOTA complète à partir de la dernière compilation de b2g réussie (e.g. que vous avez compilée vous-même), vous devez invoquer la cible gecko-update-fota-full. Cela intègre le contenu de la partition /system dans sa totalité. Voici les commandes dont vous avez besoin :

$ cd $b2g
$ ./build.sh gecko-update-fota-full

Un fichier ZIP sera généré ($PRODUCT_OUT/fota/full/update.zip) ainsi qu'un fichier MAR ($PRODUCT_OUT/fota-$TARGET_DEVICE-update-full.mar). Le fichier ZIP peut être utilisé directement avec adb sideload, tandis que le MAR est prévu pour être distribué de la même manière que tout autre paquet de mise à jour.

Générer un fichier MAR de mise à jour FOTA plus un paquet de recovery

Depuis Firefox OS 2.2 (mi-avril et après) nous avons ajouté une nouvelle cible pour make, elle peut être appelée ainsi :

$ cd $b2g
$ ./build.sh gecko-update-fota-fullimg

Elle est utilisée pour produire un paquet de recovery constituant un dump du jeu d'images de partitions. Le jeu par défaut est contrôlé par la variable B2G_FOTA_FULLIMG_PARTS, définie dans gonk-misc/Android.mk (parmi la plupart des autres nouvelles fonctionnalités vues plus bas.) Il s'agit d'une chaîne de caractères utilisant l'espace comme séparateur, listant les instances mountpoint:image à inclure. La valeur par défaut est "/boot:boot.img /system:system.img /recovery:recovery.img /cache:cache.img".

Avec tout ça, nous avons également introduit quelques nouvelles variables d'environnement pour contrôler la production de deux autres cibles make — gecko-update-fota et gecko-update-fota-full :

• La première est B2G_FOTA_PARTS, elle suit le même modèle de syntaxe que B2G_FOTA_FULLIMG_PARTS. Cela nous permet de produire ces paquets de mise à jour et de faire un dump des images de partitions avec ceux-ci, p.ex. la partition de boot, le firmware du modem, etc.
• B2G_FOTA_PARTS_FORMAT offre un moyen de décrire un jeu de partitions dont le formatage est souhaité durant l'installation du paquet de recovery. C'est une liste de points de montage, séparés par des espaces, à utiliser lors du formatage.
• Deux nouvelles variables permettent d'effacer (wipe) les caches et/ou les données pendant la procédure de construction :
  • B2G_FOTA_WIPE_DATA
  • B2G_FOTA_WIPE_CACHE

Générer un fichier MAR de mise à jour FOTA Gecko/Gaia partielle

Une mise à jour FOTA partielle utilise le même mécanisme que pour celles complètes, mais par défaut, seuls sont inclues les mises à jour Gecko/Gaia, tout comme une mise à jour OTA normale. Des fichiers supplémentaires autres que ceux de Gecko/Gaia peuvent aussi être intégrés (tels que des polices de caractères).

La logique derrière la génération d'un paquet de mise à jour FOTA partielle est principalement conditionnée par des problèmes de licence : lors de la construction d'un paquet de mise à jour FOTA complet, la partition système entière (au moins) sera intégrée. Elle peut comporter des blobs que vous n'êtes pas autorisé à redistribuer. Cependant, comme la distribution de MAR est utile et que Gecko/Gaia eux-mêmes sont des logiciels libres, il n'y a aucune raison pour que nous ne puissions pas être en mesure de les distribuer de cette façon. Une FOTA partielle permet de ne mettre à jour qu'un sous-ensemble du système. Dans un tel scénario, une mise à jour OTA pourrait être employée à la place, mais cela aurait un coût : les mises à jour OTA ont besoin d'assez d'espace sur la partition système pour contenir à la fois les fichiers Gecko/Gaia existants et les fichiers de mise à jour décompressés. Une mise à jour FOTA partielle ne possède pas cette contrainte car elle écrase les fichiers existants par ceux de la mise à jour.

Pour créer une mise à jour FOTA partielle à partir de la dernère compilation de b2g réussie (e.g. que vous avez compilée vous-même), invoquez la cible gecko-update-fota avec les commandes suivantes :

$ cd $b2g
$ ./build.sh gecko-update-fota

Elles vont générer un fichier ZIP ($PRODUCT_OUT/fota/partial/update.zip) et un fichier MAR ($PRODUCT_OUT/fota-$TARGET_DEVICE-update.mar). Le fichier ZIP peut être utilisé directement avec adb sideload, tandis que le fichier MAR est destiné à être distribué de la même manière que tout autre paquet de mise à jour.

La construction peut être contrôlée par un certain nombre de variables d'environnement, les plus utiles d'entre-elles sont documentées ci-dessous :

Générer une archive zip des fichiers cibles pour une mise à jour FOTA complète

Invoquez la cible target-files-package pour construire un zip des fichiers cibles qui pourra servir à générer des mises à jour FOTA tant complète qu'incrémentale. Le zip des fichiers cibles peut aussi être signé avec des clés personnalisées pour garantir que seules les mises à jour FOTA en provenance de sources connues  puissent être installées. Après signature des fichiers cibles, toutes les images et mises à jour (OTA aussi) doivent à nouveau être générées pour obtenir les clés insérées.

Cette étape est réalisée par les commandes suivantes :

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

Les valeurs des variables dans les commandes listées ci-dessus doivent être remplies comme suit :

Signer le zip des fichiers cibles d'une FOTA complète

Les distributions correctes devraient en principe être signées par des clés personnalisées connues uniquement du vendeur. Grâce à l'introduction de cette couche de sécurité supplémentaire, le fait de posséder de telles clés empêchera l'installation de mises à jour FOTA dont la source est inconnue. Pour que cela fonctionne, les images flashées sur un appareil doivent inclure les clés publiques tandis que les mises à jour doivent être signées avec les clés privées correspondantes. 

La première étape consiste à générer des clés personnalisées et à les stocker en lieu sûr. Android Open Source Project dispose d'un script pour générer ces clés. Pour une compatibilité totale, récupérez ce script depuis la branche correspondant à la version de Gonk présente sur l'appareil en question. La version pour la branche master se trouve ici.

Plusieurs clés sont requises — créez-les avec les commandes suivantes. releasekey est la clé à utiliser pour signer les paquets de mise à jour FOTA.

$ development/tools/make_key releasekey '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
$ development/tools/make_key platform '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
$ development/tools/make_key shared '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
$ development/tools/make_key media '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'

Une fois les clés présentes, le fichier zip des fichiers cibles peut être signé par l'emploi des commandes suivantes. Elles vont insérer les clés publiques et modifier les propriétés du build pour refléter le fait qu'il ait été signé.

$ cd $b2g
$ ./build/tools/releasetools/sign_target_files_apks \
  --default_key_mappings $RELEASEKEY_FOLDER \
  --replace_ota_keys \
  --signapk_path prebuilts/sdk/tools/lib/signapk.jar \
  $UNSIGNED_TARGET_FILES_ZIP \
  $SIGNED_TARGET_FILES_ZIP

Les valeurs des variables présentes dans les commandes listées plus haut doivent être remplies de la manière qui suit :

Générer un fichier MAR de mise à jour OTA incrémentale

Dans cet exemple, nous supposons générer une mise à jour du logiciel version X vers la version Y. L'emplacement du fichier MAR de l'OTA Gecko/Gaia complète compilé à partir du logiciel version X en suivant les instructions ci-dessus sera appelé $MAR_X par la suite. ll peut s'agir d'un chemin sur le serveur de compilation comme /home/build/b2g/versions/X/update.mar. De manière similaire, l'emplacement du MAR complet compilé à partir de la version Y sera appelé $MAR_Y.

L'outil build-gecko-mar.py va générer un fichier MAR de mise à jour OTA Gecko/Gaia incrémental en utilisant $MAR_X et $MAR_Y. La destination du fichier généré sera appelée $GENERATED_INCREMENTAL_MAR_X_Y. Utilisez les commandes suivantes pour cette étape :

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

Générer une archive zip de mise à jour FOTA incrémentale

Dans cet exemple, nous supposons générer une mise à jour du logiciel version X vers la version Y. L'emplacement du zip cible pour la FOTA complète construite à partir du logiciel version X en utilisant les instructions ci-dessus sera appelé $TARGET_FILES_X par la suite. Il peut s'agir d'un chemin sur un serveur de compilation comme /home/build/b2g/versions/X/target_files.zip. De manière similaire, l'emplacement du zip cible pour la FOTA complète construite à partir de la version Y sera appelé $TARGET_FILES_Y.

L'outil build/tools/releasetools/ota_from_target_files va générer un fichier FOTA update.zip incrémental en se servant de $TARGET_FILES_X et de $TARGET_FILES_Y. La destination de ce fichier intermédiaire sera appelée $INTERMEDIATE_FOTA_UPDATE_FOTA_X_Y.

Après la génération de ce update.zip, la dernière étape sera de l'encapsuler dans un MAR pour le livrer au client B2G. L'outil tools/update-tools/build-fota-mar.p effectue cette opération. La destination où générer le fichier sera appelée $GENERATED_INCREMENTAL_FOTA_X_Y.

Utilisez les commandes suivantes pour achever cette étape  :

$ cd $b2g
$ ./build/tools/releasetools/ota_from_target_files -v \
    --incremental_from $TARGET_FILES_X \
    --signapk_path prebuilts/sdk/tools/lib/signapk.jar \
    --package_key $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

Les valeurs des variables employées dans les commandes listées ci-dessus devraient être remplies de la manière suivante :

Hébergement des mises à jour et recherche de nouvelles versions côté client

Les clients B2G OS scrutent les mises à jour en récupérant et analysant un manifeste de mise à jour : update.xml. Les clients B2G OS sont configurés pour rechercher des mises à jour sur des serveurs spécifiques — ils interrogent un chemin construit spécialement sur le serveur. HTTPS est le protocole recommandé pour être utilisé par le client pour interroger le serveur, cependant, HTTP est aussi pris en charge. Le serveur et le chemin consultés par les clients peuvent être modifiés par la livraison aux clients existants d'une mise à jour qui change le code de scrutation.

Dans les exemples ci-dessous, nous estimerons que les mises à jour sont hébergées sur le serveur updates.b2g.com.

L'URL scrutée par le client contient habituellement les paramètres suivants :

Le client Firefox utilise les valeurs de son hôte de mise à jour configuré et de ces valeurs pour construire une URL à interroger pendant l'exécution. La structure est la suivante :

https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_DEVICE%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml

Un exemple réel d'une telle URL est comme ceci :

https://aus4.mozilla.org/update/3/B2G/37.0a1/20141214040212/flame/en-US/nightly-b2g37/Boot2Gecko%202.2.0.0-prerelease%20%28SDK%2019%29/default/default/update.xml?force=1

Si le serveur renvoie "404 Not Found" en réponse à la requête du client, cela signifie qu'aucune mise à jour n'est disponible. S'il renvoie "200" et un fichier de manifeste, alors c'est qu'une mise à jour peut être disponible. Le manifeste décrit la version nouvellement disponible ; autrement dit, celle vers laquelle le client peut être mis à jour. Voici un exemple de manifeste :

<?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"
          isOSUpdate="true">
    <patch type="partial" URL="https://updates.b2g.com/release/unagi1/18.0/20121203123456/update.mar"
           hashFunction="SHA512" hashValue="5111e033875752b7d9b32b4795152dea5ef954cb8a9d4a602dd19a923b464c43521287dcb5781faf3af76e6dc5e8a3dd9c13edea18c1f2c8f3bd89e17d103d6f"
           size="41901319"/>
  </update>
</updates>

Il suit le même schéma que le manifeste de compilation B2G (voir le format updates.xml pour plus de détails). Les champs du manifeste décrivent :

• Métadonnées utilisées pour afficher une interface utilisateur sur le client.
• Métadonnées sur la version nouvellement disponible.
• L'emplacement du paquet de mise à jour.
• Métadonnées utilisées pour vérifier le téléchargement du paquet de mise à jour.

En utilisant le mécanisme décrit plus haut, les serveurs peuvent héberger des paquets de mise à jour pour que tout client avec une ancienne version puisse passer à une nouvelle version. Ou alors, ils peuvent héberger uniquement un "historique linéaire de mises à jour" à partir duquel les clients peuvent se mettre à jour via un chemin unique.

Les détails de l'interaction entre les serveurs de compilation et l'hôte de mise à jour dépassent pour l'instant la portée de ce document. Elle est très grandement dépendante de l'environnement de production. Vous pouvez trouver quelques détails supplémentaires sur notre page de wiki Software Update.

Vérifier et appliquer les mises à jour

Après qu'un client B2G OS ait détecté avec succès une mise à jour (ce qui est fait depuis le système lui-même), téléchargé celle-ci et vérifié l'intégrité du paquet de mise à jour téléchargé, l'étape finale est d'appliquer la mise à jour.

La première chose dans l'application d'une mise à jour est la vérification de la signature embarquée dans les paquets MAR (voir Generating an incremental FOTA update zip sur la façon dont elles sont créées). Cela est réalisé par le client B2G OS lui-même après le contrôle de l'intégrité du paquet téléchargé. Le code utilisé pour cette tâche est le même que ce soit pour les mises à jour FOTA ou pour celles OTA Gecko/Gaia.

Après la vérification des signatures, le processus d'application d'une mise à jour diverge selon le type de mise à jour, OTA Gecko/Gaia ou FOTA. À ce stade, voyons les différences entre les deux.

Appliquer des mises à jour OTA Gecko/Gaia

Le client B2G OS applique celles-ci grâce à l'utilisation du binaire updater. Il fait partie de la distribution Gecko et son code est le même que celui utilisé pour mettre à jour la version de bureau de Firefox. Comme cela a été décrit précédemment, la mise à jour est appliquée pendant que le client B2G OS continue de fonctionner normalement. Pendant l'application des mises à jour, les utilisateurs sont toujours en mesure de passer des appels ou d'en recevoir, de lancer des applications, de naviguer sur le web etc.

Les détails spécifiques au binaire updater dépassent le cadre de ce document mais il fonctionne approximativement de cette manière :

• Il réalise une copie des fichiers présents dans /system/b2g.
• Il applique les patches binaires, supprime les anciens fichiers et ajoute les nouveaux comme cela est spécifié dans le fichier MAR.
• Il redémarre le processus principal b2g afin que celui-ci utilise tous les nouveaux fichiers.

Après le redémarrage du processus b2g, l'utilisateur bénéficiera de la nouvelle version du logiciel client B2G.

Appliquer des mises à jour FOTA

Elles sont appliquées par le client FOTA. Le client Gecko se "débarrasse" de la mise à jour en appelant l'API librecovery qui se chargera de l'appliquer. Ce qui arrive après cette étape est spécifique à chaque client FOTA.

Dans l'implémentation de librecovery utilisée par le client GOTA, l'application du paquet de mise à jour téléchargé est planifiée et des commandes particulières sont mises en file d'attente pour le client de recovery. librecovery redémarre ensuite l'appareil en mode recovery. Le client recovery lance ensuite le script de mise à jour situé dans le fichier update.zip pour mettre à jour les fichiers et les partitions si nécessaire. Le client de recovery peut avoir besoin de redémarrer plusieurs fois afin de mettre à jour tous les fichiers.

Après le redémarrage final, l'appareil fonctionnera avec la nouvelle version du logiciel client B2G OS.