Google komt met serverside-update die hoog accuverbruik Pixel-telefoons verhelpt

Google zegt een probleem opgelost te hebben waardoor de accu's van 'bepaalde Android-smartphones' snel leegliepen. Het probleem deed zich vooral voor bij Pixel 6- en Pixel 7-smartphones. Een backendwijziging in de Google-app moet het probleem hebben opgelost.

Google bevestigt tegenover 9to5Google van de accuproblemen af te weten. Het bedrijf heeft een update uitgerold die het probleem 'onmiddellijk' op zou lossen. Volgens Google zijn er geen app- of systeemupdates nodig om het probleem te verhelpen, omdat het een update aan de backend van Google betrof.

Berichten over de problemen verschenen eind vorige week, meldde onder meer Engadget. De Pixel-telefoons van Google raakten bij veel gebruikers oververhit. Daarbij liep de accu uitzonderlijk snel leeg. In de instellingen was te zien dat de Google-app een hoog accuverbruik had. Bij sommige gebruikers werd de gebruikersduur van de accu hierdoor gehalveerd. Dat resulteerde in een schermtijd die daalde van zes naar drie uur, naast het opwarmen van de telefoon, zo is te lezen op Reddit en Google Help.

De problemen leken zich voor te doen na de Pixel-beveiligingsupdate van 12 mei en kwamen vooral voor bij gebruikers met een telefoon uit de Pixel 6- of Pixel 7-series, meldt 9to5Google. Omdat het probleem zich voordeed in de backend van de Google-app, had het geen zin om een oudere versie te installeren.

De Google Pixel 6 en Pixel 6 Pro

Reacties (59)

[Yellow]

Een soort gelijk probleem heeft zich in het verleden ook eens voorgedaan, maar dan met de Facebook en Facebook Messengers apps. Ik had toen een Samsung S6 die binnen ander half uur van 100 naar 0 procent ging. Dat was ook opgelost met een serverside-update:
nieuws: Serverupdate Facebook en Messenger veroorzaakte snel leeglopende accu

edit off-topic: Zie toevallig dat ik 6 jaar geleden heb gereageerd op het andere bericht:
Yellow in 'Serverupdate Facebook en Messenger veroorzaakte snel leeglopende accu'

[Reactie gewijzigd door Yellow op 22 juli 2024 15:38]

[Cerberus_tm]

Op mijn telefoon worden Goole Play Services e.d. automatisch uitgeschakeld/bevroren zodra het scherm uit gaat. Ze gaan automatisch aan wanneer een bepaalde applicatie ze echt nodig heeft en deze op de voorgrond draait (Tasker en Icebox gebruik ik voor deze automatisering). Echt een wereld van verlichting op mijn Pixel.

[Verwijderd]

Zou jij je automation willen delen? Klinkt interessant!

[Cerberus_tm]

Ken je Tasker? Daarmee kun je ervoor zorgen dat bepaalde handelingen uitgevoerd worden bij bepaalde omstandigheden. Icebox is een programma waarmee applicaties bevroren en weer ontdooid kunnen worden. Dus ik heb o.a. "Scherm gaat uit? → Play Services bevriezen". En ik heb een actie "Ontdooi Play Services en start applicatie X", in plaats van de normale manier om applicatie X te starten. Overigens kun je ook instellen dat dingen getriggerd worden doordat een bepaalde applicatie op de voorgrond is, maar dat werkt iets minder vloeiend.

Bij Icebox kun je ook instellen dat bepaalde applicaties sowieso bevriezen zodra het scherm uitgaat, tenzij ze een notificatie actief hebben. Etc.

[akooijman]

Ik heb een oudere MacBook Air. Als ik het ding dichtklap en vergeet chrome af te sluiten is de accu de volgende dag vrijwel leeg.
Sluit ik chrome af duurt dat zowat een week.

[Jeroen]

Nu ben ik wel benieuwd geworden wat er technisch gebeurde om dit te veroorzaken, en hoe dat nu is aangepast.

[CH4OS]

Ik vind het vooral opmerkelijk te noemen dat een serverside update problemen op een ("client") telefoon oplost. Ik weet dat Google een verschrikkelijke datahonger heeft, maar dit soort dingen zou gewoon überhaupt nooit mogen, wat mij betreft. Mogelijk hebben andere toestellen van andere fabrikanten hier ook last van, buiten deze twee van Google zelf.

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:38]

