Der Akku-Thread zum Samsung Galaxy S3: Akkulaufzeiten, -Probleme und mehr

[Rob2222]

Das ist nicht korrekt. Bei IMAP IDLE sendet der Client alle 15/30 Minuten ein NOOP an den Server, davor und danach werden nicht permanent Daten ausgetauscht.

Es geht ja nicht um das NOOP, sondern darum, wie das NOOP gesendet wird. Über eine TCP Verbindung. Und damit diese TCP Verbindung nicht von den NAT Routern unterwegs verworfen wird, müssen Keep-Alive Pakete gesendet werden. Auf Ebene der TCP Verbindung.
Was über die TCP Verbindung im Endeffekt geht (in diesem Fall dann meinetwegen der NOOP von IMAP) ist ganz egal.
Es muß ein Aufwand betrieben werden, um die TCP Verbindung offenzuhalten.

Wie gesagt, früher kam das wohl hin. Ich habe z.B. letzte Nacht 35 Nachrichten von unterschiedlichen Apps bekommen und trotzdem 0,3%/h.

Ja. 50 Datentransfers sind auch _nicht annähernd_ der Rede wert und evtl./vermutlich führt Deine Funkzelle eh Fast Dormancy durch, deshalb ist es egal, ob Du es im Handy ausstellst.
Schau mal bitte unter *#0011# unter RRC, wieviel Sekunden Dein Handy in Deiner Heimfunkzelle nach einem Datentransfer (Ausgehen der bunten Datentransferpfeile) im FACH Zustand bleibt.
Und als zweiten Wert, wie kurz die schnellste Zeit vom Wechsel von DCH nach PCH/IDLE ist.

Das sagt halt so nichts aus. Um das zu beurteilen brauchst Du die RRC Timer Deiner Funkzelle. Aktuell konfigurierte Funkzellen mit Fast Dormancy Zeiten schalten Dein Handy innerhalb weniger Sekunden (unter 10) in PCH oder IDLE zurück. Klar, braucht man da kein Fast Dormancy im Handy, wenn man in so eine Zelle sitzt.

Noch nicht so konfigurierte Funkzellen lassen Dein Handy dann aber 30 Sekunden in FACH rumgammeln. Und die 30 Sekunden mal 50 fachem Strombedarf für den FACH Zustand nach _jedem_ Datentransfer merkt man dann, wenn genügend einzelne Datentransfers auftreten. Bei 50 Datentransfers in einer Nacht wird man davon wohl noch nichts merken.

Deswegen ist diese Pauschalisierung ("Ich habe Fast Dormancy im Handy aus und gute Akkulaufzeit => Man sollte FD Abschalten um Akku zu sparen") eben falsch, weil es so einfach eben nicht ist.
Klar, ist das Ausschalten von Fast Dormancy im Handy nicht nachteilig, _wenn_ es die Funkzelle eh sowieso macht...


Aus "Ich habe Fast Dormancy im Handy aus und gute Akkulaufzeit" kann man nur zwei Dinge schließen:
Entweder a) Die Funkzelle führt ihrerseits Fast Dormancy durch, deswegen macht es keinen Unterschied
oder b) Ich habe in der Anzahl so wenig Datentransfers, daß es keinen merkbaren Unterschied macht, wenn das Handy nach jedem Datentransfer noch 30 Sekunden in FACH rumhängt.



Solltest Du noch in einer Funkzelle sitzen, die ihrerseits kein Fast Dormancy durchführt, DANN kannst Du gerne mal den Unterschied zwischen Handy-Fast Dormancy an und aus testen. Für den Test mußt Du dann aber auch mal eine ordentliche Menge an einzelnen Datentransfers erzeugen. Zum Beispiel alle 15 Sekunden einen Ping senden, der so groß ist, daß das Handy in den DCH Zustand hochschaltet. Das wären dann 1440 "Zurückschaltungen" in 6 Stunden. Und _dann_ kannst Du FD-Handy an/aus vergleichen.

PS: Hast Du den von mir verlinkten Beitrag zu Fast Dormancy mal gelesen? Weil da steht das eigentlich schon recht detailliert drin.


Gruß
Rob

 

[steffibabyy]

hallo
habe das samsung galxy s 3 und es will nicht mehr laden.
wenn ich das aldekabel reinstecke kommt diese ton nicht mehr. der blitz wird angeziegt, läd jedoch nicht.
außerdem steht im bildschirm weiterhin" ladegerät anschließen!"
am laptop angeschlossenläd es auch nicht
mehrmals an und aus gemacht aber nichts klappt, anders ladekabel klappt auch nicht.
was mache ich denn nun? hat einer einen tipp für mich?

 

[S13gfried]

Wenn du dein handy mit USB Kabel an rechner hängst, bekommst du eine Verbindung? (AUf bilder etc)? oder geht das auch nicht.

Wenn du eine/keine Verbindung bekommst, wackel mal ein bisschen und gucke/höhre ob diese bestehen bleibt oder nicht konstant ist. Hört man ja auch am Windows sound.


Und was noch, Handy ausschalten und ranhängen. Dann sollte das große Batteriesymbol kommen.
Weiß jetzt nicht was du für eine Rom hast, sicher original, bei mir bleibt diese Batterie grau, könnte bei dir anders sein, also kontrollier mal vor dem ausschalten akku anzeige und nach 30Minuten dran lassen (nur in dem "Lademodus") anmachen und nochmal checken, ob geladen wurde.

 

