Depuis 2016, Android a hérité du système de mise à jour silencieuse de ChromeOS. Le principe est simple, on découpe le stockage système en deux, et Android est installés deux fois, une fois sur chaque partie. Pendant que la première partie est utilisée par l’utilisateur, la seconde partie se met à jour en tâche de fond. Il suffit alors de redémarrer l’appareil pour basculer sur la seconde partie, et donc la nouvelle version d’Android.
Bien qu’il occupe plus de stockage, ce système permet de rendre les mises à jour plus simples et transparentes pour l’utilisateur, qui n’aura pas à interrompre l’utilisation de son appareil pendant trop longtemps.
LineageOS reprend le système à sa sauce
Nos confrères de XDA ont détecté dans des modifications du code source de LineageOS que cette ROM alternative allait bientôt prendre en charge les mises à jour pour les systèmes en deux parties comme décrites plus haut.
C’est d’autant plus intéressant pour LineageOS, car ce système est en perpétuel développement et multiplie les versions Nightly, en plus de versions plus stables.
Pour le moment, peu d’appareils Android utilisent cette architecture proposée par Google, probablement en raison du coût en espace de stockage. On compte dans la liste les Google Pixel, Pixel XL et le LG V20.
Si vous voulez recevoir les meilleures actus Frandroid sur WhatsApp, rejoignez cette discussion.
bah j'ai dû aller chercher l'info, il aurait pû le dire !! je sais bien que c'est une copie mdr
Y'a eu trop de connecteurs bouchés ou d'accidents plus grave avec les cpu en chaleur ou autre, donc oui c'est interdit a l'heure actuelle. ;)
alors ça y est! parce que je suis une machine j'ai pas le droit de me marier? sale mécanophobe! ?
bah, c'est juste une copie de ta partition système (différente sur chaque tel), donc elle ferait 1,4Go pour toi...
Mmh, ça doit dépendre du nombre d'applis que tu possèdes sur le téléphone... Tu ne peux pas supprimer les programmes préinstallés ? Pour LineageOS c'est certain de toute manière ? Mais oui, au niveau des téléphones vendus neufs, avec la ROM d'origine, ça risque de poser des problèmes.
Je ne savais pas que Android supportait ZFS (j'aimerais bien avoir une source), par contre, j'imagine que ce n'est pas de la "compression" à proprement parler (qui serait assez lente et inefficace) mais plutôt du Copy-on-Write. Lorsque des fichiers sont copiés-collés, plutôt que de dupliquer/recopier bêtement les données sur le support (comme les vieux systèmes de fichiers type EXT4 le font), le système de fichiers va juste découper le fichier original en blocs et dire "ce bloc est le même ici" (un genre de lien symbolique pour des portions de fichiers). Ce n'est que lorsque l'une des deux portions de fichier sera modifiée que le système de fichiers va effectivement dupliquer la portion concernée pour appliquer les changements à un seul des deux blocs. C'est parfaitement adapté au cas présent puisque le copier-coller du FS entier va virtuellement prendre 0 octets espace (en pratique un peu plus puisqu'il faut quand même stocker l'information qui dit que tel bloc est le même ailleurs), puis on aura en gros uniquement à stocker en surplus la différence entre les deux mises-à-jour, ce qui est assez limité la plupart du temps. C'est cette ristourne qui permet à Apple de se pamer et faire un effet d'annonce en conférence en montrant qu'un copier-coller d'un fichier de 10Go prenait 5 minutes auparavant (pas de support de CoW sur HFS+) et est désormais instantané (APFS supporte CoW). Bien que reproductible, c'est un peu biaisé quand même à mon avis ;-) . Ça existe depuis belle lurette.
La liste doit se limiter aux Google Pixel. Dans une autre catégorie tu as les Chromebook.
Quelqu'un a une liste des terminaux qui utilisent ce système de mise à jour ? Car sur OP3T sur Nougat il n'y a bel et bien qu'une partition système, avec boot du recovery avec chaque màj.
Top, remplacer pour mon ZF2 avec 6.0 buggé abandonné par ASUS. 1x par semaine des updates, j'ai pas rencontrer des soucis tout est régler: - batterie - lag ghost - GPS Etc Je suis en Nougat 7.1
Malheureusement, il me semble que cela fasse juste, à cause des programmes pré-installés et en me restreignant en apk et ce avec une sd 64 go j'ai beaucoup d'alertes sur le stockage. Je ne peux plus prendre un smartphone 16 go, c'est trop contraignant
Good question. Moi j'ai fait des benchmarks que sur eMMC et j'ai pas vu de différence de temps de boot. Mon pronostic c'est que pour de l'UFS (bien plus rapide c'est vrai) tu verras pas de différence... avec un bon CPU ;) L'UFS est monté que sur du haut de gamme, les CPU sont puissants... bref je pense que ça reste un bon calcul de compresser, mais ce n'est que mon avis basé sur pas grand chose ;) En tous cas dans l'avenir les CPU vont s'améliorer bcp plus vite que le débit du stockage donc de totues façons ça deviendra de plus en plus intéressant.
Ou alors 16 + carte microSD, en mettant toutes les données deplacables (photos, films et données des applis) sur la microSD
Intéressante comme analyse.
Du coup ce que tu dis sur le goulot d'étranglement de l'emmc est vrai pour l'UFS 2.1 aussi ou nan ?
Cassim, tu aurais pu donner une idée de la taille de cette partition système, pour qu'on se rende compte. Sur mon téléphone marshmallow, elle fait 1.4 Go. C'est pas rien de bouffer 1.4 Go juste pour gagner de temps aux mises à jour.
Sauf que l'intérêt ici c'est que cela devrait te permettre de revenir à l'ancienne version stable si la mise à jour est vérolée ou bugguée...
Mais une machine ca se marie pas voyons ^^
Merci, en lisant tout tes autres com', j'ai tout compris. Nickel
Enormément d'utilisateurs (pas vraiment ceux qu'on croise ici) ont peur des mises à jour. Il faut brancher le téléphone, le laisser 20mn tourner et le voir faire des "trucs bizarres"... c'est un poil terrifiant pour bcp. Je sais, ça prête à rire, mais Google l'a observé via les mises à jours non effectuées. Il s'agit ici de faire des mises à jour plus souvent (un simple reboot !) et de manière moins pénible. Le but final pour Google est de promouvoir les mises à jour au maximum. A noter que c'est couplé avec tout un tas de nouveautés qui séparent la parite Google de Android (l'AOSP) de a partie OEM (BSP). A terme, Google pourrait mettre à jour les téléphones sans même que le fabriquant ait quoi que ce soit à faire.
Il va télécharger "de force", mais c'est toi qui va au final accepter ou pas la mise à jour effective.
Consommation de RAM, non. Quand tu lis du EXT4, tu dois mettre les données en RAM. Là c'est pareil : tu lis, tu décompresses, tu mets en RAM la version décompressée (donc équivalent à EXT4). Pour être clair : il ne s'agit pas de décompresser toute l'image en RAM puis de considérer un RAMdisk. C'est bien de la décompression à la volée. Niveau performances, c'est pas plus long. En effet, le goulot d'étranglement de nos jours est plutôt la vitesse de l'eMMC plutôt que le CPU (même dans le monde du mobile :) ). Donc tu lis moitié moins de données sur l'eMMC, c'est donc plus rapide en lecture. Google a conseillé un algo particulier de ZFS (je sais plus lequel, mais il n'est présent que dans les kernel récents), je suppose qu'ils ont fait plusieurs bench pour voir le moins gourmand en CPU.
Est-ce que ça ne baisse pas les performances par rapport un système comme ext4 ou f2fs. Qui dit compression, dit nécessité de décompresser... Et une puce mobile n'est pas un core i Est ce que ça ne se fait pas au détriment de la consommation de ram?
Je comprends bien le concept et l'argumentation mais est-ce qu'on est si accro qu'on peut pas se passer du téléphone pendant 20min 1 fois par mois pour la mise à jour de sécurité? Je préfère attendre que la mise à jour se fasse et bénéficier de plus de stockage que l'inverse...
Ce système est-il contournable? Et il possible de choisir l'un ou l'autre ? Parce-que j'aime encore bien savoir ce que j'installe moi... Sans compter les mises à jour qui, des fois, sont buguées !
En fait sur une implémentation "normale", ça ne prend pas bcp plus d'espace de stockage. En effet, le FS utilisé pour le système est ZFS (à la place de EXT4), qui compresse à peu près par 2 la taille de stockage.
Il sera vain de prendre un appareil à moins de 32 Go si l'on veut bénéficier des mises à jour
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix