Nexus-apparaten scoren niet beter op accutest onder Android L

De Nexus 5 en Nexus 7 2013 scoren op de accutest van Tweakers, waarbij het apparaat de hele tijd moet browsen, niet beter of zelfs een stuk minder onder Android L dan onder de huidige versie KitKat. Dat blijkt uit herhaalde tests van Tweakers.

De herhaalde tests tonen dat de Nexus 5 resultaten haalt die ongeveer gelijk zijn onder Android L, terwijl de Nexus 7 het een stuk minder lang volhoudt. De resultaten van Tweakers staan haaks op de scores die Ars Technica deze week publiceerde. De site heeft een verlenging van de accuduur van 36 procent gemeten.

Bij de resultaten van Tweakers, een gemiddelde over meerdere tests, kwam de Nexus 5 een kleine 3 procent hoger uit, een score die nog in de foutmarge zit: daaraan is af te lezen dat de accuduur in elk geval ongeveer gelijk is. De accuduur van de Nexus 7 kwam zo'n 8 procent lager uit, op zes uur en twintig minuten.

Bij de accutest van Tweakers zijn de apparaten verbonden met altijd hetzelfde wifi-netwerk en liggen ze steevast op dezelfde plek. Bovendien is het scherm afgesteld op 250 nits en is de telefoon bovendien zo goed als schoon: na een factory reset stellen we alleen een Google-testaccount in. In opzet zijn de tests van Tweakers en Ars Technica zo goed als hetzelfde.

De tests van zowel Tweakers als Ars Technica meten niet het effect van Project Volta, waarmee Google de accuduur wil verlengen. Volta is erop gericht om het accuverbruik terug te dringen als de gebruiker de telefoon juist niet gebruikt. Ook de switch van Dalvik naar ART als virtuele machine kan geen invloed hebben: Chrome is geschreven in C++ en maakt dus geen gebruik van een virtuele machine.

Het is onbekend hoe Ars Technica een zoveel hogere score haalde, hoewel de auteur in het stuk zegt dat hij het heeft getest op een toestel dat hij dagelijks gebruikt; dat zou ervoor kunnen zorgen dat de omstandigheden waarin hij Android L heeft getest fors afwijken van die van Android 4.4. In een reactie op Google+ geeft hij geen verklaring voor het verschil. Deze tests geven geen indicatie van hoe de accuduur in Android L zal zijn: het gaat slechts nog om een Developer Preview en belicht bovendien maar een aspect van de accuduur, namelijk webbrowsen.

Reacties (114)

Ik vind dit geen eerlijke test. Laatst een tweet gezien over deze test en dat chrome c++ is en dus art daar geen rol op heeft. En dan ga je juist een test uitvoeren op een systeem dat er geen invloed op heeft?

Test dan fatsoenlijk gebruik ( bellen, appen etc )

Klopt helemaal ik merk zelf wel degelijk verschil al bij normaal gerbuik zonder te testen ik doe nu al een week met een nexus 7 normaal was het iets korter.

Test dan fatsoenlijk gebruik ( bellen, appen etc )

Dat is best handig aangezien de resultaten wereldwijd nog verder gaan verschillen omdat er van verschillende netwerken/frequenties gebruik wordt gemaakt, de afstand tot de dichtsbijzijnde mast verschilt, bepaalde apps/games door gebruiker A of B beter/sneller/anders worden bediend etc. etc. etc.

Neemt niet weg dat er dat in ieder geval zeer gunstige alsmede zeer ongunstige resultaten worden gepubliceerd zodat iedereen weet wat men kan verwachten.

idd, de verbetering zit ook in de standby tijd door de manier waarop met meldingen en roaming word omgegaan. Via een wifi netwerk merk je daar niets van, al helemaal niet als het toestel op een plek ligt met het scherm aan. Het scherm verbruikt dan zo veel energie dat de winst in standby tijd niet meetbaar is.

