Implémenter les mises à jour OTA

Pour mettre en œuvre les mises à jour Over The Air (OTA), le bootloader doit pouvoir accéder à un disque RAM de récupération au démarrage. Si l'appareil utilise une image de récupération AOSP non modifiée, le bootloader lit les 32 premiers octets de la partition misc. Si les données correspondent à boot-recovery, le bootloader démarre dans l'image recovery. Cette méthode permet de poursuivre toute tâche de récupération en attente (par exemple, l'application d'une OTA ou la suppression de données).

Pour en savoir plus sur le contenu d'un bloc dans Flash utilisé pour les communications entre la récupération et le bootloader, reportez-vous à bootable/recovery/bootloader_message/bootloader_message.h.

Appareils avec mises à jour A/B

Pour prendre en charge les mises à jour OTA sur les appareils qui utilisent des mises à jour A/B, assurez-vous que le bootloader de l'appareil répond aux critères suivants.

Critères généraux

• Toutes les partitions mises à jour via une OTA doivent pouvoir être mises à jour pendant le démarrage du système principal (et non lors de la récupération).

• Pour démarrer la partition system, le bootloader transmet la valeur suivante sur la ligne de commande du noyau: ro root=/dev/[node] rootwait init=/init.

• Il appartient au framework Android d'appeler markBootSuccessful à partir du HAL. Le bootloader ne doit jamais marquer une partition comme correctement démarrée.

Compatibilité avec le HAL de contrôle de démarrage

Le bootloader doit être compatible avec le HAL boot_control tel que défini dans hardware/libhardware/include/hardware/boot_control.h. Le programme de mise à jour interroge le HAL de contrôle de démarrage, met à jour l'emplacement de démarrage non utilisé, modifie l'emplacement actif à l'aide du HAL et redémarre dans le système d'exploitation mis à jour. Pour en savoir plus, consultez la section Implémenter le HAL de contrôle de démarrage.

Compatibilité avec les emplacements

Le bootloader doit être compatible avec les fonctionnalités liées aux partitions et aux emplacements, y compris:

• Les noms de partition doivent inclure un suffixe identifiant les partitions qui appartiennent à un emplacement particulier du bootloader. Pour chaque partition, il existe une variable has-slot:partition base name correspondante avec la valeur yes. Les emplacements sont nommés par ordre alphabétique (a, b, c, etc.) correspondant aux partitions portant le suffixe _a, _b, _c, etc. Le bootloader doit indiquer au système d'exploitation quel emplacement a été démarré à l'aide de la propriété de ligne de commande androidboot.slot_suffix. Cette propriété est définie via bootconfig pour les appareils lancés avec Android 12 ou version ultérieure.

• La valeur slot-retry-count est réinitialisée sur une valeur positive (généralement 3), soit par le HAL de la commande de démarrage via le rappel setActiveBootSlot, soit via la commande fastboot set_active. Lors de la modification d'une partition faisant partie d'un emplacement, le bootloader efface le message "ayant démarré" et réinitialise le nombre de tentatives pour l'emplacement.

Le bootloader doit également déterminer l'emplacement à charger. La figure montre un exemple de processus de décision.

1. Identifiez l'emplacement à essayer. N'essayez pas de charger un emplacement marqué slot-unbootable. Cet emplacement, appelé "emplacement actuel", doit être cohérent avec les valeurs renvoyées par fastboot.

2. Si l'emplacement actuel n'est pas marqué comme slot-successful et possède un slot-retry-count = 0, marquez-le comme slot-unbootable. Sélectionnez ensuite un autre emplacement, qui n'est pas marqué unbootable, mais est marqué comme slot-successful. Cet emplacement est désormais l'emplacement sélectionné. Si aucun emplacement actuel n'est disponible, démarrez pour récupérer ou affichez un message d'erreur explicite à l'utilisateur.

3. Sélectionnez le boot.img approprié et incluez le chemin d'accès à la bonne partition système sur la ligne de commande du noyau.

4. Renseignez le paramètre slot_suffix de la ligne de commande du noyau.

5. Démarrage. Si la valeur n'est pas définie sur slot-successful, diminuez la valeur slot-retry-count.

L'utilitaire fastboot détermine la partition à flasher lors de l'exécution de commandes Flash. Par exemple, l'exécution de la commande fastboot flash system system.img interroge d'abord la variable current-slot, puis concatène le résultat au système pour générer le nom de la partition à flasher (system_a, system_b, etc.).

Lorsque vous définissez l'emplacement actuel à l'aide de la commande fastboot set_active ou de la commande setActiveBootSlot de contrôle de démarrage setActiveBootSlot, le bootloader doit mettre à jour l'emplacement actuel, effacer slot-unbootable et slot-successful, et réinitialiser le nombre de tentatives (il s'agit du seul moyen d'effacer slot-unbootable).

Appareils sans mises à jour A/B

Pour prendre en charge les mises à jour OTA sur les appareils qui n'utilisent pas de mises à jour A/B (consultez la section Appareils non A/B pouvant être mis à jour), assurez-vous que le bootloader de l'appareil répond aux critères suivants.

• La partition recovery doit contenir une image capable de lire une image système à partir d'une partition compatible (cache, userdata) et de l'écrire dans la partition system.

• Le bootloader doit permettre un démarrage direct en mode Recovery.

• Si les mises à jour des images radio sont prises en charge, la partition recovery doit également pouvoir flasher la radio. Pour ce faire, deux possibilités s'offrent à vous:

  • Le bootloader fait clignoter la radio. Dans ce cas, il devrait être possible de redémarrer à partir de la partition de récupération dans le bootloader pour terminer la mise à jour.

  • L'image de récupération clignote dans la radio.Cette fonctionnalité peut être fournie sous la forme d'une bibliothèque binaire ou d'un utilitaire.