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

[BananaPing]

Iwt bei mir genauso, was du am ende beschrieben hast, und das log sieht gut aus wahrscheinlich irgendwelche prozesse, die rum-nerven, guck mal mir dem wakelock-detector nach und mit der rom toolbox kann man den autostart leeren, was gut ist, da apps wie angry birds oder ähnliches sonst die ganze zeit im Hintergrund laufen, quch wenn sie nicht im multi-tasking sind

 

[Rob2222]

NOOP ist ein Keep-Alive.

Die Verbindung wird auf TCP Ebene offen gehalten und da sind es halt TCP-KeepAlive Pakete, die dafür sorgen. Erklärung hier. Siehe auch RFC1122.
Eigentlich vollkommen egal, was zählt ist, daß in Intervallen von unter 15 Minuten (weil viele Router TCP Verbindungen nach 15 Minuten droppen) regelmäßig Daten gesendet werden müssen. Und dafür muß das Handy aus dem Deep Sleep kommen und das Funksystem hoch und wieder runterfahren.

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.

Du machst Dich langsam lächerlich, diese Quelle anzuzweifeln. Dann nimm die Version aus dem Google Cache der GSMA Website. Link Ansonsten frag das Dokument eben bei der GSMA an.

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.

Natürlich stammt der von mir. Ich hab's ja auch getestet. Lange vor dieser sinnlosen Diskussion hier. Du sagst mal wieder, stimmt ja gar nicht, _ohne_ ein Beleg anzugeben.
Wie gesagt, die secril-FD Wakelock fallen nicht ins gewicht, da sie fast komplett von den MultiPDP Wakelocks überlappt werden. Erstelle passende Dumps mit BBS und Du kannst es selbst verifizieren. Ich habe das bereits gemacht. Jetzt mach Du es selbst, oder lass das Argument.

Wir leben also alle mit Funkzellen, welche nicht mit "FD-alt" seitens "Handy" klarkommen, nur du nicht.

Funkzellen die mit FD-alt _Probleme_ haben, gibts hier nicht. Oder siehst Du hier Massen von Leuten die mit einem unerklärbaren Akkuverbrauch von 3-5% pro Stunde rumrennen? Die Zeiten sind vorbei.

Du siehst nur Deine Wakelocks, von denen ich schon erklärt habe, wieso sie nicht negativ sind und beharrst darauf, daß man Fast Dormancy deswegen abschalten muss.

Genau wegen solchen Leuten, wird der Mythos weiter hochgehalten...

Aber das macht hier keinen Sinn, mit Dir weiter "zu diskutieren", Du bist in dem Punkt lernresistent, nur noch darauf bedacht Recht zu haben und ziehst offensichtlich nicht mal in Betracht, falsch liegen zu können. Hier ist jede weitere Diskussion und jeder weitere Erklärungsversuch sinnlose Zweitverschwendung.
Das Dokument von der GSMA zum Thema anzuzweifeln...
Lass' gut sein. Macht keinen Sinn.

Gruß
Rob

 

[rotznaas]

Vielen dank für die schnellen antworten.
Hab mal Rom toolbox geladen und einige häkchen weggenommen und der wakelock detector werd ich auch mal im Auge behalten.
Auch für die nächste Messung mach ich das mal wie ihr das geraten habt.
Noch mal danke.

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

 

[S13gfried]

Bei der Romtoolbox kannst du auch (im Autostartmanager) widgets deaktiveren, welche du nicht brauchst. Auch so tolle Einträge wie "Analytics", "billing service" (billingReceiver) etc. natürlich nur, wenn du entsprechende nicht nutzt...

Oder im built.prop Editor den letzten Eintrag (wifi.supplicant_scan_intervall) hoch setzen von 15sekunde auf 300Sekunden. (Habe ich, manche haben auch (viel) mehr).

 

[rotznaas]

Danke.
Hab mal beim autostart manager fast alle häkchen raus genommen außer whatsapp.
Facebook hab ich den push service eh aus, dann kann ich doch die häkchen alle rsus nehmen oder?

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

 

[koboltzz]

Du machst Dich langsam lächerlich, diese Quelle anzuzweifeln. Dann nimm die Version aus dem Google Cache der GSMA Website. Link Ansonsten frag das Dokument eben bei der GSMA an.