[steffibabyy]

hallo danke für deine schnelle antwort

wenn ich am pc dran hänge kommt oben wie gehabt der blitz und eine verbindung bekomme ich auczh auf bilder.

wenn ich das handy ausmache und das akku dran hänge, kommt die große batterie und verschwindet nach 2 sekunden.

normalerweise bleibt sie konztanz da und läd, aber seit heute morgen tut sich leider garnichts mehr...ö

 

[koboltzz]

Es geht ja nicht um das NOOP, sondern darum, wie das NOOP gesendet wird. Über eine TCP Verbindung. Und damit diese TCP Verbindung nicht von den NAT Routern unterwegs verworfen wird, müssen Keep-Alive Pakete gesendet werden.

Sorry, aber du redest kariert. Was du "Kepp-Alive Pakete" nennst ist ein NOOP (No Operation).

Ja. 50 Datentransfers sind auch _nicht annähernd_ der Rede wert und evtl./vermutlich führt Deine Funkzelle eh Fast Dormancy durch, deshalb ist es egal, ob Du es im Handy ausstellst.
Schau mal bitte unter *#0011# unter RRC, wieviel Sekunden Dein Handy in Deiner Heimfunkzelle nach einem Datentransfer (Ausgehen der bunten Datentransferpfeile) im FACH Zustand bleibt.
Und als zweiten Wert, wie kurz die schnellste Zeit vom Wechsel von DCH nach PCH/IDLE ist.

Äh, was du dir da angelesen hast, entspricht nicht ganz der Wahrheit.
1. Funkzellen bestimmen nicht über Fast Dormancy, es sind die Netzbetreiber. Technisch gesehen unterstützt jede Funkzelle Fast Dormancy in Deutschland.
2. Du kannst hier mal etwas differenzierter über FD nachlesen. Es ist nicht von der Hand zu weisen, dass Android wakelocks en masse produziert, sobald FD aktiviert, aber nicht unterstützt wird vom Netzbetreiber. Das zieht dann sehr viel Akku, völlig egal ob man 1000 E-mails oder eine am Tag bekomt.

Also bitte bitte hör auf gegen das Deaktivieren zu wettern. Einige kompetente Leute haben nicht umsonst diverse Deaktivierungs-Apps online gestellt und werden mit Dankbarkeit von den Usern überschüttet.

 

[S13gfried]

hallo danke für deine schnelle antwort

wenn ich am pc dran hänge kommt oben wie gehabt der blitz und eine verbindung bekomme ich auczh auf bilder.

wenn ich das handy ausmache und das akku dran hänge, kommt die große batterie und verschwindet nach 2 sekunden.

normalerweise bleibt sie konztanz da und läd, aber seit heute morgen tut sich leider garnichts mehr...ö

Das hört sich sehr eigenartig an.

Wenn du am Kabel wackelst, bleibt es aber mit dem PC Verbunden?
Wenn der Blitz kommt, läd es doch dann am Rechner ?!

 

[steffibabyy]

eben nicht.
auch wenn ich am kabel wackel bleibt der blitz da aber es läd nicht.

war eben 3 stunden angeschlossen und liegt immer noch bei 3 % und uaf dem bildschirm steht weiterhin "ladekabel anschließen"

 

[koboltzz]

Samsung Netzteile haben eine kurze Lebenserwartung, das ist nichts neues.
Kurz gesagt; deines ist kaputt, kauf dir ein Nokia Netzteil, die sind super.

 

[steffibabyy]

am ladekabel liegt es nicht.
meine mama hat das mini und habs eben versucht mit meinem ladekabel und es hat geklappt

 

[koboltzz]

Ich sprach auch nicht vom Ladekabel...
Wenn das Ding, was du in die Steckdose steckst, kein Batteriesymbol auf deinem S3 auslöst, ist das Netzteil kaputt.

 

[steffibabyy]

was ist ein netzteil?
der stecker der in die steckdose kommt oder wie? steh grade aufem schlauch

 

[SaschaKH]

was ist ein netzteil?
der stecker der in die steckdose kommt oder wie? steh grade aufem schlauch

Ja das TEIL das Du zwischen Dein Smartphone und das 230 V StromNETZ steckst um es auf zu laden. Ja die Netzteile die mit Smartphones geliefert werden sind normalerweise direkt am Eurostecker dran. Manche der USB-Netzteile haben ein Kabel mit Micro-USB-Stecker dran, das vom SGS3 hat aber glaub nur eine USB-Buchse dran so das Du noch ein Kabel brauchst um es mit dem Smartphone zu verbinden.

 

[Rob2222]

Sorry, aber du redest kariert. Was du "Kepp-Alive Pakete" nennst ist ein NOOP (No Operation).

Sorry, aber ich meine Keep Alive Pakete. NOOPs sendet der IMAP Client an den IMAP Server z.b. alle 30 Minuten um zu signalisieren, daß die Verbindung zwischen Client und Server noch steht. Das passiert auf OSI Layer 7.

Auf TCP/IP Verbindungsebene (OSI Layer 4) muß das Android Telefon die TCP Verbindung am leben erhalten. Und da reicht das NOOP alle 30 Minuten eben nicht aus. Deswegen muß das Telefon Keep-Alive Pakete senden.
Das passiert auf einer ganz anderen Netzwerkschicht (7 vs 4) und da sind es eben Keep Alive Pakete.
Siehe: Keepalive - Wikipedia, the free encyclopedia

