Google verkleint Play Store-app-updates met 50% of meer met nieuw algoritme

Google heeft verbeteringen aangebracht in zijn delta-compressie-algoritme waardoor Play Store-app-updates nu 50% kleiner worden ten opzichte van voorheen. In sommige gevallen worden updates nog kleiner. Daarnaast gaat de Play Store nu van tevoren tonen hoe groot een update is.

De reeks kleine aanpassingen zet Google uiteen op de Android developers blog. Het algoritme, genaamd bsdiff, werkt het beste met apps die uncompressed native libraries bevatten. Is dat niet het geval, dan zien ontwikkelaars slechts een verbetering van gemiddeld 5% kleinere updates. Als voorbeelden geeft Google een grote en een kleine Chrome-update. Het formaat van de grote update gaat van 22,8MB naar 12,9MB en de kleine van 15,3MB naar 3,6MB. Het bedrijf meldt dat de verbetering van de compressie een reactie is op de toename aan app-updates die via de Play Store gepubliceerd worden en de kostbaarheid van mobiele data.

Daarnaast gaat de Play Store duidelijker aangeven hoe groot de downloads zijn die gebruikers te wachten staan. Als een app niet geïnstalleerd is, dan wordt de grootte van de gehele app getoond. Is deze wel geïnstalleerd, dan wordt de grootte van de te downloaden update getoond. Aangezien het Play Store-algoritme zelf de updates samen kan stellen, hoeven gebruikers maar een enkele update te downloaden om bij de nieuwste versie te belanden, ongeacht hoe oud de versie is die ze op dat moment draaien. De aanpassing aan de weergave wordt gefaseerd ingevoerd en is op het moment van schrijven nog niet te zien in de Nederlandse Play Store.

Reacties (57)

Duurt het voor langzamere telefoons niet langer met het nieuwe algoritme om de update daadwerkelijk te installeren.
Als ik kijk naar mijn eigen updates dan duurt niet het downloaden het langst maar het installeren van een app. Dat lijkt mij met dit nieuwe algoritme alleen maar erger te worden omdat er nog meer gedecomprimeerd moet worden op de telefoon.

Ja het is kiezen tussen de twee, of minder datagebruik (en snellere download tijden, niet iedereen heeft beschikking tot snel internet) of langere installatie tijden (die in Android N al drastisch korter zijn geworden).

of je laat beide toe: standaard indien wifi, delta compressie indien 3G/4G

Waarom, één ding is zeker. Er zijn nog veel datalimieten. Internet is niet overal snel genoeg. Echter tijd is er altijd wat extra en zou ik dus als overall beeld eerder voor snellere downloads ( dus minder data ) gaan en de telefoons die tegenwoordig best snel zijn even langer werkt laten verrichten.

Ik denk dat het decompressen op de telefoon heel erg meevalt. Het zal het compressen zijn, wat op de servers van Google gebeurt, die de meeste CPU-power kost.

Ik ken het algoritme van Google niet, maar de naam doet vermoeden dat ze dus alleen de wijzigingen naar de telefoon versturen. De telefoon hoef het dus alleen maar even te unzippen en op de juiste plaats te zetten.

Ik denk dat het complexer is dan dat, je ziet namelijk ook vaak met pre en post scripts als je spreekt over een update (om je bestaande data cache geldig te houden (je app settings))

Voor de database van de app is de maker van de app zelf verantwoordelijk, dus dat gedeelte van de cache wordt waarschijnlijk niet aangeraakt.

Het gaat niet alleen om de persoon, of deze nou wel of niet een goede bundel heeft. Google verwerkt miljoenen al dan niet miljarden updates. Als je op alles zo'n 50% kan besparen op dataverkeer dan is dat echt massive...

En daarmee minder verbruik van brandstoffen om de datacentra van Google te laten draaien. Een stuk milieuvriendelijker.

Of je vertelt je telefoon dat deze alleen mag updaten als je aan een wifi netwerk gekoppeld bent. Dan heb je het hele probleem niet meer. Wel af en toe op een netwerk aanmelden.

Ik heb updates zelf helemaal uitgezet, want elke dag is er wel iets dat upgedate is, en dat is niet goed voor flash geheugen.
Dus nu bepaal ik zelf wanneer ik mijn apps installeer (1 keer per week op zondag)
Het voordeel is dat mijn adapter dan insteekt, want ik vind het echt vreemd dat google enkel "none,via wifi, via cellular" aanbied, ik vind dat er een extra checkbox moet staan "Only update when connected to power"