[Marve79]

Misschien een updatecheck die net iets te vaak gebeurde. Kan van alles zijn.

[thomasv]

Maar een update check zou geinstantieerd moeten worden vanuit de client, niet vanuit de server (mits we het over OTA updates hebben). Zoals hierboven aangegeven ben ook ik zeer benieuwd en vind ik het ook zeer opmerkelijk dat een server side issue een negatief effect oplevert op een client.

[TheVivaldi]

Nee hoor, pushen vanuit de server kan ook. Zie bijv. Microsoft die computers automatisch upgradet naar een nieuwere Windowsversie.

[84hannes]

Nee hoor, pushen vanuit de server kan ook. Zie bijv. Microsoft die computers automatisch upgradet naar een nieuwere Windowsversie.

Het lijkt me heel sterk dat de verbinding door de Windows Server wordt geïnitieerd, al is het maar omdat de meeste computers met Windows achter een NAT zitten. Ik ben ervan overtuigd dat zowel Windows als Android (als andere mainstream besturingssystemen) zelf aan de server vragen of er een update is. Waarschijnlijker is het dat het probleem welliswaar client-side opgelost had kunnen worden, maar server side sneller ging. Bijvoorbeeld omdat de server bij een vraag een antwoord geeft dat zoeits betekent als: "probeer het over 10ms weer eens". Een cliënt zou dat natuurlijk niet moeten doen, maar zorgen dat de server het niet eens vraagt is een snellere fix voor iedereen.

edit:
Ik geeft toe, dat een client de connectie initieert betekent niet dat de client ook de communicatie initieert. Lijkt me een semantische discussie, ik ben nog steeds van mening dat de client erg gevoelig is voor serverfouten.

[Reactie gewijzigd door 84hannes op 22 juli 2024 15:38]

[hiostu]

Een client kan een socket verbinding opbouwen en die in principe open laten. Een server kan dan gewoon berichten sturen wanneer het nodig is over die socketverbinding. Dit patroon wordt veel gebruikt, ook bijvoorbeeld door gateway producten zoals een Philips Hue. Die bouwen niet elke zoveel ms of seconden een verbinding op, maar houden deze gewoon open. Wanneer nodig kan een server dan over de actieve verbinding een bericht sturen.

[Raymond Deen]

Een socket verbinding is hier niet zo handig gezien het aantal clients en het aantal mogelijke sockets per server.

[Bolle117]

https://en.m.wikipedia.org/wiki/HTTP/2_Server_Push er bestaat iets als http2 server push. Dus het is mogelijk. Of hier zoiets ook aan de hand is, is een tweede

[Verwijderd]

Dit zou middels een firewall rule op je telefoon ook opgelost kunnen worden. Om push verbindingen te maken loopt via de browser vendors. Zal wel Google zijn in dit geval. Ik vind het zorgelijk dat een server een cliënt kan benadelen. Dit zou niet moeten kunnen met een goede policy.

[mjz2cool]

Ik denk dat het net zo werkt als push berichten, die komen ook vanaf de server, ook achter een NAT.

[84hannes]

Ik denk dat het net zo werkt als push berichten

Bij push-berichten legt de client een langdurige verbinding aan met de server waarop de server op het gewenste ogenblik een bericht kan terugsturen. Het initiatief ligt dan dus nog steeds bij de cliënt. Om voor updates zo'n verbinding te gebruiken klinkt niet zo zinnig, een paar uur vertraging speelt geen belang. Elke paar uur pollen zou dus mee dan genoeg zijn. Het is waarschijnlijker dat dit met messengers te maken heeft.

[Blokker_1999]

Zucht...

Neen, dit is geen push vanuit de server. De volgende keer de client komt vragen of er updates zijn gaat Microsoft nu de Win 10 22H2 versie aanbieden als je nu nog op 21H2 zit terwijl je daar voor heen expliciet op een knop moest klikken.

MS servers hebben geen optie om aan clients te zeggen dat ze nu moeten update, het process begint client-side.

[Aaargh!]

Maar een update check zou geinstantieerd moeten worden vanuit de client, niet vanuit de server

Sure, maar het kan zijn dat er een iets als een cache-expiry header verkeerd stond.