Als ik de nieuwsberichten rond de accuduur van Android L juist interpreteer, dan begrijp ik dat vooral de winst te merken moet zijn bij het gebruik van bijvoorbeeld pushberichten (door Project Volta; http://www.allaboutphones...rijen-met-36-procent.html) en de (zwaardere) apps (door ART). Dan klinkt het logisch dat bij een kale installatie er geen tot weinig verschil merkbaar is, toch?

Inderdaad, echter, uit deze test blijkt dat bij hetzelfde (zware) gebruik, in dit geval browsen, de accuduur in sommige gevallen achteruit gaat. Dus dat zou kunnen betekenen dat bij bepaald zwaar gebruik, waar de telefoon weinig op stand by staat de accuduur dus ook achteruit kan gaan. Als de theorie opgaat dat je vooral winst kan halen uit pushberichten en stand by, dan zou de accuduur dus niet moeten veranderen bij zwaar gebruik. En dat lijkt wel het geval te zijn. En dat mag best wel genoemd worden.

Daar heb je een punt, maar voor zover ik weet is Chrome juist net weer geen ART-compatible app. Ik vind 't in ieder geval een voorbarig nieuwsbericht voor een developer-preview waar ongetwijfeld nog e.e.a. aan versleuteld aan gaat worden.

Misschien mag de titel wat minder stellig zijn, maar er staat gewoon in de review onderaan:

Deze tests geven geen indicatie van hoe de accuduur in Android L zal zijn: het gaat slechts nog om een Developer Preview en belicht bovendien maar een aspect van de accuduur, namelijk webbrowsen.

Dus er kan zeker nog aan gesleuteld worden zodat de definitieve versie anders is. Maar op DIT moment met de huidige Developer Preview geeft de review wel de stand van zaken weer op een specifiek vlak. Alleen mag dat misschien wel wat duidelijker naar voren komen.

Inderdaad, ik ging er ook vanuit dat het alleen invloed heeft op de stand-by tijd van het apparaat, omdat hij niet elke seconde een dataverbinding op gaat zetten.

Het is natuurlijk wel zo dat Android L nog niet af is. Het is slechts een developer preview zodat developers gewend raken aan de framework, API's e.d.
Ik denk dat er nu pas begonnen wordt aan optimalisaties e.d.

@Tweakers:
Was jullie toestel bij KitKat op ART of op Dalvik? Bij Ars Technica hadden ze Dalvik op Kitkat en ART op Android L. Dat kan het verschil verklaren.
Ik heb op mijn SGS3 onder KitKat ook het verschil gezien tussen ART en Dalvik. Met ART haal ik gemiddeld gezien 20% betere batterij duur. En onder Android L moet ART nog meer geoptimaliseerd zijn heb ik begrepen.

Was jullie toestel bij KitKat op ART of op Dalvik?

Dalvik. Maar Chrome is sowieso C++, dus dat maakt niet uit.

[Reactie gewijzigd door arnoudwokke op 4 juli 2014 09:37]

Hoewel Chrome hoofdzakelijk C++ is, draait je Android-telefoon weldegelijk een hoop andere code, zelfs tijdens een browsertest. Vooral het verschil in garbage collection zou uit moeten maken, lijkt me.

[Reactie gewijzigd door DCK op 4 juli 2014 10:32]

...Dus gezien ze KitKat in Dalvik draaien en L in ART, zou dat een voordele voor ART moeten zijn. Dat we hier dus niet zien.

Waarschijnlijk ja, hoewel het ook nog zo kan zijn dat Dalviks simpelere GC juist in het voordeel is als je hoofdzakelijk unmanaged code draait. De gevolgen van garbage collection zijn heel moeilijk voorspelbaar.

Ik probeerde alleen te zeggen dat Arnouds voorstelling van de zaken iets te simpel was.

maarja, draaide beide toestellen wel de exact zelfde versie van Chrome, want bij L kan ik me voorstellen datie een testversie daarvoor draait aangezien Chrome ook specifieke android targets heeft (ofwel Android 3 is iets anders dan 4)..

Nee het is juist een heel nuttig artikel. Want er ging een nieuwsbericht de hele wereld over met de claim dat Android L voor een langere accuduur zou zorgen. Het testwerk van Tweakers spreekt dit tegen. En dat testwerk wordt grondig uitgevoerd.

Grondigheid en representatief testen zijn echter 2 hele verschillende testen, hier worden er voor de reproduceerbaarheid dingen geforceerd/uitgesloten waarin waarschijnlijk nou juist de optimalisaties zitten. In de apparaten zijn belangrijke stroomverbruikers nou eenmaal het scherm en daarnaast vooral de draadloze communicatie.

Het scherm word niet op de default automatische instellingen gelaten maar bevroren op een vaste intensiteit, terwijl daar misschien best optimalisaties mogelijk zijn die het gebruik van de apparaten niet benadellen.

Daarnaast word met name voor de nexus 5 het hele mobiele netwerk gebeuren zoveel mogelijk uitgesloten door alleen op wifi te blijven en ook continu te browsen. Erg leuk voor reproduceerbaarheid, maar totaal niet representatief voor normaal gebruik. Een mobiel is vaak op reis en zit regelmatig ook in standbye, waarin hij nu dus nooit komt, daar is nou juist precies de meeste winst in te behalen.

Ik begrijp ook juist uit andere artikellen dat daar slimmer mee om is gegaan, wanneer slaapt hij en wanneer word hij door processen wakker gemaakt, dit word veel efficienter geregeld en centraler aangepakt ook ten opzichte van mobiele communcatie. Door continu actief te blijven word dit geheel buiten beschouwing gelaten, terwijl dit juist heel erg representatief is voor dagelijks gebruik. Je telefoon staat bij het gros van de mensen toch wel meer in standbye dan actief in gebruik. En juist al die achtergrondprocessen die dan willen updaten is funest voor je accugebruik.

Een ander belangrijk aspect is dat de meeste mensen hun toestel vol heeft met social media apps en mail apps en andere apps die vaak internet gebruiken op de achtergrond. Vrijwel niemand gebruikt een hele kale android en installeeert geen enkele app en zit 24/7 alleen maar te browsen.

Deze test is vooral zinnig om apparaten met dezelfde software maar andere hardware onderling te vergelijken in accuduur, maar minder geschikt om iets te zeggen over accuduur verbetering in dagelijks gebruik.

Een ander belangrijk aspect is dat de meeste mensen hun toestel vol heeft met social media apps en mail apps en andere apps die vaak internet gebruiken op de achtergrond. Vrijwel niemand gebruikt een hele kale android en installeeert geen enkele app en zit 24/7 alleen maar te browsen.

Denk inderdaad dat daar het grote verschil zit in de testmethodes. Als Ars Technica het toestel niet gewiped heeft maar getest met een representatieve set aan applicaties, terwijl Tweakers een compleet kaal systeem zonder achtergrondtaken heeft gebruikt, dan snap ik best waarom de Ars test veel meer verbetering laat zien. Er valt natuurlijk veruit het meeste te besparen door taken die telkens de CPU en radio's wakker maken, en wat ik er van begrepen heb is dat precies wat Volta doet (batchen van dit soort voorheen veel frequentere operaties enzo).

Welke van de 2 testmethodes 'beter' is moet iedereen maar zelf beslissen, persoonlijk ben ik altijd wel een fan van realistische testscenario's, ook als dat ten koste van enige reproduceerbaarheid gaat.

Wat je aanhaalt is idd de reden waarom de Tweaker test "incorrect" is. Wat men puur doet is, de basis hardware in zo goed als idle situatie vergelijken.

De grote energie eter in idle, is juist de applicaties dat de toestellen verhinderen om idle te gaan of de boel om de x minuten activeren.

Stel dat een persoon weChat of Whatsup actief heeft. Dit zal letterlijk de boel forceren om de x tijd terug actief te worden. In de software van de Sony Android versies, ziet een leuke optie in genaamd "Stamina". Als je de Stamina mode activeert, kunnen enkel de applicaties dat je toelaat, het toestel uit standby halen. In Android L hebben ze nu gelijkaardige spullen ingestoken. Als je een kaal toestel test, dan heeft deze "Stamina" equivalent, totaal geen nut, want er is ( zo goed als? ) niets dat de boel uit slaap haalt.

Maar de echte energie verbetering komt niet van dit alleen, nee ... ART is de leuke beestje dat de echte reden is, dat veel mensen een energie verbetering zien. En dat is ook dezelfde reden waarom de resultaten zo "verschillende" zijn tussen de mensen / toestellen. De ene heeft een massieve verbetering, de andere heeft nauwelijks een verbetering. Wat het op neer komt, is dat die verbetering vooral onmerkbaar is, door de "standby" tijd te vergroten.

Wanner een "oude" toestel met Dalvik een applicatie "opstart" voor een routine check van ... zijn er berichten toegekomen in WeChat of what dan ook. Dan eet het meer resources, want gans de Dalvik interpretor or hoe men het wilt noemen dient op te starten, het moet de code van de applicatie omvormen naar machine code, en dan doet de applicatie zijn echte taak. Bij Art word gans die stap overgeslagen omdat er al een gecompilde versie op het toestel staat.

Het leuke eraan is, dat de resources dat nodig zijn om de x minuten sporadische te checken veel lager zitten. Waardoor het systeem automatische: a) sneller terug in slaap toestand kan gaan, b) minder cores/resources zal activeren voor de startup van de applicatie check iedere x minuten, c) wifi of andere communicatie dat mogelijk in slaap toestand stonden worden terug geactiveerd ( heb je ook actieve software voor nodig ).

