sel3 schrieb:
Ich habe den Übeltäter glaube ich gefunden
Laut "Datennutzung" unter den Einstellung hat "Samsung Push Service" im Hintergrund 653mb übertragen
Kann ich das einfach deinstallieren? Habe Root + Titanium Backup Pro
Für was braucht man das?
Huhu,
ich vermute Du hast unter Konten und Syncronisierung, Samsung Konto, Backup zu Samsung Servern eingestellt. Das ist die Samsung eigene Backup Lösung.
Wenn die aber erst mal die Hauptdaten übertragen hat, denke ich wird die nicht mehr viel Daten übertragen. Also mußt Du eigentlich nicht zwingend was ändern.
Gruß
Rob
Der ursprüngliche Beitrag von 12:40 Uhr wurde um 13:28 Uhr ergänzt:
Kleiner Exkurs zum Thema Kernel Wakelocks:
Was ist ein Wakelock überhaupt? Ein System, daß sicherstellt, daß die CPU für einen gewissen Zeitraum nicht in den Standby geht.
Normalerweise geht die CPU in einem Smartphone sofort in den Standby, sobald der Bildschirm ausgeschaltet wird. Das ist aber von Nachteil, da gewisse Dinge schon funktionieren sollen, wie z.B. Facebook Benachrichtigungen.
Also mal am Beispiel Facebook, das Handy ist im Standby. Über einen Alarm soll Facebook um 12:00Uhr schauen, ob es neue Meldungen gibt. Durch den Alarm wird die CPU um 12:00 geweckt und Facebook benachrichtigt, daß es Zeit ist, auf neue Nachrichten zu checken. (Das Display bleibt aus).
Facebook übernimmt nun und muß sofort ein Wakelock setzen, da sonst die CPU wieder in den Standby geht. Facebook setzt ein Wakelock, z.B. 1 Minute und verbindet sich zum Server und schaut nach neuen Nachrichten. Das hat Facebook nach z.b. 33 Sekunden beendet und dann kann Facebook den Facebook-Wakelock auch schon vorzeitig löschen. (Würde Facebook nun abstürzen, würde der Wakelock nach 1 Minute automatisch von Android gelöscht)
Was sind nun Kernel-Wakelocks? Prinzipiell das selbe, nur daß es Wakelocks vom Android-Betriebssystemkern (Kernel) sind. Das Problem für unsere Betrachtungen hier ist, daß Kernel-Wakelocks durchaus parallel gezählt werden. Zum Beispiel sichert sich das WLAN-System für eine Minuten die CPU. Jetzt spingt aber der Battery-Monitor gleich mit an, weil das S3 eh schon wach ist. Nach einer Minuten gehen beide wieder aus. In den Kernel Wakelocks erscheint nun 1 Minute WLAN und 1 Minute battery-monitor, aber das geschah in dem geschilderten Beispiel
zeitgleich. Bzw. der battery-monitor hätte
kein ein Wakelock erzeugt, wenn das S3 nicht durch den WLAN Wakelock eh schon wach gewesen wäre.
Prinzipiell ist es bei den Kernel Wakelocks also schwer zu sagen,
welcher Wakelock ist die Ursache, und welcher
Wakelock ist nur Effekt.
Hier mal ein Beispiel meiner Kernel-Wakelocks der letzten Nacht:
(Man könnte nun denken, daß battery-monitor für 9 Minuten Wach-Zeit verantwortlich ist. Ist es aber nicht...)
Code:
================
Kernel Wakelocks
================
"battery-monitor" (): 9 m 16 s (556 s) Cnt:(c/wc/ec)553/0/553 2,1%
"wlan_rx_wake" (): 8 m 37 s (517 s) Cnt:(c/wc/ec)336/0/336 1,9%
"l2_hsic" (): 5 m 45 s (345 s) Cnt:(c/wc/ec)612/158/612 1,3%
"alarm_rtc" (): 5 m 10 s (310 s) Cnt:(c/wc/ec)425/80/219 1,2%
"PowerManagerService" (): 4 m 16 s (256 s) Cnt:(c/wc/ec)730/0/0 1,0%
"alarm" (): 2 m 18 s (138 s) Cnt:(c/wc/ec)740/4/0 0,5%
"wlan_wake" (): 46 s (46 s) Cnt:(c/wc/ec)14606/159/0 0,2%
"umts_rfs0" (): 20 s (20 s) Cnt:(c/wc/ec)7/0/7 0,1%
"rpm_hsic" (): 11 s (11 s) Cnt:(c/wc/ec)55/0/0 0,0%
"AudioOutLock" (): 8 s (8 s) Cnt:(c/wc/ec)3/0/0 0,0%
"umts_ipc0" (): 3 s (3 s) Cnt:(c/wc/ec)23/0/23 0,0%
"efsd-interface" (): 1 s (1 s) Cnt:(c/wc/ec)14/0/0 0,0%
"secril_rfs-interface" (): 1 s (1 s) Cnt:(c/wc/ec)7/0/0 0,0%
"power-supply" (): (0 s) Cnt:(c/wc/ec)603/98/0 0,0%
"tx_hsic" (): (0 s) Cnt:(c/wc/ec)111/0/0 0,0%
"mmc1_detect" (): (0 s) Cnt:(c/wc/ec)708/0/0 0,0%
"sync_system" (): (0 s) Cnt:(c/wc/ec)1/0/0 0,0%
"KeyEvents" (): (0 s) Cnt:(c/wc/ec)889/0/0 0,0%
"mmc0_detect" (): (0 s) Cnt:(c/wc/ec)708/0/0 0,0%
"secril_fmt-interface" (): (0 s) Cnt:(c/wc/ec)78/0/0 0,0%
Dem Problem, daß man nun nicht weiß, welcher Kernel-Wakelock die Ursache ist, hat sich ein findiger Developer bei den XDA-Devs angenommen und einen Kernel-Patch geschrieben, der für jede Sekunde nur den verursachenden Kernel-Wakelock loggt. Die Kernel-Wakelocks, die nur aktiv sind, weil das Handy eh schon wach ist, werden nicht mit einberechnet.
Diesen Patch hat z.B. der Siyah Kernel eingebait und die Funktion kann man mit den S-Tweaks aktivieren.
Das heißt, in diesem Modus werden nur noch die Kernel-Wakelocks angezeigt, die
der Grund/die Ursache sind, daß das Handy gerade wach ist.
Hier mal die Kernel-Wakelocks
der selben Nacht(!) im
diskreten Kernel Wakelock Modus.
Code:
===================================
Kernel Wakelocks (!!! discrete !!!)
===================================
"wlan_rx_wake" (): 4 m 47 s (287 s) Cnt:(c/wc/ec)267/0/267 1,1%
"battery-monitor" (): 2 m 25 s (145 s) Cnt:(c/wc/ec)192/0/192 0,5%
"l2_hsic" (): 2 m 23 s (143 s) Cnt:(c/wc/ec)238/157/238 0,5%
"PowerManagerService" (): 1 m 24 s (84 s) Cnt:(c/wc/ec)91/0/0 0,3%
"alarm_rtc" (): 49 s (49 s) Cnt:(c/wc/ec)182/80/87 0,2%
"wlan_wake" (): 28 s (28 s) Cnt:(c/wc/ec)472/159/0 0,1%
"alarm" (): 24 s (24 s) Cnt:(c/wc/ec)202/4/0 0,1%
"umts_rfs0" (): 2 s (2 s) Cnt:(c/wc/ec)1/0/1 0,0%
"umts_ipc0" (): (0 s) Cnt:(c/wc/ec)2/0/2 0,0%
"power-supply" (): (0 s) Cnt:(c/wc/ec)102/98/0 0,0%
Hier sieht man nun schön, wie viele Kernel-Wakelocks nun gar nicht mehr gelistet sind, weil sie nur Nebeneffekt-Wakelocks waren. Nämlich alle die, die jetzt auf einmal fehlen. Jetzt sieht man sehr schön, daß WLAN der Hauperzeuger der Wach-Zeit war und daß Battery-Monitor hauptsächlich ein Nebeneffekt ist, der einsetzt, weil WLAN das Handy augeweckt hat.
Fazit: Beim Auswerten der normalen, nichtdiskreten Kernel-Wakelocks muß man versuchen mit Erfahrung zu "sehen", welche Wakelocks die echte Ursache und welche Kernel-Wakelocks nur Nebeneffekt waren.
PS: Wichtig: BBS kann (noch) nicht mit gemischten Referenzen arbeiten. Ihr müßt dafür sorgen, daß die Referenz-Modis übereinstimmen. Erzeugt ihr durch An- und Abstecken eine "unplugged" Referenz im normalen, nichtdiskreten Modus, schaltet danach über S-Tweaks auf den diskrekten Wakelockmodus um, und geht dann in BBS, dann vergleicht BBS z.B. bei "since unplugged" die aktuellen diskreten Statistiken gegen die nichtdiskrete-Referenz. Da kommt nur Müll bei raus!
Und weils gerade passt noch eine Info, wenn man eine BBS Messung macht, darf man das Handy nicht neustarten, da das Neustarten die Statistiken verwurschtelt.
Gruß
Rob
