À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour implémenter les mises à jour OTA (Over The Air), 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 à toute tâche de récupération en attente (par exemple, l'application d'une mise à jour OTA ou la suppression de données) de se poursuivre jusqu'à son achèvement.
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 mise à jour OTA doivent être actualisables 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 kernel: 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 démarrée avec succès.
Prise en charge du HAL de contrôle du démarrage
Le bootloader doit être compatible avec le HAL boot_control tel que défini dans hardware/libhardware/include/hardware/boot_control.h. L'outil de mise à jour interroge le HAL de contrôle du démarrage, met à jour l'emplacement de démarrage inutilisé, 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 du démarrage.
Compatibilité avec les emplacements
Le bootloader doit prendre en charge les fonctionnalités liées aux partitions et aux emplacements, y compris:
Les noms de partitions doivent inclure un suffixe qui identifie les partitions appartenant à un emplacement particulier dans le bootloader. Pour chaque partition de ce type, il existe une variable has-slot:partition base name correspondante avec une valeur de yes. Les emplacements sont nommés par ordre alphabétique (a, b, c, etc.) et correspondent aux partitions avec 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 contrôle du démarrage via le rappel setActiveBootSlot, soit via la commande fastboot set_active. Lorsque vous modifiez une partition faisant partie d'un emplacement, le bootloader efface "booted successfully" (démarrage réussi) et réinitialise le nombre de tentatives pour l'emplacement.
Le bootloader doit également déterminer quel emplacement charger. La figure montre un exemple de processus de décision.
Figure 1. Flux de création de slots du bootloader
Déterminez l'emplacement à essayer. N'essayez pas de charger un emplacement marqué slot-unbootable. Cet emplacement doit être cohérent avec les valeurs renvoyées par fastboot et est appelé emplacement actuel.
Si l'emplacement actuel n'est pas marqué comme slot-successful et qu'il comporte un slot-retry-count = 0, marquez-le comme slot-unbootable. Sélectionnez ensuite un autre créneau qui n'est pas marqué unbootable, mais slot-successful. Ce créneau est maintenant sélectionné. Si aucun emplacement actuel n'est disponible, démarrez en mode récupération ou affichez un message d'erreur pertinent à l'utilisateur.
Sélectionnez le boot.img approprié et incluez le chemin d'accès à la partition système correcte sur la ligne de commande du kernel.
Renseignez le paramètre slot_suffix de la ligne de commande du noyau.
Démarrez. Si la valeur n'est pas slot-successful, diminuez slot-retry-count.
L'utilitaire fastboot détermine la partition à flasher lors de l'exécution de commandes de 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 HAL de contrôle du démarrage setActiveBootSlot, le bootloader doit mettre à jour l'emplacement actuel, effacer slot-unbootable et slot-successful, et réinitialiser le nombre de tentatives (c'est le 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 (voir 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 de démarrer directement en mode récupération.
Si les mises à jour d'images radio sont prises en charge, la partition recovery doit également pouvoir flasher la radio. Pour ce faire, procédez de l'une des manières suivantes:
Le bootloader flashe 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 la radio. Cette fonctionnalité peut être fournie sous la forme d'une bibliothèque ou d'un utilitaire binaire.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Implement OTA updates\n\nTo implement the [over-the-air (OTA) updates](/docs/core/ota), the\nbootloader must be able to access a recovery RAM disk during boot. If the device\nuses an unmodified AOSP recovery image, the bootloader reads the first 32 bytes\non the `misc` partition; if the data there matches `boot-recovery`, the\nbootloader boots into the `recovery` image. This method enables any pending\nrecovery work (for example, applying an OTA or removing data) to continue to\ncompletion.\n\nFor details on the content of a block in flash used for communications by\nrecovery and the bootloader, refer to\n[bootable/recovery/bootloader_message/bootloader_message.h](https://android.googlesource.com/platform/bootable/recovery/+/android16-release/bootloader_message/include/bootloader_message/bootloader_message.h#64).\n\nDevices with A/B updates\n------------------------\n\nTo support OTA updates on devices that use [A/B\nupdates](/docs/core/ota/ab), ensure that the device bootloader meets\nthe following criteria.\n\n### General criteria\n\n- All partitions updated through an OTA should be updatable while the main\n system is booted (and not updated in recovery).\n\n- To boot the `system` partition, the bootloader passes the following value on\n kernel command line: `ro root=/dev/[node] rootwait init=/init`.\n\n- It's the responsibility of the Android framework to call `markBootSuccessful`\n from the HAL. The bootloader should never mark a partition as successfully\n booted.\n\n### Support for boot control HAL\n\nThe bootloader must support the `boot_control` HAL as defined in\n`hardware/libhardware/include/hardware/boot_control.h`. The updater queries the\n[boot control\nHAL](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/boot/1.0/IBootControl.hal),\nupdates the boot slot not in use, changes the active slot using the\nHAL, and reboots into the updated operating system. For details, see\n[Implementing the boot control\nHAL](/docs/core/ota/ab/ab_implement#bootcontrol).\n\n### Support for slots\n\nThe bootloader must support functionality related to partitions and slots,\nincluding:\n\n- Partition names must include a suffix that identifies which partitions\n belong to a particular slot in the bootloader. For each such partition,\n there's a corresponding variable\n `has-slot:`\u003cvar translate=\"no\"\u003epartition base name\u003c/var\u003e with a value of\n `yes`. Slots are named alphabetically as a, b, c, etc. corresponding to\n partitions with the suffix `_a`, `_b`, `_c`, etc. The bootloader should inform\n the operating system which slot was booted using the command line property\n `androidboot.slot_suffix`. This property is set through bootconfig for devices\n launching with Android 12 or higher.\n\n- The `slot-retry-count` value is reset to a positive value (usually `3`),\n either by the boot control HAL through the `setActiveBootSlot` callback or\n through the `fastboot set_active` command. When modifying a partition that's\n part of a slot, the bootloader clears \"successfully booted\" and resets the\n retry count for the slot.\n\nThe bootloader should also determine which slot to load. The figure shows an\nexample decision process.\n**Figure 1.** Bootloader slotting flow\n\n1. Determine which slot to attempt. Don't attempt to load a slot marked\n `slot-unbootable`. This slot should be consistent with the values returned by\n fastboot, and is referred to as the current slot.\n\n2. If the current slot isn't marked as `slot-successful` and has a\n `slot-retry-count = 0`, mark the current slot as `slot-unbootable`. Then\n select a different slot that is not marked `unbootable` and is marked as\n `slot-successful`; this slot is now the selected slot. If no current slot is\n available, boot to recovery or display a meaningful error message to the\n user.\n\n3. Select the appropriate `boot.img` and include the path to correct system\n partition on the kernel command line.\n\n4. Populate the kernel command line `slot_suffix` parameter.\n\n5. Boot. If not marked `slot-successful`, decrement `slot-retry-count`.\n\nThe `fastboot` utility determines which partition to flash when running any\nflash commands. For example, running the `fastboot flash system system.img`\ncommand first queries the `current-slot` variable then concatenates the result\nto system to generate the name of the partition that should be flashed\n(`system_a`, `system_b`, etc.).\n\nWhen setting the current slot using the fastboot `set_active` command or the\nboot control HAL `setActiveBootSlot` command, the bootloader should update\nthe current slot, clear `slot-unbootable` and `slot-successful`, and reset the\nretry count (this is the only way to clear `slot-unbootable`).\n\nDevices without A/B updates\n---------------------------\n\nTo support OTA updates on devices that don't use A/B updates (see [Non-A/B\nupdatable devices](/docs/core/ota/nonab)), ensure that the device\nbootloader meets the following criteria.\n\n- The `recovery` partition should contain an image that is capable of reading a\n system image from some supported partition (`cache`, `userdata`) and writing\n it to the `system` partition.\n\n- The bootloader should support booting directly into recovery mode.\n\n- If radio image updates are supported, the `recovery` partition should also be\n able to flash the radio. This can be accomplished in one of two ways:\n\n - The bootloader flashes the radio. In this case, it should be possible to\n reboot from the recovery partition back into the bootloader to complete the\n update.\n\n - The recovery image flashes the radio. This functionality can be provided as\n a binary library or utility."]]