Echter in de praktijk zal je flash geheugen nooit zover slijten dat je er iets van merkt.

Vooral het laatste maakt deze stap van Google een goede, m.i.. Ik ben Android N aan het testdraaien sinds versie 3 en het installeren gaat zeer rap. Een kleiner te downloaden bestand als update, is enkel goed, vind ik.

Dat is leuk alleen zal 90% van de android telefoons nooit op Android N of hoger komen te draaien (in ieder geval niet in de komende 2 jaar).

Het probleem is er, maar je overdrijft wel héél erg flink.

Android Marshmallow is nu 9 maanden uit, en 13% van de devices draait daarop. Bijna 49% van de devices draait Lollipop of hoger, en die is nu pakweg 20 maanden uit.

Door te stellen dat de komende 2 jaar max 10% op Android Nougat komt te zitten is dus complete onzin.

bron? Lijkt me namelijk zeer sterk.

edit:
https://developer.android...oards/index.html#Platform

Je hebt gelijk, dat valt dan nog mee dacht dat het erger was.

edit 2:

Ah je hebt geen gelijk dat gaat alleen om devices die de google app store hebben bezocht in de laatste 7 dagen, niet bepaald representatief...

[Reactie gewijzigd door acst op 23 juli 2016 13:28]

Ah je hebt geen gelijk dat gaat alleen om devices die de google app store hebben bezocht in de laatste 7 dagen, niet bepaald representatief...

Geloof me maar dat t wel representatief is. Uiteindelijk draait het overigens ook om de mensen die de appstore gebruiken en apps updaten. Niet om mensen nog een telefoon met android 2.3.3 hebben liggen ok alleen te bellen.

Als je de data van elke week kunt terug vinden zal je zien dat het met elke Android versie een hele mooie stijgende lijn zit met (op dat moment) de nieuwste versie.

In een artikel die gaat over installatie bestanden vanuit de google play store lijken mij dat juist de meest relevante cijfers?
Android gebruikers die geen play store gebruiken zullen onder geen enkele omstandigheid namelijk iets merken van deze ontwikkeling.

[Reactie gewijzigd door lappro op 23 juli 2016 14:17]

Android Marshmallow is nu 9 maanden uit, en 13% van de devices draait daarop. Bijna 49% van de devices draait Lollipop of hoger, en die is nu pakweg 20 maanden uit.

Nog steeds verschrikkelijk slecht natuurlijk, 13% van de devices dat haalt een major iOS update binnen een dag.

Als Android developer is dit iets waar je behoorlijk last van hebt, je moet OS versies ondersteunen die jaren oud zijn in een industrie waar 1 jaar is al een eeuwigheid is.

Android N is leuk en aardig, maar het gaat zeker tot 2020 duren voordat je apps kan gaan ontwikkelen voor Android N en later. Google heeft echt een gigantisch zooitje van hun OS updates gemaakt

[Reactie gewijzigd door Aaargh! op 23 juli 2016 13:30]

Het is niet alleen iets waar Android developers last van hebben, maar ook gebruikers. Een developer zal geneigd zijn om nieuwe functies niet te gebruiken omdat hij/zij dan weer allemaal varianten voor verschillende OS-en moet ondersteunen (inclusief dure verificatieprojecten op alle OS versies).

Effectief betekent het dus dat je als gebruiker van een nieuw OS relatief weinig profijt er van hebt. Wat ook weer tot gevolg kan hebben dat de vervangingssnelheid van toestellen langer wordt (dus slecht voor de smartphone leveranciers en al hun toeleveranciers).

Hoogste tijd dus dat Google nu eens echt serieus iets gaat doen om de upgrades sneller uit te rollen. Als Apple relatief oude hardware blijft ondersteunen moet dat met Android toch ook kunnen?

Ben met je eens dat het update beleid van Google niet goed is.

Maar, je kunt het niet direct vergelijken met Apple. Android is een open OS, met enorm veel devices die het moet ondersteunen en veel fabrikanten die ze maken.

Apple bouwt hun eigen software en hardware. Hun hebben een veel meer gesloten, en simpelere omgeving.

Heb vandaag op de Huawei p8 de update naar 6.0 dus de percenten gaan nog hoger zijn
De p8 is een verkoopsucces geweest

Met de high end flagship phones valt dit wel mee.

Veel goedkope telefoons draaien ook op Android maar die hebben de laatste Android versie dan ook niet nodig.

Decomprimeren kost tegenwoordig niet veel tijd. Het installeren van een app of update duurt misschien soms lang, maar met het decomprimeren erbij zal je niet merken dat het echt langer duurt dan voorheen...