Nun, da du jetzt abschließende Worte eingeleitet hast, will ich dies nun auch tun. Wer von uns beiden hat in einem posting viermal von "belastbaren Quellen" geredet und dann Wikipedia angeführt?
Sorry, aber damit hast du dich bereits lächerlich gemacht und ich wollte dich mit dem Hinweis auf slideshare.net nochmal aufziehen. Aber mal im Ernst, das Dokument ist von offizieller Seite nicht mehr verfügbar und das gibt dir nicht zu denken? Nein, antworte bitte nicht darauf.

Natürlich stammt der von mir. Ich hab's ja auch getestet. Lange vor dieser sinnlosen Diskussion hier. Du sagst mal wieder, stimmt ja gar nicht, _ohne_ ein Beleg anzugeben.

Wow Rob, du bist als einziger in den letzten 5 Jahren auf die Idee gekommen, so einen Test zu machen. Alle anderen, sogar die devs bei xda, waren so blöd einfach mal Anleitungen und Apps zum Deaktivieren von FD zu veröffentlichen, ohne theoretische Grundlage. Danke, dass du uns alle erleuchtet hast [Ironie off].

Funkzellen die mit FD-alt _Probleme_ haben, gibts hier nicht. Oder siehst Du hier Massen von Leuten die mit einem unerklärbaren Akkuverbrauch von 3-5% pro Stunde rumrennen? Die Zeiten sind vorbei.

Nee, ich sehe ja auch 10000 - 50000 Leute, die das hier allein letzten Monat installiert haben.

Du hast in einem Punkt recht, es hat keinen Sinn mit dir zu diskutieren, denn du stützt alles auf ein offline genommenes Dokument und einen selbstgemachten Test, der keinerlei Aussagekraft hat. Also lass die Leute hier in Ruhe mit deiner FD-Religion, danke.

 

[S13gfried]

So, war ja doch ganz spannend mit euch beiden
Da bei mir FD aus besser ist als an, bleibt es erstmal so.

Ich fände es jedoch gut, wenn ihr euch nicht so angeht. Argument vs. Gegenargument ist ja gut, aber wenn es dann in Richtung emotionale Komponente geht, verliert es an beiden Seiten an Glaubwürdigkeit. Wobei ich natürlich sagen muss, dass mir eure Antworten jeweils fachlich sehr hoch waren, für mich zu hoch.


@rotznaas:
Bei FB habe ich, seit vorhin, alles Häckchen draußen und es geht noch. Google Suche auch alle draußen, 3gingen allerdigns nicht zu entfernen.
beide Apps funktionieren immer noch.
Was ich jetzt nicht weiß ist, wie es sich mit diesen inApp logins via Facebook verhält.

Bei manchen Apps habe ich auch probleme wenn da was fehlt, vor allem solche mit Widgets (wenn ich sie benutze) und viele mit Synchronisation.
Wenn du einem app die netzwerkstatus Receiver entziehst, weiß es nicht mehr, wenn du im WLAN bist. Z.B. Dropbox Bilderupload "nur im Wlan" dürfte dann nicht mehr funktionieren.

Also, einfach mal probieren. Bei spielen habe ich immer alles draußen. Wenn es mal nich gehen sollte, schalte ich halt ein, ich weiß ja wa ich geändert habe...

Alles aus ist vlt. ein wenig hart.

 

[Rob2222]

Nun, da du jetzt abschließende Worte eingeleitet hast, will ich dies nun auch tun. Wer von uns beiden hat in einem posting viermal von "belastbaren Quellen" geredet und dann Wikipedia angeführt?

Das glaube ich jetzt nicht. Belastbare Quellen waren rein auf das Thema Fast Dormancy bezogen. Und ich denke das weißt Du sehr genau. Zu einem einfachen Thema wie TCP Keep Alive kannst Du Dir binnen Sekunden genügend eigene Quellen recherchieren. Den Wiki Link zum TCP Keep Alive habe ich Dir als Einstiegspunkt für Recherchen mit angeboten. Ich habe erwartet, daß Du zu dem einem einfachen Thema wie TCP Keep Alive massig eigene Quellen findest. Der Wiki Link war nur ein freundlich gemeinter Einstieg.