En dat is de echte reden waarom mensen een groter accu autonomie zien. En ook de reden waarom de Tweakers test, eigenlijk een incorrecte test is. Het is geen slechte test, want het toont aan dat de software het toestel zonder applicaties, niet magische betere levensduur geeft. Maar NIEMAND koopt een toestel om het te gebruiken zonder een hoop actieve ( vooral sociale ) app's...

En ook ... de wifi constant actie houden is een major nono... Iedere slimme persoon zet zijn wifi zodat het automatische in slaaptoestand gaat en enkel activeert voor de sporadische checks. Idem met de andere verbindingen uit te zetten. Wie zet er nu zijn bel functie uit? Niemand ...

Als men bij tweakers een goede test wilt doen, had men beter 2 toestellen gebruikt, en de ene in de basis configuratie, en de andere vol met de normale social apps dat mensen installeren. En daar zal je ook het verschil zien.

Was het niet zo dat android zelf niet zo zeer zuiniger werd maar dat de telefoon zuinig werd door de verbeterde API's. Van wat ik heb meegekregen van het stukje dat ik keek van de google I/O persconferentie zou de telefoon in slaapstand bijvoorbeeld minder vaak uit slaapstand ontwaken om op push berichten te controleren maar echt alleen ontwaken als er een bericht gepusht wordt.