Een goed voorbeeld hiervan is het DNS systeem. Omdat je niet voor elke DNS lookup de authoritative DNS server wil raadplegen mogen tussenliggende DNS servers het antwoord cachen. Hoe lang dit is kan je instellen als onderdeel van je DNS records, maar meestal is het iets van 24h ofzo. Als je weet dat je de DNS gaat aanpassen zet je 'm een dag vantevoren op 5 minuten o.i.d. zodat clients niet te lang het oude IP gebruiken, na de switch zet je 'm weer op 24h.

Het kan zijn dat Google ook zoiets doet met b.v. update checks. "Voorlopig geen update geplanned, check over een week maar weer". Als ze 'm dan per ongeluk ipv op 7 dagen op 7 seconden zetten, dan gaat die telefoon steeds op updates checken en loopt de batterij zo leeg.

Ik vermoed dat je 't in die hoek moet zoeken.

[Dubbeldrank]

Precies! Als er een proces is dat aangesproken wordt en de telefoon weerhoudt in energiebesparingsstand te gaan, dan loopt je accu een stuk sneller leeg. Als voorbeeld dan.

[CodeCaster]

Dit kan zo eenvoudig zijn als een soort cron/Task Scheduler, waarbij de door de telefoon uit te voeren taken bij Google worden opgehaald. De server zegt: "je moet elk uur checken of je app-caches moet wissen", en door een bug werd dat: "je moet elke seconde checken of je app-caches moet wissen".

Dan updatet Google die "back-end" en is de bug verholpen.

[Reactie gewijzigd door CodeCaster op 22 juli 2024 15:38]

[CH4OS]

Maar dan nog, ik blijf het een beetje gek vinden dat zoiets opgehaald moet worden bij de server (als dit het issue was). Zoiets kan prima ook lokaal ingesteld worden, ik zie het voordeel van een server afhankelijkheid in deze niet echt.

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:38]

[CodeCaster]

Jij en ik allebei niet, maar het was maar een arbitrair voorbeeld en wij zijn Google niet. Ze zullen er vast hun redenen voor hebben.

[nst6ldr]

Ik heb zelf een Pixel 7 met PixelUI en GrapheneOS gebruikt, dat laatste scheelt me zo'n 20% accu aan het einde van de dag.

[dasiro]

da's omdat je mss geen google play services hebt draaien die constant bezig zijn. Dat heeft niet echt rechtstreeks iets met de google-app te maken

[bartje]

het zou zomaar kunnen dat de server een foutmelding terug gaf waardoor de telefoon iedere keer opnieuw probeerde de server te benaderen. foutmelding verholpen, probleem opgelost.

of een expirationtoken die de huidige tijd terug geeft ipv nu+ 1 uur.

Ik geef toe, het is opvallend, echter is het niet ondenkbaar.

[e.dewaal]

Het zou kunnen dat de telefoon actief blijft terwijl het op antwoord wacht. Als er geen antwoord komt, of het antwoord komt pas met vertraging zou dit voor extra energieverbruik kunnen zorgen. Door sneller antwoord te geven zou een telefoon sneller terug in slaapstand kunnen gaan.

Hoe dan ook, het blijft speculeren zolang Google niet meer informatie geeft.

[controvi]

Is niet heel moeilijk te begrijpen.
Los van het feit dat het letterlijk van alles kan zijn, kan het prima een wijziging zijn die een connectie niet sloot wanneer er een ping gestuurd werd.

Als de app om een reactie vraagd maar de backend geeft een verkeerde reactie zou het zo maar kunnen dat een app dan in een soort loop komt.

Waar iedereen voor moet waken is direct weer Google een nekschot te geven want ze zullen weer wat gedaan hebben om de consumenten te benadelen.
Daar wordt ik een beetje moe van.

Ook bij google kunnen fouten gemaakt worden en/of bugs ontstaan.
Laten we dat niet vergeten ipv. (en ik zeg niet dat jij dat direct doet) dat een foutje niet direct een wereldramp is.

[ikt]

Er zijn prima redenen te bedenken waarom een client zich zo gedraagt.

Als er bijvoorbeeld een connectie naar Google is, kan de client periodiek iets sturen. Maar als bijvoorbeeld de client een retransmissie-ding heeft, en de verbinding half half wegvalt op zo'n manier dat de client niet weet dat de server totaal niet responsief is, kan de client het retransmissie constant doen. Denk aan een server die deels responsief is, waardoor de client aanneemt dat die door kan gaan met retransmissies. Zodra de server weer berichten goed aanneemt/antwoordt kan de client weer verder met de normale programmering.