Äh, was du dir da angelesen hast, entspricht nicht ganz der Wahrheit.
1. Funkzellen bestimmen nicht über Fast Dormancy, es sind die Netzbetreiber. Technisch gesehen unterstützt jede Funkzelle Fast Dormancy in Deutschland.

In der Tat konfiguriert der Netzanbieter seine Funkzellen. Wenn Du jetzt aber denkst, die Funkzellen eines Netzanbieters sind alle einheitlich konfiguriert, dann irrst Du. Bei im Handy abgeschalteten Fast Dormancy hat die eine Vodafone Zelle mein Handy 30 Sekunden im FACH Zustand hängen lassen und dann zu IDLE geschickt (nicht fast dormant), während eine andere Vodafone Funkzelle das Handy bereits nach 8 Sekunden komplett von DCH nach PCH geschaltet hat (fast dormant). Ebenso habe ich beide Zellkonfigurationen (nicht fast dormant und fast dormant) im E-Plus Netz beobachten können.
Man kann also nicht alle Funkzellen eines Providers über einen Kamm scheren, man muß das Thema Fast Dormancy nach der jeweiligen Konfiguration der einzelnen Funkzelle beurteilen.

2. Du kannst hier mal etwas differenzierter über FD nachlesen.

Was soll ich da bitte differenzierter lesen? Genau wegen solchen oberflächlichen Artikeln habe ich die Zusammenfassung hier geschrieben.
Allerdings habe ich mich dabei nicht auf irgendwelche falsche Beobachtungen gestützt sondern auf ein Dokument der Netzbetreiber (GSM Association) zu Fast Dormancy "Fast Dormancy Best Practices".
Link zu Deiner Verfügung: Link
Und genau da steht eben drin, daß es zwei verschiedenen Versionen von Fast Dormancy gibt. Einmal das vom Handy ausgelöste (in dem Dokument ASCR genannt) und einmal ein auf 3GPP-R8 basiertes von den Zellen gesteuertes NCFD.

Es ist nicht von der Hand zu weisen, dass Android wakelocks en masse produziert, sobald FD aktiviert....

Bis hierhin korrekt. Aber diese Fast Dormancy Wakelocks fallen nicht ins Gewicht und kosten keinen Akku. Wieso? Weil sie das Handy nicht effektiv wachhalten, da sie dann geschaltet werden, wenn das Handy eh wach ist.
Kernel-Wakelocks überlappen sich. Wenn beispielsweise Wakelock A das Handy 10 Minuten in einer Stunde wach hält, dann kannst Du in genau diesen 10 Minuten tausend andere Wakelocks schalten, die das Handy nicht beeinflussen, da das Handy durch Wakelock A eh schon wach ist.

Wenn Du wegen massivem Datenverkehr beispielsweise 1 Stunde secril-FD Wakelocks siehst, dann hast Du gleichzeitig auch über 1 Stunden multiPDP Wakelocks. Die durch den Datenverkehr bedingten multiPDP Wakelocks halten das Handy wach. Ob da jetzt noch gleichzeitig secril-FD Wakelocks parallel geschaltet werden, ist für den Akku vollkommen egal.
Kurzer Auszug aus einem BBS Log dazu:
"multipdp" (): 1 h 31 m 49 s (5509 s) Cntc/wc/ec)693/0/693 20.0
"secril_fd-interface" (): 1 h 9 m 13 s (4153 s) Cntc/wc/ec)956/0/0 15.1%
"l2_hsic" (): 26 m 14 s (1574 s) Cntc/wc/ec)2928/1185/2929 5.7%

Beleg daß sich die Wakelocks überschneiden hier. In einer nur 10 Minuten laufenden Messung habe ich 9:48min multiPDP Wakelocks und gleichzeitig 7:35min secril-FD Wakelocks erzeugt.

... aber nicht unterstützt wird vom Netzbetreiber. Das zieht dann sehr viel Akku, völlig egal ob man 1000 E-mails oder eine am Tag bekomt.

Die Wakelocks steigen einzig und alleine mit der Menge an Datenverkehr und das hat nichts mit der Funkzelle oder irgendeiner Kompatibilität dieser zu tun. Trotzdem sind die Wakelocks nicht schlimm, aus obig genannten Grund.

Also bitte bitte hör auf gegen das Deaktivieren zu wettern.

Warum, wenn es denn keinen Sinn macht bzw. nur ein fest eingesessener Mythos ist, der trotzdem falsch ist? Der einzig sinnvolle Grund Fast Dormancy zu deaktivieren ist, wenn man in einer Funkzelle ist, die nicht damit zurechtkommt, wenn ein Handy FD-alt durchführt. Dann kriegst Du einen Standbyverbrauch von 3-5%/Stunde, ohne überhaupt Datenverkehr zu haben. Aber solch eine Funkzelle heutzutage und hier in Europa soll mir erstmal jemand zeigen. Die letzten mir bekannten Berichte dazu sind aus der Anfangzeit von UMTS bzw. liegen mittlerweile mehrere Jahre zurück und das waren Netzwerke in den USA.

Aber eine Bitte zurück, bitte setze Dich selbst mit dem Thema auseinander und studiere zumindest das obig genannte PDF, denn da steht genau das drin, was ich hier herunterpredige. Und, wie gesagt, das Dokument ist von der GSM-Association, also im Gegensatz zu vielem heruntergeschriebenen Halbwissen eine belastbare Quelle. Weitere Links zum Vertändnis in der Fußnote dieses Artikels.