Mit belastbaren Quellen meinte ich z.B. eben das angesprochene Dokument von der GSM-A, dazu ein White Paper von Nokia Siemens, dazu diverse Blog-Artikel hier, hier, hier und hier von einer Person, die über das Thema Mobilfunk-Netzwerktechnik mehrere Bücher verfasst hat. DAS meine ich mit belastbaren Quellen zum Thema Fast Dormancy.
Und jetzt studiere entweder diese Quellen oder höre bitte auf mir hier den Mund verbieten zu wollen. Das ist doch ein Witz hier. Ich habe diese Dokumente mehrmals durchgearbeitet und da steht es eben so drin.
Ich hatte Dich letztens nach den T1 und T2 Timern Deiner Heimatfunkzelle gefragt und mit welchem Grund-Zustand diese arbeitet (*PCH oder IDLE) ...

EDIT: Ein weiteres, sehr gutes Dokument von Huawei, welches auf die verschiedenen Fast Dormancy Systeme eingeht: Link (Seite 4.1 und Seite 4.2)


Und zum Thema 50.000 Downloads... es dachte auch fast die ganze Community inkl. XDA, daß Löschen der batterystats.bin die Batterieanzeige kalibriert, bis eine Programmiererin von Google, die an der BatteryStats App gearbeitet hat, das wiederlegt hat... Das ist eben das Problem bei so einem Mythos wie Batterystats oder Fast Dormancy... da glauben so viele Leute so fest dran, daß sie gar nicht mehr auf die Idee kommen, daß es evtl. doch nicht so sein könnte...


Gruß
Rob

 

[koboltzz]

Okay, du willst Nachschlag,... du kriegst Nachschlag.

Das glaube ich jetzt nicht. Belastbare Quellen waren rein auf das Thema Fast Dormancy bezogen.

Aha, bei anderen Themen, die du zur Diskussion stellst, reicht also auch Hörensagen? Ich kann dir tausend links zeigen, in denen von NOOP als das Keep-Alive Paket beim IMAP IDLE die Rede ist, nur mal so als freundlich gemeinter Einstieg: Findet man bei google, bing, yahoo etc.

Mit belastbaren Quellen meinte ich z.B. eben das angesprochene Dokument von der GSM-A, dazu ein White Paper von Nokia Siemens, dazu diverse Blog-Artikel hier, hier, hier und hier von einer Person, die über das Thema Mobilfunk-Netzwerktechnik mehrere Bücher verfasst hat.

Liest du dir deine Links überhaupt durch? Ich gehe mal davon aus, dass du weißt, dass Nokia keine Smartphones mit Android herstellt... in dem "White Paper" steht ausdrücklich, dass Android nur eine sehr grundlegende FD-Funktion vorweist.

Und zum Thema 50.000 Downloads... es dachte auch fast die ganze Community inkl. XDA, daß Löschen der batterystats.bin die Batterieanzeige kalibriert, bis eine Programmiererin von Google, die an der BatteryStats App gearbeitet hat, das wiederlegt hat... Das ist eben das Problem bei so einem Mythos wie Batterystats oder Fast Dormancy... da glauben so viele Leute so fest dran, daß sie gar nicht mehr auf die Idee kommen, daß es evtl. doch nicht so sein könnte...

Ja schon verrückt, dass so viele Leute in den Foren einfach rumlügen und screenshots bearbeiten, nur um die Wirksamkeit der FD-Deaktivierung zu demonstrieren...
Lass gut sein, du wirst weiter predigen und ich kläre die Leute auf

 

[Stahlie]

Bin gerade wieder zurück vom LG 4X HD...<<Einfach nur grauenhaft der Akku und auch andere Sachen...Hab jetzt ein S3 mit Miui...Akku absolut super...

 

[user201]

Habe auch von Lg 4x hd auf S3 gewechselt.

Man merkt deutlich den Unterschied der Akkulaufzeit.

Bei dem 4x hd reichte der Akku gerade einmal 9Std.

Beim S3 sind es jetzt 21 Std *-*

 

[rotznaas]

Iwt bei mir genauso, was du am ende beschrieben hast, und das log sieht gut aus wahrscheinlich irgendwelche prozesse, die rum-nerven, guck mal mir dem wakelock-detector nach und mit der rom toolbox kann man den autostart leeren, was gut ist, da apps wie angry birds oder ähnliches sonst die ganze zeit im Hintergrund laufen, quch wenn sie nicht im multi-tasking sind

Hallo nochmal.
Hab die Tipps durchgeführt außer neutstart vorm Anfang der Messung.
Jetzt hatte ich 2,4%/h.
Könnt ihr noch mal drüber schauen?
Danke.

Spoiler