Dat hangt natuurlijk wel van het gekozen algoritme af. Inlezen van data dat met LZ4, LZF of Snappy is gecomprimeerd, is vanaf 'disk' inclusief decompressie vaak sneller dan wanneer het niet gecomprimeerd was.

Maar LZMA (o.a. in 7-zip gebruikt) en andere zwaardere algoritmes, geldt dat nog echt niet voor hoor. Die kunnen - zeker op zwakke processors - nog best lang duren, soms zelfs langer dan de winst in benodigde downloadtijd.

Overigens is er met een delta-bestand niet per se sprake van compressie. Dat bestaat vooral uit het weglaten van bytes die toch niet veranderd zijn.

Als je updaten op de achtergrond doet, hoef je er weinig van te merken als het iets langer doet.

Een verbetering zou nog zijn dat je kunt instellen alleen te updaten als die aan de wifi en aan de lader ligt in de nacht, heb je er zelf geen omkijken naar, en ook geen last van.

Mijn telefoon (Galaxy S7 Edge) voert altijd al zijn updates uit gedurende de nacht wanneer het aan de lader zit. Ik dacht dat dit normaal is maar nu lees ik aan de reacties hier op tweakers dat dat niet zo is?? Ik vind het noujuist logisch hoe mijn telefoon het in de nacht altijd doet (ik krijg ook geen update meldingen gedurende de dag en na de nacht sta ik op en zie ik dat x aantal apps geüpdate zijn).

Ik heb dezelfde telefoon, als die leeg is en je doet hem op de lader dan check die of er een update is. Ik heb verder nog niet echt gemerkt, dat die updates alleen doe wanneer die aan de lader ligt wel dat die vaak veel apps tegelijk geüpdate worden.

Ik merk net hetzelfde met mijn Nexus 6P.
Ik heb alle play market meldingen uitgezet, totaal geen relevante informatie, snachts aan de lader werkt hij bij, ik hoef daar geen melding van.

Volgensmij staat dit al ingesteld.
Want zodra ik mijn telefoon op de lader hang in de avond gaat Googleplay alles updaten .

Dat kun je al sinds android 2.x instellen geloof ik

Wat je suggesteert kan wel al een paar jaar maar met een kleine leap in logica.
Ga naar je WiFi settings en stel de optie " Keep Wi-Fi on during sleep" op "Only when plugged in" - en daarnaast in je play store settings "Only auto-update on wifi"

CPU is behoorlijk cheap in vergelijking met mobiele data & enterprise storage.

Dit is opgelost in Android Nougat waarbij ze JIT en AOT combineren, JIT (just in time) zorgt ervoor dat er nauwelijks iets geinstalleerd (gecompileerd) hoeft te worden en AOT (ahead of time) zal naarmate je de app langer gebruikt veelgebruikte delen "installeren" (compileren).

Alleen zal het marktaandeel van Android N en hoger de komende jaren nog marginaal zijn.

Verbeteringen in een compressie-algoritme moet niet altijd noodzakelijk een negatief effect hebben in het decompressie gedeelte. Ze spreken hier ook niet over het gebruik van de compressie waarmee gegevens van A naar B gestuurd worden, maar over het delta-compressie algoritme. Dus de code die kijkt naar "ontvanger heeft reeds versie 1.0 en we gaan naar 1.1, dus deze spullen hier zijn anders en hoe kan ik (gebruik makende van de reeds beschikbare info in versie 1.0) dit zo 'klein' mogelijk over brengen."
Het resultaat wordt nadien vaak gezipt oid.

Denk dat het om het kostenplaatje gaat. In het ene geval liggen de kosten (ook) bij Google (data traffic), in het andere geval meer bij jou (in tijd dan).

Niet significant, het echte rekenwerk zit ’m in het comprimeren. Het comprimeren van één app kan enkele uren duren, maar op de schaal van Google is dat de bandbreedtebesparing meer dan waard.

Zal toch wel meevallen? Encoden van video duurt zelfs op een stevige PC wel even, maar zo'n video is dan zonder problemen af te spelen op zo'n beetje iedere telefoon. Zal hier niet veel anders zijn lijkt me.

[Reactie gewijzigd door Anoniem: 382732 op 23 juli 2016 20:09]

Ik heb een redelijk idee welke compressie dit betreft, vanwege de beschrijving "werkt het beste met apps die uncompressed native libraries bevatten".