http://youtu.be/wtLJPvx7-ys?t=41m58s

Edit: Link toegevoegd met het stukje uit de I/O keynote.

[Reactie gewijzigd door mark met een k op 4 juli 2014 09:39]

Ik vind het dan ook wel een erg simplistische test en een erg boute uitspraak na een test die niks met real life gebruik te maken heeft. Zoals je al aangeeft wordt er nu totaal geen gebruik gemaakt van de optimalisaties in Android L, maar wordt er een eenvoudige en goedkope test losgelaten en daaruit geconcludeerd dat er geen verbetering is.

Dat is alsof je een auto op een rollenbank zet met een stoeptegel op het gaspedaal, om iets te zeggen over het energieverbruik. Het is "een" manier van testen, super eenvoudig en voor alle auto's gelijk, maar is het een realistisch verbruik? Neuh...

Tja, met auto's vind ik ook dat je het verbruik moet testen op de rijstijl van de gebruiker, niet aan de hand van een rijstijl die zo optimaal mogelijk is voor het gebruik. Als de gebruiker niet is "geoptimaliseerd" zal hij ook geen winst ondervinden.

Beetje off topic, maar dat klopt inderdaad. Wat dat betreft valt het me ook op dat mensen altijd maar roepen dat het opgegeven verbruik veel te optimistisch is, maar met mijn 13 jaar oude zafira rij ik zuiniger dan opgegeven in de specs als ik een beetje mijn best doe. Dan tuffel ik echter met 100 door het land, ga ik met 130 met het verkeer mee dan verbruikt hij veel meer (alhoewel me de laatste jaren opvalt dat er steeds meer mensen lijken te zijn die lak hebben aan het idee "maximum snelheid = minimum snelheid" en er ook achter lijken te zijn dat dat vooral veel meer brandstof kost voor nauwelijks tijdwinst).

project volta: https://www.youtube.com/watch?v=KzSKIpJepUw