===================
General Information
===================
BetterBatteryStats version: 1.13.4.0
Creation Date: 2013-06-22 08:26:35
Statistic Type: Unplugged to Current
Since 7 h 8 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.: -17% (100% to 83%) [2,4%/h]
Voltage lost [mV]: (4298-4098) [28,0%/h]
===========
Other Usage
===========
Awake (): 7 h 8 m 29 s (25709 s) Ratio: 100,0%
Screen On (): 1 m 40 s (100 s) Ratio: 0,4%
Poor Signal (): 9 m 55 s (595 s) Ratio: 0,7%
Screen dark (): 1 m 40 s (100 s) Ratio: 0,4%
=========
Wakelocks
=========
AlarmManager (Android-System): 1 m 15 s (75 s) Count:566 0,3%
AudioOut_2 (1013): 39 s (39 s) Count:14 0,2%
*sync*_com.google.android.location.reporting_Account {name=a5125242f14770b06e580497ae9a3880, type=com.google} (Google-Dienste): 30 s (30 s) Count:7 0,1%
AWS NW Stats (com.avast.android.mobilesecurity.avast! Mobile Security): 14 s (14 s) Count:86 0,1%
Cleaner (com.oasisfeng.greenify.Greenify): 11 s (11 s) Count:7 0,0%
AlarmManager (com.whatsapp.WhatsApp): 4 s (4 s) Count:23 0,0%
com.google.android.music.leanback.AutoCacheSchedulingService (com.google.android.music.Google Play Music): 2 s (2 s) Count:28 0,0%
Event Log Service (Google-Dienste): 2 s (2 s) Count:21 0,0%
AlarmManager (com.avast.android.mobilesecurity.avast! Mobile Security): 1 s (1 s) Count:43 0,0%
ActivityManager-Launch (Android-System): 1 s (1 s) Count:35 0,0%
BBS_WAKELOCK_WHILE_SAVING_REF (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 1 s (1 s) Count:4 0,0%
RILJ (Telefon): 1 s (1 s) Count:105 0,0%
NetworkStats (Android-System): 1 s (1 s) Count:29 0,0%
*backup* (Android-System): 1 s (1 s) Count:65 0,0%
================
Kernel Wakelocks
================
"secril_rfs-interface" (): 7 h 6 m 48 s (25608 s) Cntc/wc/ec)0/0/0 99,6%
"secril_fd-interface" (): 7 m 56 s (476 s) Cntc/wc/ec)132/0/0 1,9%
"multipdp" (): 7 m 53 s (473 s) Cntc/wc/ec)61/0/61 1,8%
"PowerManagerService" (): 3 m 11 s (191 s) Cntc/wc/ec)839/0/0 0,7%
"l2_hsic" (): 1 m 49 s (109 s) Cntc/wc/ec)365/0/365 0,4%
"rpm_hsic" (): 1 m 37 s (97 s) Cntc/wc/ec)365/0/0 0,4%
"tx_hsic" (): 59 s (59 s) Cntc/wc/ec)703/0/0 0,2%
"battery-monitor" (): 47 s (47 s) Cntc/wc/ec)176/0/176 0,2%
"umts_ipc0" (): 46 s (46 s) Cntc/wc/ec)103/0/103 0,2%
"alarm" (): 13 s (13 s) Cntc/wc/ec)776/0/0 0,1%
"radio-interface" (): 7 s (7 s) Cntc/wc/ec)10/0/0 0,0%
"power-supply" (): 1 s (1 s) Cntc/wc/ec)176/0/0 0,0%
"PowerManagerService.Broadcasts" (): (0 s) Cntc/wc/ec)4/0/0 0,0%
"KeyEvents" (): (0 s) Cntc/wc/ec)1242/0/0 0,0%
"secril_fmt-interface" (): (0 s) Cntc/wc/ec)181/0/0 0,0%
"alarm_rtc" (): (0 s) Cntc/wc/ec)1/0/0 0,0%
"sync_system" (): (0 s) Cntc/wc/ec)2/0/0 0,0%
=========
Processes
=========
jrcud (0): Uid: 0 Sys: 5 s (5 s) Us: (0 s) Starts: 0
gpsd (1021): Uid: 1021 Sys: 3 s (3 s) Us: 1 s (1 s) Starts: 0
s3c-fb-vsync (0): Uid: 0 Sys: 4 s (4 s) Us: (0 s) Starts: 0
rild (Telefon): Uid: 1001 Sys: 3 s (3 s) Us: (0 s) Starts: 0
kworker/0:0 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/0:1 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
kworker/0:2 (0): Uid: 0 Sys: 2 s (2 s) Us: (0 s) Starts: 0
/init (0): Uid: 0 Sys: (0 s) Us: (0 s) Starts: 0
======================
Alarms (requires root)
======================
com.ebay.mobile (): Wakeups: 86
Alarms: 86, Intent: com.ebay.mobile.service.DO_POLL
Alarms: 0, Intent: com.ebay.mobile.service.SET_PREFERENCES

