Mises à jour du système non A/B

Sur les anciens appareils Android sans partitions A/B, l'espace flash contient généralement les partitions suivantes :

botte
Contient le noyau Linux et un système de fichiers racine minimal (chargé dans un disque RAM). Il monte le système et d'autres partitions et démarre le runtime situé sur la partition système.
système
Contient des applications système et des bibliothèques dont le code source est disponible sur Android Open Source Project (AOSP). En fonctionnement normal, cette partition est montée en lecture seule ; son contenu ne change que lors d'une mise à jour OTA.
vendeur
Contient des applications système et des bibliothèques dont le code source n'est pas disponible sur Android Open Source Project (AOSP). En fonctionnement normal, cette partition est montée en lecture seule ; son contenu ne change que lors d'une mise à jour OTA.
données d'utilisateur
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.
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 dans l'espoir 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, comprenant 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.
divers
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.

Durée de vie d'une mise à jour OTA

Une mise à jour OTA typique contient les étapes suivantes :

  1. L'appareil effectue une vérification régulière auprès des serveurs OTA et est informé de la disponibilité d'une mise à jour, y compris l'URL du package de mise à jour et une chaîne de description à montrer à l'utilisateur.
  2. Mettez à jour les téléchargements vers un cache ou une partition de données, et sa signature cryptographique est vérifiée par rapport aux certificats dans /system/etc/security/otacerts.zip . L'utilisateur est invité à installer la mise à jour.
  3. L'appareil redémarre en mode de récupération, dans lequel le noyau et le système de la partition de récupération sont démarrés à la place du noyau de la partition de démarrage.
  4. Le binaire de récupération est démarré par init. Il trouve des arguments de ligne de commande dans /cache/recovery/command qui le pointent vers le package téléchargé.
  5. La restauration vérifie la signature cryptographique du package par rapport aux clés publiques dans /res/keys (partie du disque RAM contenue dans la partition de restauration).
  6. 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.
  7. L'appareil redémarre normalement.
    1. La partition de démarrage récemment mise à jour est chargée, puis elle monte et démarre l'exécution des fichiers binaires dans la partition système récemment mise à jour.
    2. Dans le cadre d'un démarrage normal, le système vérifie le contenu de la partition de récupération par rapport au contenu souhaité (qui était auparavant stocké sous forme de fichier dans /system ). Ils sont différents, donc 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à le nouveau contenu, donc aucune reflash n'est nécessaire.)

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 qui contient le binaire exécutable META-INF/com/google/android/update-binary . Après avoir vérifié la signature sur le package, la recovery extrait ce binaire dans /tmp et exécute le binaire en transmettant les arguments suivants :

  • Mettre à jour le numéro de version de l'API binaire . Si les arguments passés au binaire de mise à jour changent, ce nombre augmente.
  • Descripteur de fichier du tube 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 de fichier du fichier .zip du package de mise à jour .

Un package de mise à jour peut utiliser n'importe quel binaire lié statiquement comme binaire de mise à jour. Les outils de construction de packages OTA utilisent le programme de mise à jour ( bootable/recovery/updater ), qui fournit un langage de script simple pouvant effectuer de nombreuses tâches d'installation. Vous pouvez remplacer tout autre binaire exécuté sur l'appareil.

Pour plus de détails sur le binaire de mise à jour, la syntaxe edify et les fonctions intégrées, consultez Inside OTA Packages .

Migration à partir des versions précédentes

Lors de la migration depuis la version Android 2.3/3.0/4.0, le changement majeur est la conversion de toutes les fonctionnalités spécifiques à l'appareil à partir d'un ensemble de fonctions C avec des noms prédéfinis en objets C++. Le tableau suivant répertorie les anciennes fonctions et les nouvelles méthodes qui ont un objectif à peu près équivalent :

Fonction C Méthode C++
device_recovery_start() Périphérique ::RecoveryStart()
device_toggle_display()
device_reboot_now()
RecoveryUI :: CheckKey()
(également RecoveryUI :: IsKeyPressed())
device_handle_key() Périphérique ::HandleMenuKey()
device_perform_action() Périphérique ::InvokeMenuItem()
device_wipe_data() Périphérique ::WipeData()
device_ui_init() ScreenRecoveryUI ::Init()

La conversion d'anciennes fonctions en nouvelles méthodes devrait être raisonnablement simple. N'oubliez pas d'ajouter la nouvelle fonction make_device() pour créer et renvoyer une instance de votre nouvelle sous-classe Device.