Description:
No one likes battery-draining apps. We've analyzed power use by the platform and apps and want to share what we've found in this talk. We will go over best power practices, and familiarize you with some tools for measuring power consumption. We'll also describe a couple APIs that make it easy for you to write applications that drain less battery. Join us in helping improve battery life for our users.

Precies, 'herhaaldelijk browsen' heeft hier niets mee te maken natuurlijk

Het testwerk van Tweakers spreekt dit tegen. En dat testwerk wordt grondig uitgevoerd.

Zegt wie ? No offence maar Tweakers is allesbehalve nog zo onfeilbaar als het op technologie aankomt, er gaat geen week voorbij dat ik nieuwsartikelen zie passeren waar ik als techneut toch vragen bij stel. Het is een echte Persgroep productie geworden.

Een ding dat mij per direct op viel is dat er melding werd gemaakt dat ze o.a. Javascript gebruiken om het scrollen te simuleren. Ik ken die code niet maar het zou niet de eerste keer zijn dat ik een stukje JS de battery zie drainen. Bestaat zelf een studie over.

En de websites waar je zoiets op test kan idd een van de vele variabelen zijn de score beïnvloed. Als je een website bezoekt die hun JS niet optimaliseert voor mobile gebruik heb je het al vlaggen.

Weet je het kan dat die cijfers van Arstechnica niet kloppen (al is het niet de enige die een merkbare verbetering ziet) maar iets zegt dat men geen project opstart (zelf met veel fanfare er rond) om uiteindelijk minder dan 10% verbetering te zien.

[Reactie gewijzigd door simplicidad op 4 juli 2014 09:46]

Wij vinden dat we grondig genoeg te werk gaan, zoals ook wordt beschreven op http://tweakers.net/info/testmethodiek/smartphones. Geen idee wat je precies bedoelt met je Persgroep-opmerking, maar als je vindt dat we zaken beter kunnen/moeten doen, dan horen we dat graag uiteraard.

Verder stel je correct dat je onze code niet kent die wij gebruiken om het scrollen te simuleren en haal je terecht aan dat er veel variabelen zijn die de score kunnen beïnvloeden. Ik heb genoeg vertrouwen in onze javascript-goeroes om die code te vertrouwen en om te zorgen dat we de variabelen die jij aanhaalt elimineren, maken we gebruik van statische kopiën van websites die we lokaal op onze server hebben staan.

Zoals elders terecht wordt opgemerkt is dit ook maar een meting en kunnen er vele zaken invloed hebben op het accuverbruik. Wij vonden deze metingen in ieder geval relevant genoeg om nu te delen.

Als je een erg kritisch publiek tevreden kunt stellen heb je goed werk geleverd.
Ik ben juist blij dat dit tweakers is. Als tweakers iets claimt zal het door bepaalde mensen grondig bekeken worden en bediscussieerd. En het is dan ook zo dan als er iets niets zou kloppen de test opnieuw uitgevoerd wordt met deze nieuwe kennis.

Ja, het is vrij grondig, maar de titel is misleidend. Het zou eerder iets zoals 'Nexus-apparaten scoren niet beter op continuous browsing test onder Android L' .
Ben het wel met je eens dat het een relevante test is; alleen de L update en 'Project Volta' zijn niet toegespitst op screen on continuous browsing, maar op Idle modes en efficiëntere API's

Ik denk dat dat artikel de battery save mode gebruikt heeft die in de Android L zit. Daarmee wordt wel veel meer accu tijd gehaald maar gaat natuurlijk de perfromance etc wel mee naar beneden.

Android L wel ja, Android L Developer Preview niet. Dit is puur voor developers om alvast apps met nieuwe API's en Material Design te kunnen testen zodat bij de release van L meteen de vruchten worden geplukt. Zoals ook Project Butter en Svelte bij introductie nog in de kinderschoenen stonden en bij full release pas klaar was, zo gaat ook Project Volta pas bij de final release echt laten zien wat het kan. Als elke developer nu al de juiste intents aanspreekt en zijn apps test op de huidige beta versie van ART zien we in de herfst waarschijnlijk wel een verschil. Ik kan me echter niet voorstellen dat de verschillen baanbrekend zijn. Hooguit een uur of anderhalf uur extra op een dag. Dat zou al mooi meegenomen zijn, maar iedereen lijkt te verwachten dat we nu ineens wel een week zouden kunnen doen op een lading.