com.android.phone (): Wakeups: 71
Alarms: 71, 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
Alarms: 0, Intent: com.android.internal.telephony.gprs-reconnect.1

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

com.google.android.gsf (): Wakeups: 29
Alarms: 0, Intent: com.google.android.intent.action.SEND_IDLE
Alarms: 15, Intent: com.google.android.intent.action.MCS_HEARTBEAT
Alarms: 14, Intent: {com.google.android.gsf
Alarms: 0, Intent: com.google.android.intent.action.GTALK_RECONNECT

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

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

com.google.android.gms (): Wakeups: 1
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_ACTIVE_COLLECTOR
Alarms: 1, Intent: com.google.android.gms.icing.INDEX_RECURRING_MAINTENANCE
Alarms: 0, Intent: com.google.android.gms.nlp.ALARM_WAKEUP_CACHE_UPDATER

======================
Network (requires root)
======================
10045 (Mobile) (com.android.vending.Google Play Store): 85.0 KBytes 43,8%
10047 (Mobile) (Google-Dienste): 63.0 KBytes 32,8%
10061 (Mobile) (com.whatsapp.WhatsApp): 30.0 KBytes 15,6%
0 (Mobile) (0): 15.0 KBytes 7,9%
==========
CPU States
==========
1,4 GHz (): 3 s 0,0%
1,3 GHz (): 0,0%
1,2 GHz (): 0,0%
1,1 GHz (): 0,0%
1 GHz (): 1 s 0,0%
900 MHz (): 1 s 0,0%
800 MHz (): 12 s 0,0%
700 MHz (): 1 s 0,0%
600 MHz (): 6 m 36 s 1,5%
500 MHz (): 0,0%
400 MHz (): 9 s 0,0%
300 MHz (): 3 m 38 s 0,9%
200 MHz (): 6 h 57 m 42 s 97,5%
========
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.android.phone (com.android.phone.TelephonyDebugService)
Active since: 19 s
Last activity: 19 s
Crash count:0
com.android.smspush (com.android.smspush.WapPushManager)
Active since: 19 s
Last activity: 19 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.pan.PanService)
Active since: 18 s
Last activity: 18 s
Crash count:0
se.catharsis.android.calendar (se.catharsis.android.calendar.UpdateService)
Active since: 23 h 15 m
Last activity: 23 h 15 m 1 s
Crash count:0
com.google.process.gapps (com.google.android.gsf.gtalkservice.service.GTalkServiceProxy)
Active since: 30 s
Last activity: 8 h 8 m 36 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.service.UpdateService)
Active since: 33 s
Last activity: 33 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.locking.core.AppLockingService)
Active since: 21 s
Last activity: 27 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.a2dp.A2dpService)
Active since: 21 s
Last activity: 21 s
Crash count:0
com.android.systemui (com.android.systemui.SystemUIService)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.bel.android.dspmanager (com.bel.android.dspmanager.service.HeadsetService)
Active since: 22 s
Last activity: 22 h 54 m 4 s
Crash count:0
com.google.android.music:main (com.google.android.music.preferences.MusicPreferenceService$MusicPreferenceServiceBinder)
Active since: 23 h 10 m 38 s
Last activity: 23 h 10 m 38 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.messageshield.MessageScannerService)
Active since: 31 s
Last activity: 8 h 8 m 36 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.webshield.WebshieldService)
Active since: 21 s
Last activity: 27 s
Crash count:0
com.android.inputmethod.latin (com.android.inputmethod.latin.LatinIME)
Active since: 19 s
Last activity: 11 h 17 m 38 s
Crash count:0
com.android.systemui (com.android.systemui.ImageWallpaper)
Active since: 19 s
Last activity: 19 s
Crash count:0
com.android.phone (com.android.phone.BluetoothPhoneService)
Active since: 19 s
Last activity: 19 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: 19 s
Last activity: 19 s
Crash count:0
com.jrummy.liberty.toolbox (com.jrummy.billing.BillingService)
Active since: 1 h 24 m 25 s
Last activity: 23 h 17 m 4 s
Crash count:0
com.google.android.music:main (com.google.android.music.store.StoreService$StoreServiceBinder)
Active since: 23 h 10 m 38 s
Last activity: 23 h 10 m 38 s
Crash count:0
com.google.process.location (com.google.android.location.NetworkLocationService)
Active since: 19 s
Last activity: 19 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.trafficinfo.NetworkStatsService)
Active since: 21 s
Last activity: 23 h 20 m 22 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: 23 h 10 m 38 s
Last activity: 23 h 10 m 43 s
Crash count:0
com.whatsapp (com.whatsapp.messaging.MessageService)
Active since: 26 s
Last activity: 23 h 19 m 5 s
Crash count:0
com.google.process.location (com.google.android.location.internal.server.NetworkLocationService)
Active since: 20 s
Last activity: 20 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.scanner.OnDemandScannerScanService)
Active since: 1 h 22 m 21 s
Last activity: 2 h 23 m 13 s
Crash count:0
com.google.android.music:main (com.google.android.music.store.MediaStoreImportService)
Active since: 23 h 10 m 38 s
Last activity: 23 h 10 m 38 s
Crash count:0
com.google.android.music:main (com.google.android.music.playback.MusicPlaybackService)
Active since: 30 s
Last activity: 23 h 10 m 38 s
Crash count:0
com.google.process.location (com.google.android.location.GeocodeService)
Active since: 19 s
Last activity: 19 s
Crash count:0
com.avast.android.mobilesecurity (com.avast.android.mobilesecurity.app.advisor.AdvisorScanService)
Active since: 1 h 22 m 21 s
Last activity: 2 h 23 m 13 s
Crash count:0
com.android.phone (com.android.stk.StkAppService)
Active since: 23 s
Last activity: 23 s
Crash count:0
com.android.nfc:handover (com.android.nfc.handover.HandoverService)
Active since: 19 s
Last activity: 19 s
Crash count:0
system (com.google.android.backup.BackupTransportService)
Active since: 18 s
Last activity: 18 s
Crash count:0
com.google.process.location (com.google.android.location.internal.server.GoogleLocationService)
Active since: 20 s
Last activity: 23 h 10 m 33 s
Crash count:0
com.oasisfeng.greenify:service (com.oasisfeng.greenify.CleanerService)
Active since: 27 s
Last activity: 22 h 56 m 58 s
Crash count:0
com.google.android.music:main (com.google.android.music.download.DownloadQueueService)
Active since: 23 h 10 m 38 s
Last activity: 23 h 10 m 43 s
Crash count:0
com.google.process.gapps (com.google.android.gsf.gtalkservice.service.GTalkService)
Active since: 30 s
Last activity: 2 h 23 m 12 s
Crash count:0
net.nurik.roman.dashclock (com.google.android.apps.dashclock.DashClockService)
Active since: 28 s
Last activity: 23 h 15 m
Crash count:0
com.google.android.music:main (com.google.android.music.download.cache.CacheService)
Active since: 23 h 10 m 38 s
Last activity: 23 h 10 m 43 s
Crash count:0
com.android.bluetooth (com.android.bluetooth.hfp.HeadsetService)
Active since: 20 s
Last activity: 20 s
Crash count:0
==================
Reference overview
==================
ref_boot: Reference ref_boot created 27 s (Wl: 0 elements; KWl: 0elements; NetS: 7 elements; Alrm: null; Proc: 0 elements; Oth: 0 elements; CPU: 12 elements)
ref_unplugged: Reference ref_unplugged created 16 h 13 m 59 s (Wl: 0 elements; KWl: 23elements; NetS: 32 elements; Alrm: 12 elements; Proc: 0 elements; Oth: 3 elements; CPU: 13 elements)
ref_charged: Reference ref_charged created 16 h 13 m 59 s (Wl: 0 elements; KWl: 23elements; NetS: 32 elements; Alrm: 12 elements; Proc: 0 elements; Oth: 3 elements; CPU: 13 elements)
ref_custom: Reference ref_custom created 23 h 22 m 24 s (Wl: 14 elements; KWl: 23elements; NetS: 32 elements; Alrm: 12 elements; Proc: 8 elements; Oth: 4 elements; CPU: 13 elements)
ref_current: Reference ref_current created 23 h 22 m 28 s (Wl: 14 elements; KWl: 23elements; NetS: 32 elements; Alrm: 12 elements; Proc: 8 elements; Oth: 4 elements; CPU: 13 elements)

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

 

