Google a annoncé hier de nouveaux outils de compression pour réduire encore la taille des mises à jour pour les applications, qui peuvent parfois représenter un problème. Bien que les chiffres montrent l’efficacité de la méthode, elle ne se fera pas sans impact sur l’autonomie. Explications.
Il a toujours existé deux grandes méthodes pour mettre à jour un système ou une application, qu’il s’agisse d’une suite bureautique ou d’un jeu. On peut simplement compresser les fichiers complets pour les décompresser ensuite sur l’appareil et procéder par écrasement des données. Ou on peut au contraire réduire les différences à leur plus simple expression, le processeur devant alors exécuter des calculs plus importants.
Réduire toujours plus la taille des patchs
En juillet dernier, Google avait annoncé l’utilisation de l’algorithme bsdiff pour détecter et compresser les différences entre l’APK installé sur l’appareil mobile et celui présent sur le Play Store. Le gain annoncé était d’environ 50 % par rapport à la technique utilisée auparavant, permettant de générer des mises à jour plus petites à télécharger. Il y avait donc gain de temps et moins de pression sur les forfaits data, à moins bien sûr de le faire sur une connexion Wi-Fi.
Google en remet une couche, avec une nouvelle technique baptisée « File-by-File patching ». Cette fois, le gain est en moyenne de 65 % et peut même atteindre 90 % sur certaines applications. La création du patch passe par la décompression de l’ancienne et de la nouvelle application, toujours via bsdiff.
Les modifications sont cependant appliquées sur les données décompressées, avant qu’elles soient recompressées. Les signatures sont ensuite comparées pour vérifier que le nouvel APK formé sur l’appareil correspond bien au dernier disponible sur le Play store.
Une augmentation parfois significative du temps d'installation
On se rapproche donc beaucoup plus de l’intervention « minutieuse » avec un minimum de données envoyées. Ce qui engendre une charge supplémentaire pour le processeur, ce dont Google prévient d’ailleurs. Ainsi, sur des appareils récents, datant de 2015 au moins, l’étape de compression réclame en moyenne une seconde par mégaoctet. Un temps qui est loin d’être négligeable, et qui sera encore plus important sur des appareils plus anciens.
Globalement, Google indique que si la taille des mises à jour est divisée par deux, le temps d’installation est quant à lui doublé. L’éditeur indique que ces changements sont introduits pour économiser autant de données que possible. Mais l’introduction de ce mécanisme est étrange à une époque où les forfaits data ne cessent de grandir.
Car les utilisateurs, s’ils constatent un impact sur leur autonomie, risquent d’attendre systématiquement d’avoir à disposition un chargeur et un réseau Wi-Fi. Il se pourrait aussi que cette nouveauté s'adresse à des marchés plus spécifiques comme les pays en voie de développement, où les constructeurs de smartphones fondent de nombreux espoirs pour la croissance de leur activité dans les mois et années à venir.
Notez enfin que la technique « File-by-File patching » est open source. Elle fait partie du projet Archive Patcher, que l’on peut trouver sur GitHub.
Commentaires (54)
#1
mais va multiplier le nombre de mises à jour par 10 " />
#2
Pas mécontent d’avoir un téléphone avec une bonne autonomie ! " />
(7-8 Jours sans le recharger : j’ai décidé d’appeler mon téléphone Seb … Quand je vois l’autonomie je dis “Seb c’est bien !!” " />)
#3
Suffit de pas avoir ces conneries sur son telephone… Ah merde en fait un nokia 3310 m’irait tres bien :P
#4
Par contre, pour les mises à jour d’Android, vous pouvez toujours espérer…
#5
#6
#7
#8
Quel(s) constructeur(s) fait(font) un réel suivi des maj au-delà de 2-3 ans ?
#9
#10
Android 7.1.1 sera pourtant déployé sur le Nexus 6, c’était dans l’annonce officielle.
#11
Ca ressemble à une initiative pour faire passer Android plus facilement dans les pays émergent ou les forfaits data sont chers et avec un petit débit
#12
#13
N’empêche, ma N10 fonctionne encore très bien mais si j’ai bien compris, même les correctifs de sécurité ne seront bientôt plus déployés.
Alors évidemment, on peut se tourner vers les ROM customs mais on y gagne quelques bugs au passage (bug de caméra sur la N10 avec Nougat et des soucis avec la lecture de fichiers avec DRM Widevine par exemple).
Mais bon, on nous dit tout le temps que ça n’entre pas dans le cadre de l’obsolescence programmée car ça n’empêche pas l’appareil de fonctionner… Oui, il fonctionne, mais au niveau sécurité…
#14
#15
#16
Peut etre un pas de plus vers un processus de maj plus importante des composants systeme.
#17
#18
#19
#20
-JDG Star Wars-
ON S’EN BRANLE
ON S’EN BRANLE
ON S’EN BRANLE
Ce qu’on veut ce sont de nouvelles mises à jour, pas l’amélioration des existantes.
#21
#22
En ce qui concerne le fait que ca utilise plus de batterie/temps, perso les mises à jour se font quand c’est en charge et sur wifi (donc le soir quand je vais me coucher). Ils peuvent prendre le temps qu’ils veulent " />
#23
#24
Probablement, ya rien techniquement qui les empêche de reprendre la même technique pour les màj d’Android. Sauf si à l’échelle d’un système l’étape de recompression est considérée comme beaucoup trop longue.
#25
#26
Trés bien pour moi au contraire ! Windows va faire pareil
Franchement, il ne manque plus que Steam qui me bouffe une bande passante de dingue.
#27
#28
Pour les jeux, ce n’est pas la mise à jour de l’appli qui prend du temps, mais lors du lancement, la connexion aux serveur, la vérification des fichiers et le téléchargement des màj/dlc.
#29
#30
#31
Mais l’introduction de ce mécanisme est étrange à une époque où les forfaits data ne cessent de grandir.
Pourtant Google annonce sur le blog que cela leur permettra d’économiser jusqu’à 6 Po de données par jour ! Ce n’est pas négligeable.
The savings, compared to our previous approach, add up to 6 petabytes of user data saved per day!
#32
#33
#34
#35
Sur chrome, google avait abandonné bsdiff pour une solution maison, pourquoi ne pas utiliser cette technologie ? On parle du même google, non ?
#36
#37
Le Nexus 6 aura La 7.1.1
https://blog.google/products/android/sweet-update-nougat-android-711/
#38
Mauvaise foi à ce que je vois
#39
le lumia 920 c’est l’inverse, il a eut la preview de Win10 mais n’a jamais vu windows 10 final et n’en aura jamais les mises à jour.
Pas un constructeur de merde, Microsoft " />
Microsoft est très loin d’avoir un smartphone qui a eut 10 ans de mise à jour " />
#40
1 seconde de plus par Mo ?!
😮
#41
Sauf que Google s’est foiré en ce sens que la partue user d’Android est corrélée à une version de noyau
(pas les applications, hein, mais la base Android: libs et exe)
#42
#43
Effectivement, et je connais des gens qui ont joué à faire passer des versions AOSP un autre kernel (ou me plusieurs). Mais cette dépendance est cependant présente, et ça doit gêner les constructeurs.
Mais, à la réflexion, nettement moins que les modules livrés en binaire par les fournisseurs de SoC et de chips divers: Là encore, le module porte sa version de kernel, et si le fournisseur ne suit pas, le constructeur de téléphone est coincé (à titre personnel, j’ai déjà patché un binaire de module pour changer la version, mais ça marche tant que les API intra-kernel n’ont pas bougé, et puis, un constructeur peut-il se permettre ça ?)
#44
#45
#46
s’ils pouvaient diminuer le nombre de maj tout simplement …
#47
#48
#49
+1
#50
#51
Huawei :)
#52
Sérieux ?
Et ils sont comment leurs terminaux ?
J’ai un - un peu vieillissant - GS3 LTE dont je commence à ressentir l’envie (le besoin ? ) de le remplacer.
J’ai vu quelques modèles sympas (bon, ok, le S7, mais que chez samsung), mais qui me paraissent bien trop cher, surtout si c’est pour ne plus avoir de maj aussi rapidement.
#53
Le honor4X est sorti en 2014 et a reçu android 6.0
J’ai un honor 5X, je suis aussi sous 6.0
(honor étant une sous marque de huawei d’excellente facture)
Je ne peux que te recommander le Honor 8, qui va surement être mon prochain portable ou le Mate 9(mais quand même un peu beaucoup plus cher) " />" />