tja, is maar de vraag of de door tweakers uitgevoerde test wel grondiger is.. Met de test zoals tweakers heeft uitgevoerd kan het misschien deze resultaten hebben, maar met dagelijks gebruik kan het best zijn dat het ineens compleet andere resultaten oplevert..
Zomaar zeggen dat tweakers DE autoriteit is als het gaat om tests gaat mij toch echt veel VEEL te ver... Beter is gewoon verschillende tests naast elkaar te leggen, en als bv bij alle andere tests blijkt dat het langer mee gaat, dan geloof ik eerder die andere tests dan die van tweakers, maar is het 50/50 dan weet ik het nog niet, lol...

Edit: En zoals ik nu begrijp is bij tweakers alleen maar met browsen getest.. pffff.. sorry, maar dat is dus echt een pruttest, wie zit er nou de hele tijd te browsen? veel mensen gebruiken uberhaupt voor veel dingen een losse app ipv de website..
Dus nu geloof ik al eerder dat DEZE tweakertest gewoon onzin is en niets zegt over de werkelijke accuduur bij gebruik van L..

[Reactie gewijzigd door SuperDre op 4 juli 2014 10:31]

Wat ik ook wel zou willen weten of er een verschil was in dataverbruik. Stel dat de browser sneller was on Android L dan is het ook logisch dat je meer accuverbruik hebt als je continu gaat browsen.

In mijn ogen prima journalistiek, er werden scores door Ars Technica gepubliceerd die doen vermoeden dat de accuduur een stuk hoger zou liggen op Android L (beta) dan op KitKat en in plaats van dit klakkeloos over te nemen heeft Tweakers zijn eigen test gebruikt om te controleren of dit inderdaad klopt... niks mis mee. Of dit nu een beta is, is daarbij niet relevant men heeft enkel de waarheid van het bericht op Ars Technica proberen te achterhalen.

Je ziet naar mijn mening het belangrijkste element van een vergelijking over het hoofd. Het punt van meerdere mensen hierboven, waar ik me volledig bij aansluit, is dat je de accuduur gaat testen van twee Android versies en die uitkomsten gaat vergelijken met een resultaten van andere onderzoekers. Punt is dat je alleen kunt controleren of de uitkomsten ook daadwerkelijk afwijken, is het op exact dezelfde wijze te testen. Alleen dan kun je controleren of de uitkomsten overeenkomen. Als je een paar ander onderliggende aannames gaat maken dan je vergelijkingsonderzoek en dan concludeert dat de resultaten haaks staan met eerder onderzoek, sla je wat mij betreft de plank volledig mis.

Je kunt beter stellen dat onder deze voorwaarden de accutest (al dan niet significant) beter of slechter zijn dan op Android KitKat. Dat ander onderzoek wat anders uitwijst is een gegeven, maar geen grond om te suggereren dat die resultaten min of meer niet kloppen.

Omdat de uitkomst u niet bevalt?
Andere sites testen die zelfde bèta, en daar schreef u dit niet.

Nou nou, dat lijkt me dan ook weer een beetje overdreven. Een van de belangrijkste punten in L is verbeterde accuduur en als je nu zelfs een achteruitgang meet dan geeft dat aan dat er ofwel nog iets goed mis is of het gewoon geen verbetering brengt in de gebruikte testen. Google wijzen op zulke dingen is precies waarom de preview uitgebracht is en een nieuws- en testsite als tweakers.net zal dat zeker uitbrengen zonder google de hand boven het hoofd te houden.

Zijn de testresultaten ook uitgevoerd op 4.4.4 in dezelfde tijd, of worden de oude resultaten gebruikt? Anders kan het zijn dat de test niet representatief is. De Google Play Services zijn namelijk geupdate, en die zorgen bij mij voor aanzienlijk meer verbruik. Daarnaast heb je nog andere externe factoren die verschillen over een periode van een aantal weken/maanden, zoals de natuurlijke wear van de accu.

Yup, dit zijn nieuwe resultaten, ook onder 4.4

Ah, top. Interessante meting dan

De Google Sound Search vreet batterij, ik heb het uitgeschakeld, gebruik het toch niet. Maar ik zag dat hij meer batterij gebruikte dan mijn browser die continu in gebruik was.

