À 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.
Mises à jour du système autres que les mises à jour A/B
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les mises à jour non AB sont une méthode OTA obsolète utilisée par les anciens appareils Android (Android 6 et versions antérieures). Ces appareils disposent d'une partition de récupération dédiée contenant le logiciel nécessaire pour décompresser un package de mise à jour téléchargé et appliquer la mise à jour aux autres partitions.
Sur les anciens appareils Android sans partitions A/B, l'espace flash contient généralement les partitions suivantes:
- démarrage
-
Contient le noyau Linux et un système de fichiers racine minimal (chargé sur un disque RAM). Il monte le système et d'autres partitions, et démarre l'environnement d'exécution situé sur la partition système.
- d'infoloisirs
-
Contient des applications système et des bibliothèques dont le code source est disponible sur le projet Android Open Source (AOSP). En fonctionnement normal, cette partition est montée en lecture seule. Son contenu ne change que lors d'une mise à jour OTA.
- fournisseur
-
Contient des applications et des bibliothèques système dont le code source n'est pas disponible sur le projet Android Open Source (AOSP). En fonctionnement normal, cette partition est montée en lecture seule. Son contenu ne change que lors d'une mise à jour OTA.
- userdata
-
Stocke les données enregistrées par les applications installées par l'utilisateur, etc. Cette partition n'est normalement pas touchée par le processus de mise à jour OTA.
- mettre en cache
-
Zone de stockage temporaire utilisée par quelques applications (l'accès à cette partition nécessite des autorisations d'application spéciales) et pour le stockage des packages de mise à jour OTA téléchargés. D'autres programmes utilisent cet espace en prévoyant que les fichiers peuvent disparaître à tout moment. Certaines installations de packages OTA peuvent entraîner l'effacement complet de cette partition. Le cache contient également les journaux de mise à jour d'une mise à jour OTA.
- récupération
-
Contient un deuxième système Linux complet, y compris un noyau et le binaire de récupération spécial qui lit un paquet et utilise son contenu pour mettre à jour les autres partitions.
- misc
-
Petite partition utilisée par la récupération pour stocker des informations sur ce qu'elle fait au cas où l'appareil serait redémarré pendant l'application du package OTA.
Cycle de vie d'une mise à jour OTA
Une mise à jour OTA type comprend les étapes suivantes:
-
L'appareil effectue des vérifications régulières auprès des serveurs OTA et est informé de la disponibilité d'une mise à jour, y compris de l'URL du package de mise à jour et d'une chaîne de description à afficher pour l'utilisateur.
-
Les mises à jour sont téléchargées dans un cache ou une partition de données, et leur signature cryptographique est validée par rapport aux certificats dans
/system/etc/security/otacerts.zip. L'utilisateur est invité à installer la mise à jour.
-
L'appareil redémarre en mode récupération, dans lequel le noyau et le système de la partition de récupération sont démarrés au lieu du noyau de la partition de démarrage.
-
Le binaire de récupération est lancé par init. Il recherche des arguments de ligne de commande dans
/cache/recovery/command qui le redirigent vers le package téléchargé.
-
La récupération vérifie la signature cryptographique du package par rapport aux clés publiques dans
/res/keys (partie du disque RAM contenu dans la partition de récupération).
-
Les données sont extraites du package et utilisées pour mettre à jour les partitions de démarrage, système et/ou fournisseur si nécessaire. L'un des nouveaux fichiers laissés sur la partition système contient le contenu de la nouvelle partition de récupération.
-
L'appareil redémarre normalement.
-
La partition de démarrage nouvellement mise à jour est chargée, puis elle est montée et commence à exécuter des binaires dans la partition système nouvellement mise à jour.
-
Lors du démarrage normal, le système compare le contenu de la partition de récupération au contenu souhaité (qui était auparavant stocké en tant que fichier dans
/system). Comme ils sont différents, la partition de récupération est reflashée avec le contenu souhaité. (Lors des démarrages suivants, la partition de récupération contient déjà les nouveaux contenus. Il n'est donc pas nécessaire de flasher à nouveau.)
La mise à jour du système est terminée. Les journaux de mise à jour se trouvent dans /cache/recovery/last_log.#.
Mettre à jour les packages
Un package de mise à jour est un fichier .zip contenant le binaire exécutable META-INF/com/google/android/update-binary. Après avoir vérifié la signature du package, recovery extrait ce binaire dans /tmp et l'exécute, en transmettant les arguments suivants:
-
Mettez à jour le numéro de version de l'API binaire. Si les arguments transmis au binaire de mise à jour changent, ce nombre augmente.
-
Déscripteur de fichier du canal de commande. Le programme de mise à jour peut utiliser ce canal pour renvoyer des commandes au binaire de récupération, principalement pour les modifications de l'interface utilisateur, telles que l'indication de la progression à l'utilisateur.
-
Nom du fichier
.zip du package de mise à jour
Un package de mise à jour peut utiliser n'importe quel binaire lié de manière statique comme binaire de mise à jour. Les outils de création de packages OTA utilisent le programme de mise à jour (bootable/recovery/updater), qui fournit un langage de script simple capable d'effectuer de nombreuses tâches d'installation. Vous pouvez remplacer n'importe quel autre binaire exécuté sur l'appareil.
Pour en savoir plus sur le binaire du programme de mise à jour, la syntaxe edify et les fonctions intégrées, consultez Inside OTA Packages (À l'intérieur des packages OTA).
Migrer à partir de versions précédentes
Lors de la migration depuis Android 2.3/3.0/4.0, le changement majeur est la conversion de toutes les fonctionnalités spécifiques à l'appareil d'un ensemble de fonctions C avec des noms prédéfinis en objets C++.
Le tableau suivant liste les anciennes fonctions et les nouvelles méthodes qui ont une fonction à peu près équivalente:
| Fonction C |
Méthode C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(également RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
La conversion des anciennes fonctions en nouvelles méthodes devrait être relativement simple. N'oubliez pas d'ajouter la nouvelle fonction make_device() pour créer et renvoyer une instance de votre nouvelle sous-classe Device.
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,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