[BananaPing]

Ich sehe, dass du keine sekunde deepsleep hast... durch:
Secril_rfs-interface
Was das ist weiß ich leider nicht genau, weiß das jemand anders? Weil nun lief dein gerät zwar die ganze zeit perfekt, auf niedrigst (200hz) aber deepsleep ist noch um einiges sparender. Steht was im wakelock-detector?

 

[S13gfried]

Da hat er sich mit 2,4%/h noch ganz gut geschlagen

Ich habe jetzt mehrmals fastdormancy als gefunden als Fehlerbehebung, oder ein unpassendes Modem zur RIL:

[ROM][4.2.2]Slim Bean - i9300-[STABLE] [Build 6] - Page 183 - xda-developers

Aber nur eine Vermutung. Vlt. hat sich auch etwas aufgehangen und redert am Akku. Weil 100% Awake passiert auch durch FD nicht. Wobei ich in dem Forum hier ehr die Erfahrung mit anderen Wakelocks bezüglich FD gemacht habe.

Starte neu und mach den dalvik und Cache Partition im Recovery platt und mach mal nur ne Stunde danach ein bbs und gucke, ob das Teil bestehen bleibt. Wenn nicht, war es nur ein temporäres Problem.

Falls dann immer noch würde ich zuerst das Modem checken vor FD deaktivieren.

 