Ik heb L nog niet op de tablet gezet, zo te zien kan ik beter de kat uit de boom kijken.

niet om t een of ander, maar lijkt me dat je dit nog niet kan zeggen. t is maar een test versie

Je kan daar toch uithalen wat de stand van zaken op dit moment is? En je kan daar uithalen dat dit mogelijk een puntje is om in de gaten te houden. Ja misschien wordt het nog verbeterd (dat hoop ik in ieder geval), maar bij een test van de final versie zou ik als eerste gaan kijken of dit verbeterd is of niet.

Tuurlijk kun je dit zeggen. Op dit moment, beta of niet, zijn dit de resultaten uit de desbetreffende tests. Dat wil niet zeggen dat dit dezelfde uitkomst zal zijn als de resultaten van de final, die over enkele maanden uitkomt. Ik ben ervan overtuigd dat er dan opnieuw getest zal worden. Het geeft enkel aan, dat testen afkomstig uit een enkele bron (Ars technica in dit geval) niet per definitie voor iedereen op gaan. Dat die desbetreffende resultaten nu wereldweid worden overgenomen is dus op zijn minst discutabel te nomen. Het gaat hier dus absoluut niet om een definitief oordeel maar enkel om objectief en realistisch te blijven kijken naar de vorderingen van Android L.

Allebei de apparaten op dezelfde dag beide tests afgelegd of 1 jaar terug de eerste accu test en nu een tweede? Om een eventueel verschil door slijtage te voorkomen.

Allebei de apparaten op dezelfde dag beide tests afgelegd of 1 jaar terug

Zat maximaal een paar weken tussen. In die weken stond hij uit: we hebben die dingen liggen, speciaal voor testen en we hebben onszelf verboden testtoestellen dagelijks te gebruiken

Zoals Arnoud al zei: Yup, dit zijn nieuwe resultaten, ook onder 4.4.

http://www.extremetech.co...ous-battery-life-increase -> maximaal 36% verbetering van de batterijduur.

Het is maar net hoe je test en ik denk ook welke onderdelen je test; je hebt met een nieuw OS ook natuurlijk de kans dat een batterij minder lang meegaat (denk aan de eerste release van Windows 8 ).

[Reactie gewijzigd door MAX3400 op 4 juli 2014 09:26]

Om meteen zulke beschuldigingen te maken vind ik er zwaar over. Als je hun artikel leest, lichten ze hun methode namelijk WEL toe, itt wat jij beweert:

We did the test on a single device to remove variances in battery, which meant flashing to 4.4.4, signing in, updating apps, charging up, running the test, and then flashing the same device to the L preview. Our battery test keeps the screen on and automatically loads webpages over Wi-Fi every 15 seconds until the battery dies. For each run, the screen brightness was set to 200 cd/m2, as verified by a colorimeter, and for consistency, we averaged two runs each.

Ik weet niet vanwaar het verschil komt, maar dat ze alles verzonnen hebben lijkt me een idiote conclusie om zo snel te maken.

Ik blijf toch sceptisch over hun resultaten. AT is zeker een website met een goede reputatie, maar het zal nooit te bewijzen zijn of hun resultaten echt zijn. En tegen de tijd dat L echt uitkomt is iedereen dat artikel al lang vergeten en hebben ze toch hun inkomsten en aandacht gescoord.

De tijd zal het leren. Maar als dan blijkt dat de resultaten van tweakers realistischer zijn, ben je natuurlijk een zeur als je dit artikel weer oprakelt. Eigenlijk zijn er geen controle mechanismen anders dan andere gebruikers die ook testen. En er zijn ook bijna geen nadelen voor AT om de resultaten wat te overdrijven. Tegen de tijd dat het ontkracht wordt is iedereen het al lang vergeten.

Ik speel een beetje de advocaat van de duivel hoor. Niet om te trollen, maar ik heb dit zo vaak zien gebeuren.

Ik denk niet dat Ars Technica zich hier echt mee gaat bezig houden.
(Sites met een minder goeie reputatie misschien wel).

Aantal dingen die Ars Technica vermeld, maar niet in het tweakers artikel staan:

• Heeft Tweakers ook alle updates geïnstalleerd van de stock-apps? Indien niet zou dit (gedeeltelijk?) het verschil tussen AT en tweakers kunnen verklaren
• Is het zelfde toestel gebruikt (eerst 4.4 test, daarna naar L geflasht)? Twee verschillende toestellen kunnen nog altijd verschillende resultaten geven. Afhankelijk van hoe twee dezelfde toestellen gebruikt zijn, kan dit resultaat verschillen.

Ars technica heeft niet vermeld welk apparaat zij gebruikt hebben, en het 4.4 resultaat ligt tussen dat van de tweakers 4.4 resultaten voor N5 en N7, dus daar is het niet meteen uit af te leiden. (Ik veronderstel Nexus 5, aangezien zij een lagere screenbrightness gebruiken, wat de iets langere 4.4 tijd zou kunnen verklaren.)

------------------------
EDIT: Nu ik de resultaten nog eens vergelijk (en uitgaande van een nexus 5), lijkt het mij wel enigszins mogelijk dat de resultaten van AT kloppen:
De nexus 5 scoort (met android L) zowel beter bij tweakers als bij Ars technica (weer: uitgegaan van het feit dat ze de N5 gebruikten, dit staat niet in het AT artikel).
Omdat AT een lagere brightness gebruikte (200 nits vs 250 nits van tweakers), heeft de smartphone sowieso een langere uptime. Met die langere uptime zouden onderliggende optimalisaties zich beter kunnen tonen. Ik ga niet beweren dat dit 36% verschil zou geven, maar het kan in ieder geval een iets groter verschil verklaren.

Misschien eens een paar tests doen met de laagst mogelijke brightness?

[Reactie gewijzigd door graverobber2 op 4 juli 2014 10:19]

Aantal dingen die Ars Technica vermeld, maar niet in het tweakers artikel staan:
Heeft Tweakers ook alle updates geïnstalleerd van de stock-apps? Indien niet zou dit (gedeeltelijk?) het verschil tussen AT en tweakers kunnen verklaren
Is het zelfde toestel gebruikt (eerst 4.4 test, daarna naar L geflasht)? Twee verschillende toestellen kunnen nog altijd verschillende resultaten geven. Afhankelijk van hoe twee dezelfde toestellen gebruikt zijn, kan dit resultaat verschillen.

Goes without saying. Als het apparaat nog updates uitvoert op de achtergrond, verbruikt dat behoorlijk. Alleen al daarom wil je up-to-date zijn.

We gebruiken altijd dezelfde toestellen. Anders kun je niet vergelijken.

Ok
Stond niet in het artikel vermeld, dus ik wou alle mogelijkheden overlopen.

Kan je misschien ook een testje doen met de laagst mogelijke brightness, zoals ik in mijn edit heb voorgesteld (langere uptime kan kleine verschillen uitvergroten)

Ik gebruik de L preview op mijn Nexus 5 sinds dat deze beschikbaar kwam. Eerlijk gezegd merk ik geen verschil qua accuduur. Het enige wat mij wel is opgevallen is dat de telefoon na het bellen echt warm is op de achterkant naast de camera. Dit was niet het geval met KitKat.

Ik geloof dat de baseband chip in de Nexus 5 variabele stroomsterkte aan het signaal kan geven. wellicht is hier het een en ander aan veranderd bij Android L, bijvoorbeeld maximale stroom / bereik tijdens bellen, een actievere CPU (kloksnelheid+voltage) voor achtergrondzaken tijdens het bellen en is alles energiezuiniger in standby.

Maar het kan ook zo maar eens een bug zijn, waardoor de CPU hard aan het werk is (voor niks lijkt me) tijdens het bellen..

[Reactie gewijzigd door ToFast op 4 juli 2014 12:57]

Stonden er nog andere wifi netwerken in de telefoons, waar deze mee kon verbinden?
Bij mij op school is de wifi soms brak, omdat er meerdere netwerken zijn en de telefoons en laprops dan steeds willen wisselen, maar dit net niet doen en dus een slechtere verbinding hebben en meer stroom gebruiken.

Is er tevens ook een harde reset toegepast?

Stonden er nog andere wifi netwerken in de telefoons, waar deze mee kon verbinden?

Nee.