Een andere optie is dat de client een bericht stuurt en een response terug krijgt met de volgende keer dat de client een bericht mag sturen. Als de response foute data heeft, kan de client heel vaak het bericht gaan sturen. Zodra de server het oplost door een antwoord terug te sturen met een langere bericht-tijd, doet alles het weer normaal.

"Nooit mogen" is makkelijk zeggen, maar er zijn gewoon veel edge cases in communicatie-implementaties waar dit voor kan komen.

[Cergorach]

Ik ook, maar als men het heeft over een puur serverside update/fix en geen app/OS update gaan er bij mij allerlei alarmpjes af! Helemaal als het om Google gaat...

[dasiro]

[alu-hoedje]
als er teveel data-collection gevraagd wordt, bvb full app usage inventory ipv delta app usage inventory waardoor je toestel plots veel langer bezig is
[/alu-hoedje]

[CAPSLOCK2000]

Ik vind het vooral opmerkelijk dat een backend probleem beperkt is tot bepaalde modellen (de Pixel 6- of Pixel 7-series). Als alle telefoons met een bepaalde versie van Android of een bepaalde chip er last van hadden zou ik dat al veel logischer vinden. Het klinkt nu alsof die backend z'n gedrag aanpast aan het model telefoon dat je hebt.

Het roept ook de vraag op of het iets zegt dat het specifiek bij Google's eigen telefoons is en of telefoons van andere fabrikanten ook extra aandacht krijgen, of dat Google daar misschien geen extra moeite voor doet.

Sterker nog, als je heel duister denkt zou je spelletjes kunnen gaan spelen met dit soort instellingen om de telefoons van concurrenten te benadelen door hun batterij te verspillen. Maar goed, Google heeft strakke controle over het hele OS, als ze zo iets zouden willen hebben ze nog 100 andere manieren om het te doen.

[Joseph]

Het zou kunnen dat het iets met GCM (Google Cloud Messaging) te maken heeft. De reden waarom(bijvoorbeeld) Google en Apple push-berichten kunnen sturen is omdat er een verbinding is die 'open gehouden' wordt, waarop alle berichten worden geconsolideerd.

Hierin hebben de grote spelers een voordeel: bij NAT worden 'stales' vaak na een vaste treshold verbroken aan de routerkant. Met een schaal die deze bedrijven hebben kunnen telecomproviders uitzonderingen inbouwen in het infrastructuur om de lifetime van deze verbindingen flink op te rekken, waardoor minder reconnects nodig zijn.

Dit is een versimpelde versie van wat er onder de motorkap gebeurt, maar ik zoek het in deze hoek.

[satya]

Dat is bij de Pixel 6 & 7 goed voor te stellen omdat die de Tensor chip hebben en veel gebruik maken van extra AI implementaties die ook server side componenten in zich hebben.

[Zer0]

Ik vind het vooral opmerkelijk dat een backend probleem beperkt is tot bepaalde modellen (de Pixel 6- of Pixel 7-series).

Ik niet, die telefoons krijgen van Google extra features die niet terug te vinden zijn in andere telefoons, dus wellicht zat de bug in één van die features.

[Xypod13]

Nooit gedacht te horen dat een update aan hun servers een probleem zou oplossen dat het batterijverbruik van een telefoon aanpast. Zou inderdaad wel willen weten wat dat dan was, zoiets maak je bijna nooit mee.

[dezejongeman]

In het artikel word genoemd dat het gaat om de backend van de app. Ik lees niets over een online server backend. Misschien bedoelen ze alle non gui functies van de app. Dit suggereert echter ook dat het mogelijk ook andere telefoons trof. Of het zit dicht tegen de cpu schedular aan welke bij d deze pixels google's eigen SOC betrof. Hoe dan ook netjes dat het erkend wordt en waarschijnlijk al opgelost is.whoops in de titel

[Reactie gewijzigd door dezejongeman op 22 juli 2024 15:38]

[Get!em]

Valt wel mee hoor, zo speciaal is het allemaal niet.

Met wat cache expiry headers en refresh triggers kun je een website (serverside dus) ook vrij heavy maken. Evenals het tegenovergestelde, je kunt je website ook heel licht maken (wat meestal de bedoeling is van cache..). En dat allemaal met wat html + js en serverside headers.