Einige kompetente Leute haben nicht umsonst diverse Deaktivierungs-Apps online gestellt und werden mit Dankbarkeit von den Usern überschüttet.

So viel Kompetenz habe ich bei meiner wirklich umfassenden, mehrtägigen Recherche zum Thema nicht gefunden. Selbst bei XDA gab es kaum belastbare Aussagen zum Thema Fast Dormancy, die sich nicht doch mit den offiziellen Dokumenten, wie z.B. das verlinkte Dokument der GSMA gebissen haben. In vielen oder sogar fast allen Fast Dormancy Erklärungen lief es auf "Wir schaltens mal ab und glauben dran, daß wir jetzt Akku sparen" hinaus. Selbst bei XDA. Und das geht auch oft gut, weil die meisten Leute eben nicht das Datenaufkommen haben, daß sich der Unterschied negativ auswirken würde oder eben die Funkzelle selbst schon fast dormant konfiguriert ist. Belastbare Quellen sind wie gesagt in der Fußnote des obig genannten Artikels.

Viele Grüße
Robert

 

[koboltzz]

Sorry, aber ich meine Keep Alive Pakete. NOOPs sendet der IMAP Client an den IMAP Server z.b. alle 30 Minuten um zu signalisieren, daß die Verbindung zwischen Client und Server noch steht. Das passiert auf OSI Layer 7.

Sorry, aber ich weiß nicht, woher du diesen Terminus hast. NOOP ist ein Keep-Alive. Du schreibst die ganze Zeit von "belastbaren" Quellen und kommst dann mit einem Wikipedia-Artikel an?

Was soll ich da bitte differenzierter lesen? Genau wegen solchen oberflächlichen Artikeln habe ich die Zusammenfassung hier geschrieben.
Allerdings habe ich mich dabei nicht auf irgendwelche falsche Beobachtungen gestützt sondern auf ein Dokument der Netzbetreiber (GSM Association) zu Fast Dormancy "Fast Dormancy Best Practices".
Link zu Deiner Verfügung: Link

Soso, eine Quelle. Dass die verlinkte Seite eine Tauschbörse für Präsentationen ist, ist dir aber schon klar, oder? (Keine "belastbare" Quelle) schließlich kann idh dasselbe auch anders uploaden.

Und genau da steht eben drin, daß es zwei verschiedenen Versionen von Fast Dormancy gibt. Einmal das vom Handy ausgelöste (in dem Dokument ASCR genannt) und einmal ein auf 3GPP-R8 basiertes von den Zellen gesteuertes NCFD.

Das steht nun wirklich überall so im Internet, bis auf, dass andere nicht einfach wild Abkürzungen kopieren, um Eindruck zu schinden.

Bis hierhin korrekt. Aber diese Fast Dormancy Wakelocks fallen nicht ins Gewicht und kosten keinen Akku. Wieso? Weil sie das Handy nicht effektiv wachhalten, da sie dann geschaltet werden, wenn das Handy eh wach ist.

Bis hierhin falsch. MultiDPD ist ein unvermeidbarer wakelock, wenn Daten übertragen werden. Nichtsdestotrotz, der secril-fd-interface wakelock kann unabhängig davon sehr hoch oder quasi nicht vorhanden sein, je nachdem ob FD im Smartphone aktiviert oder deaktiviert ist. Diese überschneiden sich im ersten Fall nicht immer und führen zu einem exorbitantem Akkuverbrauch. Der verlinkte "Beleg" stammt von dir.

Warum, wenn es denn keinen Sinn macht bzw. nur ein fest eingesessener Mythos ist, der trotzdem falsch ist? Der einzig sinnvolle Grund Fast Dormancy zu deaktivieren ist, wenn man in einer Funkzelle ist, die nicht damit zurechtkommt, wenn ein Handy FD-alt durchführt. Dann kriegst Du einen Standbyverbrauch von 3-5%/Stunde, ohne überhaupt Datenverkehr zu haben. Aber solch eine Funkzelle heutzutage und hier in Europa soll mir erstmal jemand zeigen.

Kurzum: Die Deaktivierungs-Apps gibt es und sie bringen Normalisierung. Wir leben also alle mit Funkzellen, welche nicht mit "FD-alt" seitens "Handy" klarkommen, nur du nicht. Zufrieden?

PS: Ab Android 4.2 muss man die nwk_info.db bearbeiten, um FD los zu werden.

 

[TylonHH]

Wie kann ich denn Informationen über meine Funkzellen erhalten? Um zum Beispiel herauszufinden ob diese (höchstwahrscheinlich) FD unterstützen.

 

[rotznaas]

Morgen
Bin absoluter Neuling, hab trotzdem die slimbean Rom aufgespielt und den yank kernel geflasht .
Jetz entlädt sich mein Akku über Nacht recht schnell und da wollte ich mal hier um Hilfe bitten.
Hatte vogestern Nacht einmal nen Akku Verbrauch von 0,4 %/h, das ist ja top. 3g an.
Heute Nacht warens dann aber wieder 1,7%/h und in den vorherigen nächten auch schon mal mehr.
Die log Datei von BBS häng ich als spoiler an.

Ich danke schon mal im voraus.

 

[BananaPing]

Helfe nur bei spoiler, kein bock die sd-card zu zu Müllen

Der ursprüngliche Beitrag von 09:12 Uhr wurde um 09:13 Uhr ergänzt:

Das was du da gemacht hast ist ein Anhang und kein spoiler

 

[S13gfried]

Spoiler:

(Spoiler)
TEXT VOM BBS
(/Spoiler)

statt den runden Klammern, die eckigen []

Dein Log haut übrigens nicht richtig hin,
sieht bei mir so aus am Anfang:
<!DOCTYPE html><html lang="en" xmlns:fb="http://ogp.me/ns/fb#" xml:lang="en"
...

 

[rotznaas]

So, dann probiere ich es nochmal.

Spoiler

===================
General Information
===================
BetterBatteryStats version: 1.13.4.0
Creation Date: 2013-06-21 06:14:32
Statistic Type: Unplugged to Current
Since 6 h 58 m 29 s
VERSION.RELEASE: 4.2.2
BRAND: samsung
DEVICE: m0
MANUFACTURER: samsung
MODEL: GT-I9300
OS.VERSION: 3.0.81-Yank555.lu-CM10.1-v1.6b
BOOTLOADER: I9300XXBLH3
HARDWARE: smdk4x12
FINGERPRINT: samsung/m0xx/m0:4.1.1/JRO03C/I9300XXDLIB:user/release-keys
ID: JDQ39E
TAGS: test-keys
USER: mnazim
PRODUCT: m0xx
RADIO: I9300XXELL4
Rooted: true
============
Battery Info
============
Level lost [%]: Bat.: -12% (56% to 44%) [1,7%/h]
Voltage lost [mV]: (3834-3788) [6,6%/h]
===========
Other Usage
===========
Deep Sleep (): 6 h 36 m 2 s (23762 s) Ratio: 94,6%
Awake (): 22 m 26 s (1346 s) Ratio: 5,4%
Screen On (): 7 m 40 s (460 s) Ratio: 1,8%
Poor Signal (): 6 m 43 s (403 s) Ratio: 1,6%
Good Signal (): 2 s (2 s) Ratio: 0,0%
Screen dark (): 7 m 31 s (451 s) Ratio: 1,8%
Screen dimmed (): 9 s (9 s) Ratio: 0,0%
=========
Wakelocks
=========
AudioOut_2 (1013): 3 m 9 s (189 s) Count:3 0,8%
AlarmClock (com.android.deskclock.Uhr): 3 m 1 s (181 s) Count:23 0,3%
*sync*_com.google.android.location.reporting_Account {name=a5125242f14770b06e580497ae9a3880, type=com.google} (Google-Dienste): 1 m 14 s (74 s) Count:242 0,1%
AlarmManager (Android-System): 32 s (32 s) Count:268 0,1%
fullsync (com.whatsapp.WhatsApp): 16 s (16 s) Count:12 0,1%
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint (Google-Dienste): 11 s (11 s) Count:4 0,0%
Cleaner (com.oasisfeng.greenify.Greenify): 10 s (10 s) Count:5 0,0%
ActivityManager-Launch (Android-System): 4 s (4 s) Count:30 0,0%
BBS_WAKELOCK_WHILE_SAVING_REF (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 3 s (3 s) Count:6 0,0%
Event Log Service (Google-Dienste): 3 s (3 s) Count:25 0,0%
NetworkStats (Android-System): 2 s (2 s) Count:15 0,0%
NlpWakeLock (Google-Dienste): 2 s (2 s) Count:3 0,0%
AlarmManager (Telefon): 2 s (2 s) Count:70 0,0%
*backup* (Android-System): 1 s (1 s) Count:81 0,0%
AlarmManager (Google-Dienste): 1 s (1 s) Count:130 0,0%
SyncManagerHandleSyncAlarm (Android-System): 1 s (1 s) Count:540 0,0%
AlarmManager (com.muzurisana.birthdayfree.Geburtstage-Free): 1 s (1 s) Count:1 0,0%
Checkin Handoff (Google-Dienste): 1 s (1 s) Count:100 0,0%
================
Kernel Wakelocks
================
"multipdp" (): 6 m 30 s (390 s) Cntc/wc/ec)56/0/57 1,6%
"secril_fd-interface" (): 5 m 7 s (307 s) Cntc/wc/ec)71/0/0 1,2%
"l2_hsic" (): 3 m 47 s (227 s) Cntc/wc/ec)490/105/490 0,9%
"PowerManagerService" (): 1 m 57 s (117 s) Cntc/wc/ec)282/0/0 0,5%
"alarm_rtc" (): 1 m 49 s (109 s) Cntc/wc/ec)254/63/16 0,4%
"alarm" (): 1 m 20 s (80 s) Cntc/wc/ec)282/0/0 0,3%
"battery-monitor" (): 1 m 2 s (62 s) Cntc/wc/ec)251/0/252 0,3%
"umts_ipc0" (): 42 s (42 s) Cntc/wc/ec)105/0/105 0,2%
"rpm_hsic" (): 38 s (38 s) Cntc/wc/ec)228/0/0 0,2%
"tx_hsic" (): 30 s (30 s) Cntc/wc/ec)489/0/0 0,1%
"umts_rfs0" (): 17 s (17 s) Cntc/wc/ec)7/0/6 0,1%
"mmc1_detect" (): 17 s (17 s) Cntc/wc/ec)267/0/0 0,1%
"radio-interface" (): 6 s (6 s) Cntc/wc/ec)11/0/0 0,0%
"efsd-interface" (): 1 s (1 s) Cntc/wc/ec)14/0/0 0,0%
"secril_rfs-interface" (): 1 s (1 s) Cntc/wc/ec)7/0/0 0,0%
"PowerManagerService.Broadcasts" (): (0 s) Cntc/wc/ec)4/0/0 0,0%
"secril_fmt-interface" (): (0 s) Cntc/wc/ec)183/0/0 0,0%
"power-supply" (): (0 s) Cntc/wc/ec)315/72/0 0,0%
"KeyEvents" (): (0 s) Cntc/wc/ec)444/0/0 0,0%
"sync_system" (): (0 s) Cntc/wc/ec)2/0/0 0,0%
"mmc0_detect" (): (0 s) Cntc/wc/ec)267/0/0 0,0%
=========
Processes
=========
kworker/0:0 (0): Uid: 0 Sys: 20 s (20 s) Us: (0 s) Starts: 0
com.android.deskclock (com.android.deskclock.Uhr): Uid: 10009 Sys: 1 s (1 s) Us: 17 s (17 s) Starts: 5
kworker/0:1 (0): Uid: 0 Sys: 15 s (15 s) Us: (0 s) Starts: 0
kworker/0:2 (0): Uid: 0 Sys: 7 s (7 s) Us: (0 s) Starts: 0
kworker/0:3 (0): Uid: 0 Sys: 6 s (6 s) Us: (0 s) Starts: 0
kworker/u:15 (0): Uid: 0 Sys: 4 s (4 s) Us: (0 s) Starts: 0
surfaceflinger (Android-System): Uid: 1000 Sys: 1 s (1 s) Us: 2 s (2 s) Starts: 0
kworker/u:21 (0): Uid: 0 Sys: 3 s (3 s) Us: (0 s) Starts: 0
kworker/u:16 (0): Uid: 0 Sys: 3 s (3 s) Us: (0 s) Starts: 0
kworker/u:4 (0): Uid: 0 Sys: 3 s (3 s) Us: (0 s) Starts: 0
kworker/u:29 (0): Uid: 0 Sys: 3 s (3 s) Us: (0 s) Starts: 0
*wakelock* (Google-Dienste): Uid: 10047 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/u:28 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/u:19 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/u:25 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/u:9 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/u:6 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:8 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:23 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:17 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:14 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:3 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
mediaserver (1013): Uid: 1013 Sys: (0 s) Us: 1 s (1 s) Starts: 0
kworker/u:10 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:18 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:31 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:22 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:5 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:30 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:0 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:11 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:27 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
kworker/u:2 (0): Uid: 0 Sys: 1 s (1 s) Us: (0 s) Starts: 0
*wakelock* (Telefon): Uid: 1001 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:20 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:7 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:12 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
mmcqd/0 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:1 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:13 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:26 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kworker/u:24 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
com.whatsapp (com.whatsapp.WhatsApp): Uid: 10061 Sys: (0 s) Us: (0 s) Starts: 1
*wakelock* (com.oasisfeng.greenify.Greenify): Uid: 10085 Sys: (0 s) Us: (0 s) Starts: 0
s3c-fb-vsync (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
/init (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
jrcud (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
netd (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
vold (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
ueventd (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kthreadd (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
kswapd0 (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
======================
Alarms (requires root)
======================
com.android.phone (): Wakeups: 67
Alarms: 67, Intent: com.android.internal.telephony.gprs-data-stall
Alarms: 0, Intent: com.android.phone.UPDATE_CALLER_INFO_CACHE
Alarms: 0, Intent: com.android.internal.telephony.gprs-reconnect.0

android (): Wakeups: 35
Alarms: 0, Intent: android.intent.action.TIME_TICK
Alarms: 0, Intent: com.android.server.action.NETWORK_STATS_POLL
Alarms: -72, Intent: android.appwidget.action.APPWIDGET_UPDATE
Alarms: 0, Intent: com.android.server.ThrottleManager.action.POLL
Alarms: -72, Intent: android.appwidget.action.APPWIDGET_UPDATE
Alarms: -124, Intent: android.appwidget.action.APPWIDGET_UPDATE
Alarms: 1, Intent: com.android.internal.policy.impl.PhoneWindowManager.DELAYED_KEYGUARD
Alarms: 7, Intent: android.app.backup.intent.RUN
Alarms: 10, Intent: android.content.syncmanager.SYNC_ALARM
Alarms: -139, Intent: android.appwidget.action.APPWIDGET_UPDATE
Alarms: 0, Intent: android.net.wifi.DHCP_RENEW
Alarms: 0, Intent: android.intent.action.DATE_CHANGED
Alarms: 1, Intent: com.android.server.action.UPDATE_TWILIGHT_STATE
Alarms: 0, Intent: com.android.server.NetworkTimeUpdateService.action.POLL
Alarms: 0, Intent: com.android.server.WifiManager.action.START_SCAN

com.google.android.gsf (): Wakeups: 34
Alarms: 1, Intent: com.google.android.intent.action.SEND_IDLE
Alarms: 17, Intent: com.google.android.intent.action.MCS_HEARTBEAT
Alarms: 14, Intent: {com.google.android.gsf
Alarms: 2, Intent: com.google.android.intent.action.GTALK_RECONNECT

com.oasisfeng.greenify (): Wakeups: 5
Alarms: 5, Intent: com.oasisfeng.greenify.CLEAN_NOW

com.whatsapp (): Wakeups: 2
Alarms: 0, Intent: ALARM_ACTION
Alarms: 0, Intent: ALARM_AVAILABLE_TIMEOUT
Alarms: 0, Intent: com.whatsapp.MessageService.RECONNECT
Alarms: 0, Intent: ALARM_REPORT_SYNCS
Alarms: 1, Intent: ALARM_ROTATE_LOGS
Alarms: 1, Intent: ALARM_MESSAGES_DB_BACKUP
Alarms: 0, Intent: ALARM_CLIENT_PING_TIMEOUT

com.google.android.gms (): Wakeups: 2
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_LOCATOR
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_ACTIVE_COLLECTOR
Alarms: 1, Intent: com.google.android.gms.icing.INDEX_RECURRING_MAINTENANCE
Alarms: 1, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_CACHE_UPDATER
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_ACTIVITY_DETECTION
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_BURST_COLLECTION_TRIGGER
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_PASSIVE_COLLECTOR

com.android.deskclock (): Wakeups: 2
Alarms: 2, Intent: com.android.deskclock.ALARM_ALERT

com.android.providers.calendar (): Wakeups: 1
Alarms: 1, Intent: com.android.providers.calendar.intent.CalendarProvider2

com.muzurisana.birthdayfree (): Wakeups: 1
Alarms: 1, Intent: {com.muzurisana.birthdayfree

======================
Network (requires root)
======================
10047 (Mobile) (Google-Dienste): 66.0 KBytes 43,7%
10061 (Mobile) (com.whatsapp.WhatsApp): 37.0 KBytes 24,6%
0 (Mobile) (0): 23.0 KBytes 15,2%
10045 (Mobile) (com.android.vending.Google Play Store): 21.0 KBytes 14,2%
10074 (Mobile) (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 3.0 KBytes 2,3%
==========
CPU States
==========
1,4 GHz (): 2 m 58 s 0,7%
1,3 GHz (): 1 m 28 s 0,4%
1,2 GHz (): 46 s 0,2%
1,1 GHz (): 50 s 0,2%
1 GHz (): 1 m 53 s 0,5%
900 MHz (): 2 s 0,0%
800 MHz (): 2 m 28 s 0,6%
700 MHz (): 1 s 0,0%
600 MHz (): 2 m 4 s 0,5%
500 MHz (): 0,0%
400 MHz (): 9 s 0,0%
300 MHz (): 28 s 0,1%
200 MHz (): 9 m 13 s 2,2%
Deep Sleep (): 6 h 36 m 2 s 94,6%
========
Services
========
Active since: The time when the service was first made active, either by someone starting or binding to it.
Last activity: The time when there was last activity in the service (either explicit requests to start it or clients binding to it)
See http://developer.android.com/reference/android/app/ActivityManager.RunningServiceInfo.html
com.google.android.youtube (com.google.android.youtube.core.transfer.DownloadService)
Active since: 2 d 11 h 54 m 45 s
Last activity: 12 h 30 m 14 s
Crash count:0
com.android.phone (com.android.phone.TelephonyDebugService)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.android.smspush (com.android.smspush.WapPushManager)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.pan.PanService)
Active since: 16 s
Last activity: 16 s
Crash count:0
com.google.process.gapps (com.google.android.gsf.gtalkservice.service.GTalkServiceProxy)
Active since: 28 s
Last activity: 12 h 18 m 1 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.locking.core.AppLockingService)
Active since: 20 s
Last activity: 1 h 7 m 39 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.a2dp.A2dpService)
Active since: 20 s
Last activity: 20 s
Crash count:0
com.android.systemui (com.android.systemui.SystemUIService)
Active since: 17 s
Last activity: 17 s
Crash count:0
com.bel.android.dspmanager (com.bel.android.dspmanager.service.HeadsetService)
Active since: 21 s
Last activity: 12 h 36 m 42 s
Crash count:0
com.google.android.music:main (com.google.android.music.preferences.MusicPreferenceService$MusicPreferenceServiceBinder)
Active since: 2 d 18 h 45 m 14 s
Last activity: 12 h 37 m 25 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.messageshield.MessageScannerService)
Active since: 3 h 55 m 49 s
Last activity: 12 h 18 m 1 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.webshield.WebshieldService)
Active since: 5 m 32 s
Last activity: 1 h 7 m 39 s
Crash count:0
com.android.inputmethod.latin (com.android.inputmethod.latin.LatinIME)
Active since: 17 s
Last activity: 12 h 26 m 19 s
Crash count:0
com.android.systemui (com.android.systemui.ImageWallpaper)
Active since: 17 s
Last activity: 17 s
Crash count:0
com.android.phone (com.android.phone.BluetoothPhoneService)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.pbap.BluetoothPbapService)
Active since: 20 s
Last activity: 20 s
Crash count:0
com.android.location.fused (com.android.location.fused.FusedLocationService)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.google.android.music:main (com.google.android.music.store.StoreService$StoreServiceBinder)
Active since: 2 d 18 h 45 m 14 s
Last activity: 12 h 37 m 25 s
Crash count:0
com.google.process.location (com.google.android.location.NetworkLocationService)
Active since: 18 s
Last activity: 8 h 9 m 17 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.trafficinfo.NetworkStatsService)
Active since: 20 s
Last activity: 12 h 52 m 16 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.hid.HidService)
Active since: 20 s
Last activity: 20 s
Crash count:0
com.google.android.music:main (com.google.android.music.net.NetworkMonitor)
Active since: 2 d 18 h 45 m 14 s
Last activity: 12 h 37 m 31 s
Crash count:0
com.whatsapp (com.whatsapp.messaging.MessageService)
Active since: 24 s
Last activity: 12 h 37 m 34 s
Crash count:1
com.google.process.location (com.google.android.location.internal.server.NetworkLocationService)
Active since: 19 s
Last activity: 8 h 9 m 17 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.scanner.OnDemandScannerScanService)
Active since: 11 h 52 m 19 s
Last activity: 10 h 48 m 12 s
Crash count:0
com.google.android.music:main (com.google.android.music.store.MediaStoreImportService)
Active since: 2 d 18 h 45 m 14 s
Last activity: 12 h 37 m 25 s
Crash count:0
com.google.android.music:main (com.google.android.music.playback.MusicPlaybackService)
Active since: 27 s
Last activity: 12 h 37 m 25 s
Crash count:0
com.google.process.location (com.google.android.location.GeocodeService)
Active since: 18 s
Last activity: 8 h 9 m 17 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.advisor.AdvisorScanService)
Active since: 4 m 14 s
Last activity: 10 h 48 m 12 s
Crash count:0
com.android.phone (com.android.stk.StkAppService)
Active since: 22 s
Last activity: 1 m 14 s
Crash count:0
com.android.nfc:handover (com.android.nfc.handover.HandoverService)
Active since: 18 s
Last activity: 18 s
Crash count:0
system (com.google.android.backup.BackupTransportService)
Active since: 16 s
Last activity: 16 s
Crash count:0
com.google.process.location (com.google.android.location.internal.server.GoogleLocationService)
Active since: 1 d 22 h 52 m 45 s
Last activity: 12 h 37 m 26 s
Crash count:0
com.oasisfeng.greenify:service (com.oasisfeng.greenify.CleanerService)
Active since: 25 s
Last activity: 12 h 46 m 41 s
Crash count:0
com.google.android.music:main (com.google.android.music.download.DownloadQueueService)
Active since: 2 d 18 h 45 m 15 s
Last activity: 12 h 37 m 31 s
Crash count:0
com.google.process.gapps (com.google.android.gsf.gtalkservice.service.GTalkService)
Active since: 28 s
Last activity: 10 h 48 m 12 s
Crash count:0
net.nurik.roman.dashclock (com.google.android.apps.dashclock.DashClockService)
Active since: 26 s
Last activity: 12 h 44 m 2 s
Crash count:0
com.google.android.music:main (com.google.android.music.download.cache.CacheService)
Active since: 2 d 18 h 45 m 15 s
Last activity: 12 h 37 m 31 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.hfp.HeadsetService)
Active since: 18 s
Last activity: 18 s
Crash count:0
==================
Reference overview
==================
ref_boot: Reference ref_boot created 25 s (Wl: 0 elements; KWl: 0elements; NetS: 2 elements; Alrm: null; Proc: 0 elements; Oth: 5 elements; CPU: 12 elements)
ref_charged: Reference ref_charged created 2 d 1 h 42 m 18 s (Wl: 0 elements; KWl: 30elements; NetS: 45 elements; Alrm: 13 elements; Proc: 0 elements; Oth: 4 elements; CPU: 14 elements)
ref_unplugged: Reference ref_unplugged created 2 d 15 h 7 m 42 s (Wl: 48 elements; KWl: 30elements; NetS: 49 elements; Alrm: 13 elements; Proc: 61 elements; Oth: 16 elements; CPU: 14 elements)
ref_custom: Reference ref_custom created 2 d 15 h 8 m 5 s (Wl: 48 elements; KWl: 30elements; NetS: 49 elements; Alrm: 13 elements; Proc: 61 elements; Oth: 16 elements; CPU: 14 elements)
ref_current: Reference ref_current created 2 d 22 h 6 m 11 s (Wl: 53 elements; KWl: 30elements; NetS: 49 elements; Alrm: 13 elements; Proc: 62 elements; Oth: 16 elements; CPU: 14 elements)