Delta-compressie is een techniek die updates comprimeert. Een update verandert een bestaande file, dus de uitdaging is om de nieuwe file als een zo klein mogelijk set van veranderingen te beschrijven.

In het geval van binaries is de file een verzameling van honderden of misschien wel duizenden functies. In de praktijk zie je dat bij een update 80-90% van de functies ongewijzigd is, bij een kleine update misschien wel 99%. Maar het probleem is; de volgorde van functies maakt op zich niet zoveel uit, en daarom zijn er veel buildtools waar die volgorde random is. Stel dat je eerst functies ABC in je executable had, en daarna ADB. Dan is de wijziging "C verwijderen, D toevoegen voor B". Natuurlijk is dit complexer om uit te vinden als je in plaats van 3 functies er 3000 hebt, maar de decompressie blijft relatief simpel. De compressor maakt nog steeds een stappenplan wat de decompressor moet uitvoeren.

De reden dat dit zo'n complex probleem is, is omdat de hoeveelheid mogelijk volgordes meer dan exponetieel toeneemt. Met 3 functies heb je 3! = 6 volgordes, met 4 zijn het er al 14, met 5 60, met 6 functies 360, etcetera. Met 80 functies heb je al meer volgordes dan dat er atomen in het heelal zijn, en dat is nog steeds een klein programma.

Als de compressor niet doorheeft dat een funcit ongewijzigd is, werkt de compressie nog steeds, maar minder efficient. Dan krijg je een stappenplan als "verwijder functie X, voeg functie X weer toe." Dat levert een onnodige grote update op.

Het verschil is dat google denkt dat je downloadvolume je geld kost, en dat jouw tijd gratis is

Plus die data kost Google ook geld. Dat willen ze natuurlijk ook besparen.

nee dat is marketing.
werkelijk bedoelen ze dat het hun (google) veel data bespaard. en dus kosten

Ik snap sowieso niet dat zoveel simpele apps tegenwoordig tientallen, zo niet honderden MB's aan opslagruimte vergen. Optimalisatie is volgens mij het laatste waar app-ontwikkelaars tegenwoordig nog aan denken. Het gemak van high-level-compilers komt volgens mij voorop.

Dit. Neem Facebook als voorbeeld. Waarom moet die app in hemelsnaam 127mb groot zijn?
De webversie doet hetzelfde, al dan niet beter.

Omdat enterprise software. Ik kan wel even een voorbeeltje noemen dat ik gezien heb in Amazon code:

Er moest een boolean (een waarde die true of false kan zijn) naar JSON omgezet worden (mooie code als resultaat ). Hiervoor werd een class geschreven. Vervolgens een andere boolean, gebruiken ze niet dezelfde class voor maar ze kopieren 'm. In totaal waren er dus 3 verschillende classes die exact dezelfde code bevatten. Zo heeft de Facebook app zoveel classes dat ze om het Android limiet van 50,000 heen moeten werken.

[Reactie gewijzigd door Wolfos op 25 juli 2016 16:40]

Dit is zeker handig naarmate de apps groter worden en de databundels niet mee groeien.

Het bedrijf meldt dat de verbetering van de compressie een reactie is op de toename aan app-updates die de via de Play Store gepubliceerd worden en de kostbaarheid van mobiele data.

En de kostbaarheid van de bandbreedte die ze zelf inkopen zal vast ook een rol gespeeld hebben verwacht ik?
Maar toch wel een zeer nuttige verbetering!

Misschien zie ik iets over het hoofd, maar de titel van het artikel spreekt over verkleinen van Google playstore updates met maximaal 50% en verderop staat dan dat een kleine update 15,3 naar 3,6 maar dat is toch meer dan die 50%?

Right you are. De formulering van Google was 'up to 50% or more', blijkt. Beetje rare formulering, maar goed. Het is fixed.

Ik vind het nog steeds raar dat standaard apps automatisch updaten en dat je per app dat uit moet zetten, oftewel wie kent er nou echt een goede app manager?

Je kan gewoon in de Play Store de standaard instelling aanpassen hoor

Play Store -> Instellingen -> Automatisch updaten van apps

Ik had liever een mogelijkheid gezien om selectief apps automatisch te laten updaten in plaats van alles-of-niets.

Kan ook. Via het hamburger menuutje bij een App pagina in de play store.

De grootte van updates vind ik niet echt een probleem. Ze kunnen er beter voor zorgen dat de frequentie van updates afneemt. Een maximum aantal updates per app per jaar (bv 2-3) lijkt me een mooie maatregel.

Dat soort vooruitgang levert veel kostenbesparing op - voor zowel google als de klant.