[Metal spoon]

Oh nice, nu was mij sowieso niet opgevallen dat mijn pixel 7 pro extra aan het verbruiken was maar elke verbetering is welkom natuurlijk!

Mijne staat praktisch toch de hele dag op de pixel stand, dus veel last had ik sowieso niet

[McLambo]

Google app disabled op mijn toestel

[Netburst]

Hier ook, maar accugebruik is nog best flink. Benieuwd of de update ook iets doet voor grapheneos...

[nst6ldr]

Nee, gaat niks doen voor GrapheneOS. Als je nu last hebt van hoog verbruik dan komt dat omdat je een app gebruikt met CPU intensieve taken.

[FGras]

Download de DuckDuckGo app en zet de tracking blocker aan op je Android telefoon. Je zult versteld staan hoe vaak apps al je gegevens, contact informatie en locatie opvragen.

[nst6ldr]

Als je geen trackers wilt op je Pixel dan moet je echt aan GrapheneOS gaan. Installeren kost je hooguit een kwartier en doe je gewoon vanuit de browser. Is echt niet ingewikkeld. Daarvoor krijg je een veel veiliger toestel terug

[Reactie gewijzigd door nst6ldr op 22 juli 2024 15:38]

[Remcom00]

Is dat tegenwoordig een beetje werkbaar met Netflix, bankieren en andere apps die bepaalde beveiliging gebruiken? In het verleden altijd m'n toestel geroot/geflashed maar werd me teveel gedoe, was vaak wel te fixen met Magisk maar die word niet meer ontwikkeld naar mijn weten. Ben verder wel heel tevreden met stock android op mijn Pixel 7.

[nst6ldr]

Pixel 7 draait geen stock Android, de achtergrond daarvan heb ik in m'n review staan - maar ook de antwoorden op de andere vragen die je stelt

[Remcom00]

Zal even kijken, thanks!

[henkbert]

Goed om dit te lezen, de laatste tijd viel het me op dat de accu erg snel leeg was en dat de Pixel erg warm werd. Ik dacht zelf dat het kwam doordat het buiten wat warmer begint te worden, mooi dat ze het verholpen hebben

[wica]

En wat is de klimaat schade van deze bug?

[geerttttt]

Wat is de klimaatschade van dit nutteloze bericht?

[wica]

Als een bug er voor zorgt, dat een accu sneller leeg raakt. Is er onnodig energie verlies.
Bedenk om hoeveel devices het gaat en je heb een behoorlijk verlies en daarmee impact op het klimaat.

[geerttttt]

Je kunt je auto ook chiptunen, daardoor wordt o.a. de brandstof inspuiting verfijnd. Daar wordt je auto dus zuiniger van qua benzineverbruik. Oftewel dat dit er standaard niet in zit is ook een impact op het klimaat. Zo kun je bezig blijven.

[geerttttt]

Maar laten we het eens berekenen:
Deze bug heeft bestaan vanaf 6 a 7 mei. Dus zo'n 9/10 dagen. Laten we zeggen dat misschien gebruikers gemiddeld 0,5x vaker hun telefoon moesten opladen hierdoor per dag.

Er zijn naar schatting een paar miljoen pixels in omloop. Laten we zeggen 3,5m. Een gemiddelde laadsessie kost ongeveer 15 watt-uur.

Dus, 15*(3500000*0,5)*10=262,5 miljoen watt uur, oftewel 262.500 kWh. *0,37kg co2 = 97.125 kg co2.

Klinkt veel wellicht, maar alleen Nederland genereert in 1 jaar aan stroomverbruik al 141,5 miljard kg CO2. Laat staan het wereldwijde getal hiervoor.

Kort gezegd, het stelt nauwelijks wat voor. Dus maak je niet druk.

[NLxDoDge]

Ik heb zelf een 6a maar ik doe twee dagen ongeveer op een volledige lading. Ik heb wel aardig wat onzinnige features uit gezet. Misschien dat ik precies die feature uit had gezet die veel stroom bespaarde?

[crazyboy01]

Ik heb vrijwel niks uitgezet, gebruik mijn Pixel (7) meerdere uren per dag maar zit aan het eind van de dag met best intensief gebruik en video's kijken nog rond de 60%. Merk er dus ook niks van.