Hoffe das klappt jetzt.
Schon mal danke für hinweisen

Der ursprüngliche Beitrag von 08:27 Uhr wurde um 08:28 Uhr ergänzt:

Nein hat es wohl nicht :-(

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

Der ursprüngliche Beitrag von 08:28 Uhr wurde um 08:28 Uhr ergänzt:

Wohl doch :-]

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

 

[S13gfried]

Jetzt geht es, gut.

Es ist hier eigentlich nichts drin, was irgendwie massiv schlimm ist in meinen Augen.
Deepsleep ist gut, höher als meiner. Aber der Verbrauch von 1.6%/h etwas höher als bei mir.
Es sind ein paar Minuten "poor signal" dabei, dafür kannst du aber nichts und das sollte nicht doll ins Gewicht fallen.

7Minuten ScreenOn ist zwar nicht so gut, wenn man ein File machen will. Besser als erstes nach dem Wecker, das bbs speichern.

Wie ich sehe ist das Teil schon über 2 Tage, klingt ewtas abgedroschen, aber wenn ich neustarte vor einer Messung, habe ich immer bessere Werte. Ich Lade das Ding immer voll, starte mit netzteil neu. Danach warte ich 10Minuten und trenne das Netzteil und lass über nacht messen.
So bin ich sicher, das nicht doch noch irgendwelche Reste von Apps im Speicher hängen etc.

Ich wette, nach nem neustart sieht das nächste File besser aus