Google a fait marche arrière en exigeant que les OEM prennent en charge l'A/B virtuel sur les nouveaux appareils Android 11, ce qui aurait ouvert la voie à des mises à jour transparentes.
Mise à jour 1 (25/01/2021 à 14 h 06 HE) : Avant la sortie d'Android 11, Google semble avoir fait marche arrière en exigeant que les appareils de lancement prennent en charge l'A/B virtuel. Cliquez ici pour plus d'informations. L’article tel que publié le 7 avril 2021 est conservé ci-dessous.
Avec Android 7.0 Nougat, Google a introduit un système de partitionnement conçu pour accélérer les mises à jour logicielles. Dans Nougat, Google a ajouté la prise en charge de la duplication de certaines partitions afin que les partitions inactives puissent être mises à jour en arrière-plan, puis remplacées par actives avec un redémarrage rapide. Ce La configuration de la « partition A/B » permet des « mises à jour transparentes » se déroulera sur les appareils Android pris en charge, un peu comme Chrome OS de Google. Cependant, Google n'a jamais imposé l'utilisation de partitions A/B, c'est pourquoi de nombreux appareils ne prennent pas en charge les mises à jour transparentes. Cela pourrait cependant changer avec Android 11, car Google oblige les appareils nouvellement lancés à prendre en charge les partitions A/B virtuelles.
Pour un peu de contexte, les partitions A/B font référence à l'ensemble des partitions en lecture seule qui sont dupliquées. Les partitions dupliquées incluent généralement les partitions système, fournisseur, démarrage et produit. Lorsque le téléphone télécharge une mise à jour, le programme de mise à jour corrige l'ensemble de partitions inactives (un « emplacement ») en arrière-plan. Une fois la mise à jour appliquée sur l'emplacement inactif, l'utilisateur est invité à redémarrer son appareil. Lorsque l'utilisateur redémarre son appareil, l'emplacement inactif remplace l'emplacement actif, terminant ainsi le processus de mise à jour. L'emplacement précédemment actif reste intact en cas de problème de démarrage de l'emplacement nouvellement mis à jour. Lors de la prochaine mise à jour, ce processus est répété. Si vous êtes intéressé par une explication plus technique, reportez-vous à la documentation du développeur de Google sur les partitions A/B.
En revanche, les appareils sans partitions A/B, tels que le Samsung Galaxy S20, l'OPPO Find X2 et bien d'autres, appliquent les mises à jour via un programme de mise à jour dédié lors d'un processus de récupération. Cela expulse l'utilisateur d'Android et le rend incapable d'utiliser son appareil pendant plusieurs minutes, manquant potentiellement des notifications, des appels ou des SMS importants. Google estime que la simplification du processus de mise à jour amène davantage de personnes à effectuer une mise à jour une fois celle-ci déployée; en fait, en mai 2017, Google a découvert que un pourcentage plus élevé d'utilisateurs de Pixel que d'utilisateurs de Nexus exécutaient la dernière mise à jour de sécurité. Bien sûr, l'utilisateur peut planifier des mises à jour lorsqu'il n'utilise pas activement son appareil, mais de nombreux utilisateurs ne mettent tout simplement pas à jour leur appareil, même lorsqu'ils y sont invités. De plus, en ne disposant pas de partitions A/B, l’utilisateur passe à côté d’un de ses avantages inhérents: le protéger des mises à jour système bâclées.
Par exemple, lorsque Xiaomi a d'abord déployé la mise à jour Android 10 pour le Mi A2 Lite, de nombreux utilisateurs ont découvert que leurs appareils ne démarraient pas. Heureusement pour eux, le Mi A2 Lite dispose de partitions A/B pour des mises à jour transparentes, donc utilisateurs trouvés sur nos forums qu'ils pourraient utiliser une commande fastboot pour configurer le chargeur de démarrage afin qu'il démarre l'ensemble de partitions intact et précédemment actif. Ainsi, non seulement les partitions A/B offrent aux utilisateurs un processus de mise à jour beaucoup plus rapide, mais elles agissent également comme une sécurité contre les mises à jour bâclées. Les OEM qui n'ont pas implémenté de partitions A/B peuvent toujours concevoir leur propre façon de se protéger contre l'OTA. échecs, mais pourquoi se donner autant de mal alors que cette protection fait partie de la conception d'A/B cloisons? Pour votre information, voici une version partielle (et certes obsolète) liste des appareils prenant en charge les partitions A/B pour des mises à jour transparentes, et voici un tutoriel sur comment vérifier si votre propre appareil prend en charge la fonctionnalité.
Il peut sembler étonnant que certains équipementiers aiment Samsung facture 1 400 $ pour un smartphone mais n'offrira pas une fonctionnalité aussi intéressante. La raison se résume généralement au stockage: les OEM ne veulent pas sacrifier quelques gigaoctets d’espace de stockage pour prendre en charge des mises à jour transparentes. Les téléphones comme le Samsung Galaxy S20 ont un tonne de logiciels préinstallés, donc la duplication de partitions telles que /system et /product entraînera la duplication de nombreux fichiers et applications volumineux. Google a réussi à implémenter des partitions A/B sans trop sacrifier l'espace de stockage grâce à une astuce astucieuse pour contourner le problème de la duplication de fichiers .odex massifs. Une autre raison pour laquelle les OEM ont peut-être choisi de ne pas implémenter de partitions A/B est le coût: suivre les recommandations de Google. les modifications constantes des schémas de partition d'Android nécessitent beaucoup d'efforts, comme le souligne XDA Recognized Developer topjohnwu vous le dira. À moins que les équipementiers n’y soient contraints, nombreux sont ceux qui ne prendront pas la peine de modifier ce qui fonctionne déjà pour eux.
Mais finalement, Google semble faire la loi avec Android 11. En forçant l'adoption de partitions A/B virtuelles sur les appareils nouvellement lancés, ils ont pratiquement assuré que les OEM devront prendre en charge des mises à jour transparentes pour leurs appareils fin 2020 et 2021. Comme repéré par le développeur reconnu XDA luca020400, Yifan Hong, ingénieur logiciel chez Google au sein de l'équipe Project Treble, a soumis un engagement à l'AOSP Gerrit intitulé "Exiger Virtual A/B sur les lancements R. " Le commit met à jour le Vendor Test Suite, ou VTS, qui est un test automatisé que tous les appareils doivent réussir pour être considéré comme compatible avec Project Treble. Le nouveau test vérifie si la propriété système "ro.virtual_ab.enabled" est défini sur vrai et si "ro.virtual_ab.retrofit" est défini sur false sur les appareils dotés d'un niveau d'API d'expédition de 30 ou supérieur. En d’autres termes, ce test vérifie si un appareil lancé avec Android 11 ou supérieur prend en charge les partitions virtuelles A/B. Les partitions A/B « virtuelles » ont été introduites avec Android 10 aux côtés des « partitions dynamiques », qui sont des partitions redimensionnables dynamiquement. Il s'agit du même concept que les partitions A/B classiques, sauf qu'elles peuvent être librement redimensionnées.
Si un appareil lancé avec Android 11 ne prend pas en charge les partitions virtuelles A/B, il échouera avec VTS. Si l'appareil échoue au VTS, il ne peut pas être livré avec les services mobiles Google. En d’autres termes, Google a effectivement obligé les OEM à prendre en charge les partitions A/B virtuelles et, par extension, les mises à jour transparentes.
Mise à jour: Virtual A/B non requis pour Android 11
Lorsque nous avons signalé pour la première fois en avril que Google exigeait que tous les appareils de lancement d'Android 11 prennent en charge le mécanisme de mise à jour A/B virtuelle, il y a eu beaucoup d'enthousiasme car cela aurait enfin permis aux téléphones Samsung de bénéficier de mises à jour transparentes. Malheureusement, il s’avère que Google a décidé de ne pas rendre obligatoire la prise en charge A/B virtuelle. Android 11 Document de définition de compatibilité (CDD) indique actuellement « les implémentations de périphériques DEVRAIENT prendre en charge les mises à jour du système A/B » plutôt que la prise en charge « DOIT ». Il semble qu'à un moment donné avant la sortie d'Android 11, Google ait décidé de revenir sur sa décision d'exiger un support A/B virtuel, probablement à à la demande de plusieurs équipementiers. Cela arrive assez fréquemment mais n'est jamais communiqué au public puisque seule la version finale du CDD est publiée. en ligne.