[Rob2222]

Ich kann dir tausend links zeigen, in denen von NOOP als das Keep-Alive Paket beim IMAP IDLE die Rede ist, nur mal so als freundlich gemeinter Einstieg: Findet man bei google, bing, yahoo etc.

Ich habe das Gefühl, Du hast gar keine Motivation Dich selbst anzulesen... Also hier eine vollständige Erklärung:
Keep-Alive (allgemein) ist ein System, um eine Verbindung aufrecht/am Leben zu erhalten. Keep-Alive (allgemein) an sich gibt es also durchaus an vielen verschiedenen Stellen.

Im Falle IMAP läuft das IMAP Protokoll über ("durch") eine TCP Verbindung.
Laut rfc3501 ist die minimale Autologout-Zeit für einen IMAP Server mit 30 Minuten vorgegeben. Also muß alle 29 Minuten irgendeine Kommando (z.B. NOOP) gesendet werden, damit der IMAP-Server den Client nicht automatisch ausloggt. Das System kannst Du durchaus als Keep Alive System bezeichnen.

Allerdings kannst Du nach 29 Minuten Inaktivität nicht einfach ein NOOP senden, da die "äußere" TCP Verbindung nach 29 Minuten schon von irgendeinem Router unterwegs geschlossen wurde. Und damit das nicht passiert, mußt Du eben wesentlich öfter ein Keep-Alive Paket auf TCP Ebene senden. Damit ist eben NOOP kein TCP-Keep-Alive Paket, da TCP auch hundert andere Anwendungsfälle hat, wo es nicht mal ein NOOP gibt und trotzdem ein TCP-Keep-Alive gesendet werden muss.

Liest du dir deine Links überhaupt durch? Ich gehe mal davon aus, dass du weißt, dass Nokia keine Smartphones mit Android herstellt... in dem "White Paper" steht ausdrücklich, dass Android nur eine sehr grundlegende FD-Funktion vorweist.

Nokia-Siemens Networks baut UMTS Netwerkinfrastruktur, das ist sogar noch seriöser einzustufen als ein "nur" Handyhersteller. Aber Guter Abschnitt! Denn genau da steht, daß viele Android Geräte, die Januar 2011 (Datum des Dokuments) aktiv im Markt funkten (also Geräte die 2008-2010 gebaut wurden) das, wie Du schon sagst, relativ grundlegende FD-alt nutzen und daß es bei diesem System vollkommen egal ist, ob die Zelle das unterstützt oder nicht.

Wenn ich Dich richtig verstehe, meinst Du, daß alle unsere Zellen nicht zu Fast Dormancy (welche Version auch immer) kompatibel sind, und deswegen bös akkusaugende Wakelocks auftreten und man deswegen Fast Dormancy unbedingt abschalten muss.

Dem ist aber halt definitiv nicht so. 99% der Smartphone-User schauen nicht in Foren rum sondern benutzen ihr Handy auf Werkseinstellungen. Und da gibt es einfach keine Probleme mehr. Wäre Fast-Dormancy ein Akkufresser hätte ihn Samsung abgeschaltet. Da kannst Du sicher sein.

Lass gut sein, du wirst weiter predigen und ich kläre die Leute auf

Ja, Du kläre mal auf mit einem Mythos aus der Fast Dormancy Entstehungszeit wo es vor Ewigkeiten vielleicht mal Probleme gab. Nur gibt es die eben seit zwei, drei Jahren nicht mehr, seit dem die 3GPP-R8 Standardisierung durch ist und in das Netz und die Geräte ausgerollt wurde. (Link)
Das ist halt das Problem bei einem Mythos, viele Leute glauben fest daran und plappern diesen so fest überzeugt weiter, daß der Mythos auch nicht ausstirbt. Deswegen halt Mythos. Jetzt kann man nur hoffen, daß die Leute dann mal ihren Kopf einschalten und hinterfragen, ob das denn überhaupt immernoch so ist. Alleine die Ironie, ein EnergieSPARfeature abschalten zu sollen, um Energie zu sparen, sollte einen hellhörig werden lassen.

Ich hab Dir jetzt genug Dokumente vorgelegt, die belegen, daß Fast Dormancy seit der 3GPP-R8 Standardisierung 2008 ein sehr intelligentes System ist, daß einzig und alleine dazu dient Akku zu sparen. Jetzt, Mitte 2013, wo wohl 95% der Geräte am Markt die intelligenteste Version von 3GPP-R8 unterstützen, gibt es damit keine Probleme mehr.

Warum die FD-Wakelocks, die bei dem System anfallen, nicht ins Gewicht fallen, weil das System wegen dem Datentransfer eh schon wach ist (MultiPDP und L2_hsic), habe ich Dir auch schon erklärt. Das kannst Du auch selbst verifizieren.
Übrigens sind diese FD-Wakelocks, ganz normale Kernel Wakelocks die im laufenden Betrieb bei Datenverkehr anfallen, wie MultiPDP und L2_Hsic.
Dann könnte man genauso sagen, Datenverkehr erzeugt MultiPDP Wakelocks, schaltet alle Datenverkehr ab.

Du könntest halt mal auf das Angebot eingehen, Deine Funkzelle zu analysieren.
Vielleicht würde sich ja herausstellen, daß sie bereits netzwerkseitig fast dormant konfiguriert ist und sie sich unabhängig von den FD-Parametern im Handy absolut gleich verhält.

PS: Bei meiner Vodafone-Zelle hier ist das übrigens der Fall.

Gruß
Rob

 

[Cirno]

Könnt ihr noch mal drüber schauen?

Der Hauptfehler wurde ja schon gefunden und wird noch analysiert...aber die eBay App würde ich auch weglassen ODER in greenify reinballern

 

[BananaPing]

Ja das ist mir auch aufgefallen, aber da das der alarm ist war das wahrscheinlich für eine Auktion gewesen das das die ganze zeit alarm und wakelock macht halte ich für unwahrscheinlich und wenn er die greenifyet, kriegt er die alarme nicht mehr

 

[Cirno]

Ich bin bei den Apps mittlerweile skeptisch seit Facebook.
Ich kann mir auch vorstellen, dass die konstant sendet...einfach weil sie es kann

 

[S13gfried]

Ebay app ist genauso schlimm wie Facebook, wenn man angemeldet ist. Egal ob eine Auktion läuft oder nicht... Abmelden on der app hilft hierbei weiter. Und /oder greenify schadet nicht. Dann kommt ggf. Aber auch keine gewollte Benachrichtigung durch...

 

[koboltzz]

Allerdings kannst Du nach 29 Minuten Inaktivität nicht einfach ein NOOP senden, da die "äußere" TCP Verbindung nach 29 Minuten schon von irgendeinem Router unterwegs geschlossen wurde. Und damit das nicht passiert, mußt Du eben wesentlich öfter ein Keep-Alive Paket auf TCP Ebene senden.

Du wiederholst dich. Lies zum Beispiel hier nach.

Ich habe allerdings keine Lust mehr, mich zu wiederholen. Es gibt hunderte BBS screenshots bei xda VOR und NACH dem Einsatz von dieser App, welche wiederholt die Wirksamkeit belegen. Adieu