Batteriestatus - Akkufresser finden

  • Antworten:39
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 10:51:16 via Website

Guten Morgen zusammen,

Weil die Batterie Thematik scheinbar immer noch sehr auf Interesse stößt hab ich mich heute Morgen einmal ein wenig näher mit dem Bugreport des Android beschäftigt, aus dem zu diesem Thema sehr viel herauszulesen ist.

Um das anschaulich erklären zu können, habe ich heute einen aktuellen Bugreport erstellt, aus dem ich später einige Auszüge zeigen werde.

Der Bugreport eines Android Handys kann mit dem ADB Tool erstellt werden, dass Bestandteil des Android SDK ist. Bei installiertem SDK und vorhandenem SystemPfad auf das SDK/Tools Verzeichnis sowie per USB an den PC angeschlossenem Handy gibt man folgenden Befehl auf der CMD (Commandline/DOS-Box...) ein:

adb bugreport > bugreport.txt

Nun befindet sich in dem aktuellen Verzeichnis (in dem die CMD gestartet wurde) eine Datei namens bugreport.txt die man mit einem beliebiegen Texteditor öffnen kann.

Vorab jedoch einige Punkte um Missverständnisse zu vermeiden:
  1. Bugreports können auf anderen Handymodellen ggf. anders aussehen
  2. Was ich hier beschreibe ist nicht gesichert, da der Bugreport nicht dokumentiert ist, ich interpretiere nur mit meinem vorhandenen Wissen
  3. Man sollte keine Apps verteufeln aufgrund der Ergebnisse (dazu später mehr)

Der Bugreport enthält extrem viel Informationen zu den internen Abläufen in unseren geliebten Androids :)
Diese Informationen sind sehr technisch und basieren darüber hinaus auf Dingen die das Linux Betriebsystem des Android vorgibt und verwaltet.
Bis auf wenige Ausnahmen, ist mir zur Zeit kein anderer Weg bekannt um an derart detailierte Informationen aus dem Handy heranzukommen. Die meisten diese hier zu findenden Informationen verlangen Aufrufe von intern gehaltenen APIs an die auf normalem Weg (ohne Root und sonstige Kniffe) nicht heranzukommen ist.

Zur Sache:
Hat man den Bugreport wie oben beschrieben erstellt, öffnet man das bugreport.txt File und sucht im Text nach fogendem String: "Unplugged Statistics"
Hinter diesem Abschnitts Bezeichner werden die Vorgänge seit Beendigung des letzten Ladevorgangs (Also dem abziehen vom Ladegerät oder trennen der USB Verbindung zum PC) sehr detailgetreu dargestellt. Insbesondere in Hinblick auf die Vorgänge der einzelnen Applikationen und deren Auswirkung auf die Batterieressourcen.

Folgender Auszug aus dem Bugreport:
1Unplugged Statistics (Since last unplugged from power):
2
3 Time on battery: 7h 24m 9s 124ms (88.7%) realtime, 18m 49s 325ms (3.8%) uptime
4
5 Total run time: 8h 20m 52s 569ms realtime, 1h 15m 32s 770ms uptime,
6
7 Screen on: 2m 8s 269ms (0.5%), Input events: 156, Active phone call: 0ms (0.0%)
8
9 Screen brightnesses: dark 7s 373ms (5.7%), medium 2m 0s 897ms (94.3%)
10
11 Total received: 60.41KB, Total sent: 91.52KB
12
13 Total full wakelock time: 1s 759ms , Total partial waklock time: 15m 4s 397ms
14
15 Signal levels: good 471ms (0.0%) 2x, great 7h 24m 8s 653ms (100.0%) 0x
16
17 Radio types: none 17m 12s 68ms (3.9%) 2x, umts 7h 6m 57s 56ms (96.1%) 2x
18
19 Wifi on: 7h 24m 9s 124ms (100.0%), Wifi running: 23m 26s 582ms (5.3%), Bluetooth on: 7h 24m 9s 124ms (100.0%)
20
21
22
23 Device is currently plugged into power
24
25 Last discharge cycle start level: 100
26
27 Last discharge cycle end level: 97
28
29
30
31 #1000:
32
33 Network: 32.65KB received, 65.15KB sent
34
35 User activity: 4 other, 30 long_touch, 24 touch_up
36
37 Turned Wifi On Time: 0ms (0.0%)
38
39 Full Wifi Lock Time: 0ms (0.0%)
40
41 Scan Wifi Lock Time: 5m 35s 631ms (1.3%)
42
43 Wake lock WifiService: 5m 54s 640ms partial (51 times) realtime
44
45 Wake lock ActivityManager-Launch: (nothing executed)
46
47 Wake lock PreventScreenOn Partial: (nothing executed)
48
49 Wake lock StayOnWhilePluggedIn Partial: 188ms partial (1 times) realtime
50
51 Wake lock keyguard: 1s 390ms full (1 times) realtime
52
53 Wake lock CheckinService: 9s 710ms partial (1 times) realtime
54
55 Wake lock ActivityManager-Sleep: 47ms partial (1 times) realtime
56
57 Wake lock NotificationService: 319ms partial (1 times) realtime
58
59 Wake lock SyncManagerHandleSyncAlarmWakeLock: 398ms partial (1 times) realtime
60
61 Wake lock HardwareService: 325ms partial (1 times) realtime
62
63 Wake lock StayOnWhilePluggedIn Screen Dim: 369ms full (1 times) realtime
64
65 Wake lock window: (nothing executed)
66
67 Wake lock keyguardWakeAndHandOff: 5ms partial (1 times) realtime
68
69 Wake lock SCREEN_FROZEN: (nothing executed)
70
71 Wake lock sleep_broadcast: 360ms partial (3 times) realtime
72
73 Wake lock SyncManagerSyncWakeLock: 6s 385ms partial (1 times) realtime
74
75 Wake lock AlarmManager: 14s 60ms partial (170 times) realtime
76
77 Wake lock LocationManagerService: 4m 27s 528ms partial (48 times) realtime
78
79 Wake lock UpdateVerifier: (nothing executed)
80
81 Sensor 0: 2m 8s 309ms realtime (1 times)
82
83 Proc system:
84
85 CPU: 1m 49s 840ms user + 21s 660ms kernel
86
87 0 process starts
88
89 Apk com.android.providers.subscribedfeeds:
90
91 Service com.android.providers.subscribedfeeds.SubscribedFeedsIntentService:
92
93 Created for: 187ms uptime
94
95 Starts: 1, launches: 1
96
97 Apk com.google.android.server.checkin:
98
99 1 wakeup alarms
100
101 Service com.google.android.server.checkin.CheckinService:
102
103 Created for: 18m 49s 325ms uptime
104
105 Starts: 0, launches: 0
106
107 Apk android:
108
109 51 wakeup alarms
110
111 #1001:
112
113 Network: 8.33KB received, 10.33KB sent
114
115 Wake lock SMSDispatcher: (nothing executed)
116
117 Wake lock window: (nothing executed)
118
119 Wake lock GSM: (nothing executed)
120
121 Wake lock ScoSocket: (nothing executed)
122
123 Wake lock PhoneApp: (nothing executed)
124
125 Wake lock HeadsetBase: (nothing executed)
126
127 Wake lock RILJ: 8s 28ms partial (109 times) realtime
128
129 Wake lock BT HS/HF:StartCall: (nothing executed)
130
131 Proc com.android.phone:
132
133 CPU: 1s 160ms user + 840ms kernel
134
135 0 process starts
136
137 Apk com.android.phone:
138
139 Service com.android.phone.BluetoothHeadsetService:
140
141 Created for: 18m 49s 325ms uptime
142
143 Starts: 0, launches: 0
144
145 Apk com.android.stk:
146
147 Service com.android.stk.StkAppService:
148
149 Created for: 18m 49s 325ms uptime
150
151 Starts: 0, launches: 0
152
153 #10000:
154
155 Wake lock window: (nothing executed)
156
157 Wake lock Browser: (nothing executed)
158
159 #10001:
160
161 Wake lock window: (nothing executed)
162
163 Wake lock AlarmClock: (nothing executed)
164
165 Apk com.android.alarmclock:
166
167 (nothing executed)
168
169 #10002:
170
171 (nothing executed)
172
173 #10003:
174
175 Wake lock window: (nothing executed)
176
177 Apk com.voss.nostalk:
178
179 Service com.voss.nostalk.CallListener:
180
181 Created for: 0ms uptime
182
183 Starts: 1, launches: 1
184
185 #10004:
186
187 Wake lock window: (nothing executed)
188
189 Wake lock CalendarAppWidgetProvider: (nothing executed)
190
191 Wake lock StartingAlertService: (nothing executed)
192
193 Apk com.android.providers.calendar:
194
195 (nothing executed)
196
197 Apk com.android.calendar:
198
199 (nothing executed)
200
201 #10005:
202
203 Wake lock window: (nothing executed)
204
205 Proc android.process.acore:
206
207 CPU: 600ms user + 350ms kernel
208
209 0 process starts
210
211 Proc com.android.inputmethod.latin:
212
213 CPU: 30ms user + 60ms kernel
214
215 0 process starts
216
217 Apk com.android.inputmethod.latin:
218
219 (nothing executed)
220
221 #10006:
222
223 Wake lock window: (nothing executed)
224
225 Wake lock DownloadManager: (nothing executed)
226
227 Wake lock MediaScannerService: (nothing executed)
228
229 Wake lock ImageGallery2.checkThumbnails: (nothing executed)
230
231 Sensor GPS: (not used)
232
233 Sensor 0: (not used)
234
235 Proc android.process.media:
236
237 CPU: 1s 30ms user + 100ms kernel
238
239 1 process starts
240
241 Apk com.android.providers.downloads:
242
243 Service com.android.providers.downloads.DownloadService:
244
245 Created for: 1s 87ms uptime
246
247 Starts: 2, launches: 2
248
249 Apk com.android.providers.media:
250
251 (nothing executed)
252
253 #10007:
254
255 Wake lock window: (nothing executed)
256
257 Apk com.android.email:
258
259 (nothing executed)
260
261 #10008:
262
263 Wake lock window: (nothing executed)
264
265 Proc com.google.android.gm:
266
267 CPU: 0ms user + 0ms kernel
268
269 1 process starts
270
271 #10009:
272
273 Network: 11.03KB received, 6.81KB sent
274
275 Wake lock GTALK_CONN: 2s 72ms partial (57 times) realtime
276
277 Wake lock GTALK_DATA_MSG: 1s 192ms partial (1 times) realtime
278
279 Wake lock GTALK_ASYNC_CONN: 10s 529ms partial (4 times) realtime
280
281 Wake lock GmailProviderProviderChangedBroadcastWakeLock: 1s 329ms partial (1 times) realtime
282
283 Proc com.google.process.gapps:
284
285 CPU: 12s 590ms user + 1s 110ms kernel
286
287 0 process starts
288
289 Apk com.google.android.googleapps:
290
291 (nothing executed)
292
293 Apk com.google.android.apps.gtalkservice:
294
295 17 wakeup alarms
296
297 Service com.google.android.gtalkservice.service.GTalkService:
298
299 Created for: 18m 49s 325ms uptime
300
301 Starts: 0, launches: 0
302
303 Apk com.google.android.providers.gmail:
304
305 (nothing executed)
306
307 #10010:
308
309 (nothing executed)
310
311 #10011:
312
313 Network: 8.40KB received, 9.23KB sent
314
315 Wake lock window: (nothing executed)
316
317 Wake lock LocationFriendService: 23s 29ms partial (9 times) realtime
318
319 Wake lock BackgroundFriendService: (nothing executed)
320
321 Sensor GPS: (not used)
322
323 Proc com.google.android.apps.maps:LocationFriendService:
324
325 CPU: 6s 720ms user + 1s 470ms kernel
326
327 6 process starts
328
329 Proc com.google.android.apps.maps:BackgroundFriendService:
330
331 CPU: 1s 60ms user + 350ms kernel
332
333 4 process starts
334
335 Apk com.google.android.apps.maps:
336
337 9 wakeup alarms
338
339 Service com.google.googlenav.friend.android.BackgroundFriendService:
340
341 Created for: 8s 388ms uptime
342
343 Starts: 9, launches: 9
344
345 Service com.google.googlenav.friend.android.LocationFriendService:
346
347 Created for: 59s 164ms uptime
348
349 Starts: 48, launches: 48
350
351 #10012:
352
353 Wake lock window: (nothing executed)
354
355 Wake lock StartingAlertService: (nothing executed)
356
357 Proc com.android.mms:
358
359 CPU: 380ms user + 80ms kernel
360
361 1 process starts
362
363 Apk com.android.mms:
364
365 Service com.android.mms.transaction.TransactionService:
366
367 Created for: 410ms uptime
368
369 Starts: 2, launches: 2
370
371 #10013:
372
373 Wake lock window: (nothing executed)
374
375 Wake lock com.android.music.MediaPlaybackService: (nothing executed)
376
377 Wake lock android.media.MediaPlayer: (nothing executed)
378
379 Apk com.android.music:
380
381 Service com.android.music.MediaPlaybackService:
382
383 Created for: 18m 49s 325ms uptime
384
385 Starts: 0, launches: 0
386
387 #10014:
388
389 (nothing executed)
390
391 #10015:
392
393 (nothing executed)
394
395 #10019:
396
397 (nothing executed)
398
399 #10021:
400
401 (nothing executed)
402
403 #10022:
404
405 Wake lock window: (nothing executed)
406
407 Apk com.android.vending:
408
409 (nothing executed)
410
411 #10024:
412
413 Wake lock window: (nothing executed)
414
415 #10025:
416
417 Wake lock window: (nothing executed)
418
419 #10026:
420
421 Wake lock window: (nothing executed)
422
423 Wake lock MyTracks: (nothing executed)
424
425 Sensor GPS: (not used)
426
427 Sensor 2: (not used)
428
429 Apk com.google.android.maps.mytracks:
430
431 (nothing executed)
432
433 #10027:
434
435 Apk com.google.tts:
436
437 (nothing executed)
438
439 #10028:
440
441 (nothing executed)
442
443 #10029:
444
445 Wake lock window: (nothing executed)
446
447 Sensor 0: (not used)
448
449 Sensor GPS: (not used)
450
451 Sensor 1: (not used)
452
453 Sensor 2: (not used)
454
455 #10030:
456
457 Wake lock net.jaqpot.netcounter.service.NetCounterService: 3m 24s 254ms partial (138 times) realtime
458
459 Proc net.jaqpot.netcounter:
460
461 CPU: 3m 39s 510ms user + 5s 960ms kernel
462
463 0 process starts
464
465 Apk net.jaqpot.netcounter:
466
467 Service net.jaqpot.netcounter.service.NetCounterService:
468
469 Created for: 18m 49s 325ms uptime
470
471 Starts: 0, launches: 0
472
473 #10031:
474
475 Wake lock com.twofortyfouram.common.WAKE_LOCK: (nothing executed)
476
477 Wake lock WifiService: (nothing executed)
478
479 Wake lock window: (nothing executed)
480
481 Sensor GPS: (not used)
482
483 Apk edu.mit.locale:
484
485 (nothing executed)
486
487 #10032:
488
489 Wake lock window: (nothing executed)
490
491 #10033:
492
493 Wake lock RemoteDroid: (nothing executed)
494
495 Sensor 0: (not used)
496
497 Sensor 1: (not used)
498
499 #10034:
500
501 (nothing executed)
502
503 #10035:
504
505 Wake lock window: (nothing executed)
506
507 Wake lock Importing: (nothing executed)
508
509 Sensor GPS: (not used)
510
511 Sensor 2: (not used)
512
513 #10036:
514
515 Wake lock window: (nothing executed)
516
517 Sensor 1: (not used)
518
519 #10037:
520
521 Wake lock window: (nothing executed)
522
523 #10038:
524
525 Wake lock window: (nothing executed)
526
527 Apk com.google.android.netmeter:
528
529 (nothing executed)
530
531 #10039:
532
533 (nothing executed)
534
535 #10040:
536
537 Apk com.google.android.apps.uploader:
538
539 (nothing executed)
540
541 #10041:
542
543 (nothing executed)
544
545 #10042:
546
547 Sensor GPS: (not used)
548
549 Sensor 2: (not used)
550
551 #10043:
552
553 Wake lock WifiService: (nothing executed)
554
555 Sensor GPS: (not used)
556
557 Sensor 0: (not used)
558
559 Sensor 1: (not used)
560
561 #10044:
562
563 (nothing executed)
564
565 #10045:
566
567 Wake lock window: (nothing executed)
568
569 #10046:
570
571 Wake lock window: (nothing executed)
572
573 #10047:
574
575 Turned Wifi On Time: 7h 24m 9s 124ms (100.0%)
576
577 Full Wifi Lock Time: 0ms (0.0%)
578
579 Scan Wifi Lock Time: 0ms (0.0%)
580
581 Wake lock window: (nothing executed)
582
583 #10048:
584
585 Wake lock window: (nothing executed)
586
587 #10049:
588
589 (nothing executed)
590
591 #10050:
592
593 Sensor GPS: (not used)
594
595 Sensor 2: (not used)
596
597 #10051:
598
599 Wake lock window: (nothing executed)
600
601 Apk com.stylem.wallpapers:
602
603 (nothing executed)
604
605 #10052:
606
607 Apk com.pureinnovation.purerss:
608
609 (nothing executed)
610
611 #10053:
612
613 Wake lock window: (nothing executed)
614
615 #10054:
616
617 Wake lock window: (nothing executed)
618
619 #10055:
620
621 (nothing executed)
622
623 #10056:
624
625 Sensor 0: (not used)
626
627 Sensor 1: (not used)
628
629 #10057:
630
631 Wake lock window: (nothing executed)
632
633 Proc com.tni.TasKiller:
634
635 CPU: 10ms user + 0ms kernel
636
637 0 process starts
638
639 #10058:
640
641 Wake lock window: (nothing executed)
642
643 Apk se.f1nally.snowstorm:
644
645 (nothing executed)
646
647 #10059:
648
649 Wake lock window: (nothing executed)
650
651 #10060:
652
653 Wake lock window: (nothing executed)
654
655 #10061:
656
657 (nothing executed)
658
659 #10062:
660
661 Wake lock WifiService: (nothing executed)
662
663 Wake lock window: (nothing executed)
664
665 Wake lock ubikim-service/idle: (nothing executed)
666
667 Wake lock ubikim-service/keep-alive: (nothing executed)
668
669 Apk com.ubikod.android.ubikim.buddymob:
670
671 Service com.ubikod.android.ubikim.service.UbikIMService:
672
673 Created for: 18m 49s 325ms uptime
674
675 Starts: 0, launches: 0
676
677 #10063:
678
679 Wake lock window: (nothing executed)
680
681 #10064:
682
683 (nothing executed)

Ich möchte noch folgende Erklärung vorrausschicken. Das Handy steckt unter Tags und Abends, bei mir meistens per USB am Laptop, da ich viel damit arbeite. Vor dem Schlafengehen wird der Laptop ausgeschaltet und das Handy schaltet auf Batterie und geht automatisch in den Sleepmodus.

Schauen wir uns nun einmal die ersten paar Zeilen dieses Ausschnitts näher an:
1Time on battery: 7h 24m 9s 124ms (88.7%) realtime, 18m 49s 325ms (3.8%) uptime
2
3 Total run time: 8h 20m 52s 569ms realtime, 1h 15m 32s 770ms uptime,
4
5 Screen on: 2m 8s 269ms (0.5%), Input events: 156, Active phone call: 0ms (0.0%)
6
7 Screen brightnesses: dark 7s 373ms (5.7%), medium 2m 0s 897ms (94.3%)
8
9 Total received: 60.41KB, Total sent: 91.52KB
10
11 Total full wakelock time: 1s 759ms , Total partial waklock time: 15m 4s 397ms
12
13 Signal levels: good 471ms (0.0%) 2x, great 7h 24m 8s 653ms (100.0%) 0x
14
15 Radio types: none 17m 12s 68ms (3.9%) 2x, umts 7h 6m 57s 56ms (96.1%) 2x
16
17 Wifi on: 7h 24m 9s 124ms (100.0%), Wifi running: 23m 26s 582ms (5.3%), Bluetooth on: 7h 24m 9s 124ms (100.0%)

Hier ist zu erkennen, dass das Handy 7 Stunden 24 Minuten auf Batterie gelaufen ist, 88,7% der Zeit seit dem letzten Ende der Aufladung. Den Rest der Zeit wurde wieder geladen (Laptop eingeschaltet)
Die Gesamtlaufzeit von 8 Stunden 20 Minuten steht dann in der nächsten Zeile "Total Runtime". Hier ist auch die Uptime (Zeit in welcher das Handy nicht im SleepMode war) zu lesen.

Die nächsten beiden Zeilen, Screen on/brigthness zeigen das Bildschirmverhalten während dieser Zeitspanne. Interessant ist die Zeile: "Total received" - Sie zeigt an wieviel Datenverkehr unser Handy in dieser Zeitspanne insgesamt abgewickelt hat.

Ebenfalls sehr interessant sind die Zeilen: "Signal Levels" und "Radio Types".
Aus Ihnen können wir interessante Rückschlüsse auf das Verhalten des sogenannten "Radio Modules" unseres Handys ziehen. Das Radio Module unseres Handys kümmert sich um sämtliche Funkverbindungen die unser Handy zu bieten hat. -> Wifi (Wlan), Bluetooth, GPRS, EDGE, (2g) UMTS (3g), GPS
(Wobei es noch ein extra GPS Modul gibt)

Interessant ist nun zu sehen, dass mein Handy über Nacht, scheinbar ganze 17 min. lang keine Verbindung zum Provider hatte "Radio Types: none 17m 12s 68ms"
Diese Logfile Aussage lässt nun folgende Schlussfolgerung zu:
In diesem Zeitraum schaltet das Handy auf volle Sendeleistung und versucht nun successiv sich mit einen bekannten Handymast nach dem anderen zu verbinden. (Die Nachbarmasten, oder besser Zellen, sind dem Handy bekannt) Da dies für den Zeitraum von 17 Minuten nicht gelungen ist, gehe ich davon aus, dass mein Provider heute Nacht einen kleinen Ausfall hatte.

Nun kosten aber genau solche Dinge teilweise recht viel CPU und damit Akkuzeit.

Weiters können wir daraus ablesen, dass es nicht unbedingt Applikationen sein müssen, die Akkuzeit auffressen.

In diesem Fall hat unser Provider ein solches Verhalten verursacht. In was für Zeitabständen das Handy nun versucht eine neue Verbindung zu erlangen ist mir nicht bekannt. Das würde eine genaue Sourcecodeanalyse und Studium der Konfigurationsfiles erfordern.

Die nächsten Zeilen des Reports :
1Device is currently plugged into power
2
3 Last discharge cycle start level: 100
4
5 Last discharge cycle end level: 97

Hier wird lediglich gesagt, dass Handy wurde mit 100% Ladung vom Strom genommen und als es wieder angesteckt wurde, war noch 97 % Akkuladdung vorhanden.

Über Nacht wurden also nur 3% Akku verbraucht. Dazu sollte gesagt werden, dass mein Handy auf UMTS gestellt war, mit eingeschaltetem WIFI im WLAN eingebucht war und der Bluetooth Service lief ohne das jedoch ein HEadset connectetd war.
Eigentlich kein schlechtes Ergebnis wie ich finde. Nur 3 % ......

Die folgenden Zeilen gehen nun richtig ans Eingemachte. Hier werden für jede Applikation (wobei ich mir nun nicht sicher bin ob das wirklich alle sind oder nur diejenigen die auch wirklich laufen) die einzelnen Aktivitäten während dieser Zeitspanne aufgelistet. Interessant sind hierbei die Netzwerkaktiviäten die Strom fressen, sowie Aktivitäten, die ggf. den Screen angehen lassen.

Die einzelnen Aktivitäten werden hierbei nach den UID's aufsteigend gelistet, die jede Applikation unique im Linux - System hat. An anderer Stelle im Bugreport werden diese UID-App Mappings aufgeführt:
1Processes in Current Activity Manager State:
2 Running processes (most recent first):
3
4 Running Norm Proc # 7: oom_adj= 0 ProcessRecord{43268a30 116:android.process.acore/10005}
5
6 Running Norm Proc # 6: oom_adj= 14 ProcessRecord{43388158 22973:com.google.android.gm/10008}
7
8 Running PERS Proc # 5: oom_adj=-100 ProcessRecord{43296440 60:system/1000}
9
10 Running Norm Proc # 4: oom_adj= 7 ProcessRecord{434f94a8 22962:com.voss.nostalk/10003}
11
12 Running PERS Proc # 3: oom_adj=-12 ProcessRecord{432a54b8 112:com.android.phone/1001}
13
14 Running Norm Proc # 2: oom_adj= 7 ProcessRecord{4347d3c8 19802:com.google.process.gapps/10009}
15
16 Running Norm Proc # 1: oom_adj= 2 ProcessRecord{43415590 293:net.jaqpot.netcounter/10030}
17
18 Running Norm Proc # 0: oom_adj= 1 ProcessRecord{4335b728 205:com.android.inputmethod.latin/10005}
19
20
21
22 PID mappings:
23
24 PID #60: ProcessRecord{43296440 60:system/1000}
25
26 PID #112: ProcessRecord{432a54b8 112:com.android.phone/1001}
27
28 PID #116: ProcessRecord{43268a30 116:android.process.acore/10005}
29
30 PID #205: ProcessRecord{4335b728 205:com.android.inputmethod.latin/10005}
31
32 PID #293: ProcessRecord{43415590 293:net.jaqpot.netcounter/10030}
33
34 PID #19802: ProcessRecord{4347d3c8 19802:com.google.process.gapps/10009}
35
36 PID #22962: ProcessRecord{434f94a8 22962:com.voss.nostalk/10003}
37
38 PID #22973: ProcessRecord{43388158 22973:com.google.android.gm/10008}

Interessant zu sehen ist nun gleich der erste Bereich der detaillierten Liste:
1#1000:
2
3 Network: 32.65KB received, 65.15KB sent
4
5 User activity: 4 other, 30 long_touch, 24 touch_up
6
7 Turned Wifi On Time: 0ms (0.0%)
8
9 Full Wifi Lock Time: 0ms (0.0%)
10
11 Scan Wifi Lock Time: 5m 35s 631ms (1.3%)
12
13 Wake lock WifiService: 5m 54s 640ms partial (51 times) realtime
14
15 Wake lock ActivityManager-Launch: (nothing executed)
16
17 Wake lock PreventScreenOn Partial: (nothing executed)
18
19 Wake lock StayOnWhilePluggedIn Partial: 188ms partial (1 times) realtime
20
21 Wake lock keyguard: 1s 390ms full (1 times) realtime
22
23 Wake lock CheckinService: 9s 710ms partial (1 times) realtime
24
25 Wake lock ActivityManager-Sleep: 47ms partial (1 times) realtime
26
27 Wake lock NotificationService: 319ms partial (1 times) realtime
28
29 Wake lock SyncManagerHandleSyncAlarmWakeLock: 398ms partial (1 times) realtime
30
31 Wake lock HardwareService: 325ms partial (1 times) realtime
32
33 Wake lock StayOnWhilePluggedIn Screen Dim: 369ms full (1 times) realtime
34
35 Wake lock window: (nothing executed)
36
37 Wake lock keyguardWakeAndHandOff: 5ms partial (1 times) realtime
38
39 Wake lock SCREEN_FROZEN: (nothing executed)
40
41 Wake lock sleep_broadcast: 360ms partial (3 times) realtime
42
43 Wake lock SyncManagerSyncWakeLock: 6s 385ms partial (1 times) realtime
44
45 Wake lock AlarmManager: 14s 60ms partial (170 times) realtime
46
47 Wake lock LocationManagerService: 4m 27s 528ms partial (48 times) realtime
48
49 Wake lock UpdateVerifier: (nothing executed)
50
51 Sensor 0: 2m 8s 309ms realtime (1 times)
52
53 Proc system:
54
55 CPU: 1m 49s 840ms user + 21s 660ms kernel
56
57 0 process starts
58
59 Apk com.android.providers.subscribedfeeds:
60
61 Service com.android.providers.subscribedfeeds.SubscribedFeedsIntentService:
62
63 Created for: 187ms uptime
64
65 Starts: 1, launches: 1
66
67 Apk com.google.android.server.checkin:
68
69 1 wakeup alarms
70
71 Service com.google.android.server.checkin.CheckinService:
72
73 Created for: 18m 49s 325ms uptime
74
75 Starts: 0, launches: 0
76
77 Apk android:
78
79 51 wakeup alarms

Daraus geht hervor, dass alleine das Hauptsystem selber, bereits 50% des Netzwerktraffics direkt oder indirekt verursacht hat, der in der gesamten Nacht angefallen ist.
Im wesentlichen sind das in diesem Fall: WifiService und LocationManagerService (Locator von Google Maps) sowie der CheckinService unseres Handys (die "Ich telefoniere nach Hause" Funktion von Android wie ich sie gerne nenne)

Und so geht es im App für App und Service für Service weiter. Wie man sieht, sind wir also dazu in der Lage, sehr genau die wahren Stromfresser unserers Handys zu ermitteln.

Warum da nun allerdings eine spezielle Applikation oder ein bestimmter Service plötzlich Amok läuft und unseren Akku und die CPU malträtiert kann damit noch nicht explizit gesagt werden. Hier müssen wir die Randbedingungen, wie Providerverbindung, WifiStati, Bluetoothfehler, Exeptions usw. mit berücksichtigen.
Wenn also der Provider ausfällt und kein Wifi eingeschaltet ist beispielsweise, kann es bei mehreren Applikationen im Hintergrund durchaus sein, dass plötzlich alle diese Apps in einer Schleife laufen wo versucht wird eine Verbindung zum Server aufzubauen.

Das kann, je nach Anzahl der Apps nun zu einem ziemlichen Akkudesaster führen.

Für einen Entwickler würde das bedeuten, das er wenn seine Applikation auf solche Verbindungen angewiesen ist, Rücksicht auf Akkulaufzeit nimmt. Er könnte das bspw. so tun, das wenn keine Verbindung zustande kommt, erstaml versucht zu klären, ob überhaupt ein nutzbares Netz vorhanden ist. Wenn nicht könnte er den nächsten "Netzwerk wieder online" Broadcast abwarten und erst dann einen neuen Versuch starten die Verbindung aufzubauen.

Leider zeigt die Praxis und viele Sourcecode Beispiele im Internet das genau das nicht der Fall ist und die Apps gnadenlos im ms Takt Verbindungsversuche aufnehmen. Hier ist also die Entwicklergemeinde gefordert, sich genauer über die Auswirkungen von Exeptionbehandlungen in Zusammenhang mit Netzwerkprogrammierung zu befassen.

Ich hoffe nun das ich Euch ein wenig über die Methodik zu Fehlersuche bei zunächst unerklärlichen Batterieverlusten vermitteln konnte.

Allerdings ist es zugegeben nicht einfach diese Bugreports zu lesen und erst recht nicht die Ausgaben zu interpretieren. Manche Interpretation erfordert einfach viel Hintergrundwissen um Netzwerke, Betriebsysteme und ihr Verhalten, sowie einfach ein großes Maß an Erfahrung in diesen Bereichen. Nicht zuletzt ist die Fähigkeit zum analytischen Denken ein große Hilfe.

Dies alles sollte aber niemanden davon abhalten, sich in das Abenteuer Bugreport lesen zu stürzen. es kann u.U. viel Zeit und unnötige Raterei sparen indem man sich mal an der Basis informiert.

Über Feedback zu diesem Artikel freue ich mich natürlich und hoffe nun einigen damit geholfen zu haben.

lg
Voss

lg Voss

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

23.09.2009, 12:07:48 via Website

Guten Morgen Dr. Voss!

Wieso Dr. Voss? - nimm es nicht persönlich, aber dein Beitrag erinnert mich an eine Krankengeschichte:

Damals, es war vor ein paar Jahren wurde ein kleiner Junge mit der Rettung ins KH eingeliefert.
Er klagte über fürchterliche Bauchschmerzen -
die Ärzte wurden zusammen gerufen - es wurden zahlreiche Untersuchungen gemacht -
manche Ärzte wollten den kleinen Jungen schon den Bauch aufschneiden....
Der kleine Junge wurde auf Maschinen gehängt - Diagnosen erstellt - beraten und Diskutiert...
Aber es wurde keine Lösung gefunden??

Da kam ein alter Mann zu Tür rein, ein Patient der ging zu dem kleinen Jungen fragte den Jungen
wie es ihm geht, und klopfte ihm dabei auf die Schulter und da geschah das kleine Wunder
der kleine Junge machte ein sehr lautes Bäuerchen (wir sagen Rülpser dazu) und die Bauchschmerzen
waren wie weggeblasen.
Enddiagnose: Der kleine Junge hatte Nachmittags die Keksdose seiner Großmutter erwischt
:grin:

Was ich dir damit sagen will, dein Bericht ist wirklich sehr interessant - aber es soll auch für jedermann
verständlich sein und vor allem soll es nicht Sinn der Sache sein jedesmal wenn mein Accu zu schnell
leer ist einen kilometerlangen Bugreport auszulesen.
Ich würde es besser finden du würdest die großen Stromfresser zusammen fassen -
oder was noch wichtiger wäre eine Apk zu schreiben die, die Stromfresser herausfiltert, sie anzeigt
und ich sie bei Bedarf abschalten kann.

Zusammenfassung:

Also ich finde deinen Beitrag wirklich sehr interessant, ich weiß zumindest jetzt um was es geht!
Aber Lösung konnte ich leider keine finden.

Schöne Grüße in die Bundeshauptstadt

Manfred

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 13:09:39 via Website

Moin Manfred,

lass den Dr. weg, der bin ich nicht. Persönlich nehm ich sowas nicht, keine Sorge.

Ich würde ja dem guten Android gerne öfter auf die Schulter klopfen ... einzig .. fehlen mir die Mittel dazu.

Ich schrieb ja :
Die meisten diese hier zu findenden Informationen verlangen Aufrufe von intern gehaltenen APIs an die auf normalem Weg (ohne Root und sonstige Kniffe) nicht heranzukommen ist.

Soll für Nicht-Lateiner / Techniker heißen: Das System lässt mich auf Programmierebene nicht an diese im Bugreport befindlichen Informationen heran.

Ich kann den Wunsch nachvollziehen, einzig erfüllbar scheint er mir nicht unter den gegebenen Umständen.

Eine gewisse Erleichterung wird es wohl mit Donut geben, Google hat uns ein Programm spendiert das den Akkuverbrauch nach Applikationen auszugeben scheint. Ob und wie hilfreich das ist ... vielleicht kann Sebastian da mehr zu sagen, er hat ja Donut schon auf seinem gerooteten Handy drauf.

Was die Verständlichkeit angeht ... ich kann an den Tatsachen der Ausgabe nichts ändern ... ich versuche nur mein Wissen mit Euch zu teilen. Die Tiefe in die diese Dinge gehen, macht es zudem nicht leicht die Inhalte ohne das vorhandensein von Vorwissen zu vermitteln.

Auch kann ich nicht die Vielzahl an Apps die sich am Markt befinden und die unterschiedlichen Konstellationen von Apps, Einstellungen, und Gegebenheiten abbilden. In sofern wird es mir nicht gelingen, DIE Stromfresser schlechthin isoliert darzustellen.

Es war nicht Ziel meines Beitrages Lösungen zu präsentieren, lediglich Methodiken vorzustellen, was im Beitrag aber auch nachzulesen ist.

Niemand zwingt Dich einen kilometerlangen Bugreport zu lesen. Diejenigen die es wollen, haben es mit dem Artikel aber vielleicht etwas leichter die Inhalte zu interpretieren.

lg
Voss

lg Voss

Antworten
Friedrich W.
  • Forum-Beiträge: 265

23.09.2009, 13:13:39 via Website

Hallo Jörg,
vielen Dank für deine umfangreiche Aufklärung, die für mich in mehrfacher Hinsicht aufschlussreich ist. Aber zuvor, ich bin ein interessierter, aber laienhafter Nutzer solcher Geräte. Mit anderen Worten, solch eine Überprüfung könnte ich im Moment nicht vornehmen, weil sie über meine Kenntnisse geht.

Was aber wieder einmal deutlich wird, ist, dass die einfache Zuschreibung dieses oder jenes Programm ist für starken Akkuverbrauch verantwortlich, nicht haltbar ist. Verkompliziert die Sache natürlich noch einmal. Wäre so schön, wenn man sagen könnte, das ist es, also runter damit.

Insofern hast du natürlich recht, dass man nicht einfach ein Programm verteufeln sollte, ohne sicher zu wissen, dass es tut, was man nur vermuten kann.

Ich kann für mich aus deinen Informationen fast nur schließen, akzeptiere die Komplexität des Akkuverbrauchs deines Heros. Passt zu meiner fatalistischen Lebensphilosophie, oder um es mit Nietzsche zu sagen: "amor fati". Liebe dein Schicksal.

Andererseits möchte ich an Manfreds Frage anknüpfen, ob es denn nicht möglich ist, die Hauptstromfresser zu benennen.

Mir wäre auch so etwas wie ein survival of the fittest App sympathisch. Damit meine ich es müsste so etwas wie eine Liste geben, in der man Vermutungen über Stromfresser äußert, die dann von x Nutzern bestätigt oder nicht bestätigt würden, so dass in einem Prozess die Programme herausgefiltert werden könnten, die akkufreundlich sind, denn es ist bei der Vielzahl von z. B. Wetterwidgets nicht einzusehen, warum einen Energiefresser durchfüttert.
Schließlich arbeitet der "Market" ja letztlich auch nach dem "survival of the fittest-Prinzip".

Aber so etwas wird wohl nicht machbar sein, also werde ich mich in mein Schicksal lieben, dass ich nicht weiß, was los ist, wenn mal wieder der Akku so angesaugt wird, dass er vor Vergnügen quietscht.

Gruß
Friedrich

PS
Noch mal meinen Dank dafür, etwas Naivität abgesaugt bekommen zu haben.

— geändert am 23.09.2009, 13:17:16

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

23.09.2009, 15:31:12 via Website

Hallo Jörg,

Ich kann den Wunsch nachvollziehen, einzig erfüllbar scheint er mir nicht unter den gegebenen Umständen.


Wir kennen durch deinen Eintrag zwar jetzt die Umstände, die das schnelle leeren eines Accus
bewirken können...

Aber machen kann man dagegen gar nichts - außer das übliche alles abdrehen was nicht gebraucht wird
Und daraus lernen wir nicht wir steuern die Computer - die Computer steuern uns....

Mann, bin ich froh wenn ich mit der ganzen Sache nichts mehr zu tun hab!

Das mit dem Dr. weiß ich - aber die ganze Sache hat sich für einen Laien, wie mich - schon gelesen wie
ein lateinischer Krankenbericht :grin:

Ich wünsche dir noch einen schönen Tag

lg Manfred

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 16:25:09 via Website

Hallo Manfred,

soll ich denn das nächste Mal so einen Artikel besser nicht schreiben?

Ich meine, wer liest schon gerne "lateinische Krankenberichte".

lg
Voss

lg Voss

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 16:27:41 via Website

Nun mal alle gefragt:

Was wurde nicht verstanden bzw. liest sich "lateinisch" ?

Ich bin ja gerne bereit die Dinge zu erklären.

lg
Voss

lg Voss

Antworten
Uwe Fegel
  • Forum-Beiträge: 47

23.09.2009, 16:58:42 via Website

tach auch,
ich als anfänger versteh es auch noch nicht, hoffe aber auf die zukunft,
man muß ja auch nicht lesen wenn man nicht möchte, von daher, weiter so!
gruss an alle

Antworten
Gelöschter Account
  • Forum-Beiträge: 31

23.09.2009, 17:19:52 via Website

Eine einfache Möglichkeit ebenfalls an einen großen Teil dieser Informationen zu kommen bietet die versteckte Test App (zumindest wird sie bei mir unter dem Namen angezeigt).

In diese gelangt man wenn man

*#*#INFO#*#* wählt (also *#*#4636#*#* )

Dort kann man die Werte auch im Akkuprotokoll nachlesen. Sehr praktisch ist dort übrigens unter Telefoninformationen der Punkt "bevorzugte Netzwerktyp feslegen", da man dort das G1 auch auf 3g only (WCDMA Only) einstellen kann. Eine Funktion die ich sehr gerne nutze wenn ich das G1 fürs Tethering verwende, da es sonst häufig zwischen 2g und 3g wechselt.

Zumindest gibt es dieses Menü beim G1 - zu den anderen Modellen kann ich leider nichts sagen.

Gruß
Leif

Antworten
Anton S.
  • Forum-Beiträge: 1.614

23.09.2009, 17:43:12 via Website

Hey Jörg,

ich finde deinen Beitrag sehr interessant. Mit den Codezeilen selbst kann ich nicht so viel anfangen, aber deine Erklärungen sind gut.

Ich möchte hier auch nochmal kurz was zum Thema Akkulaufzeit sagen. Ich habe ein gerootetes G1 und habe derzeit die cyanogen 11.1 ROM (Android 1.6 Cupcake) drauf. Diese läuft auch bei niedrigeren Taktfrequenzen immernoch sehr sehr flüssig. Natürlich ist bei mir auch aus diesem Grunde das Overclock Widget drauf. Ich habe es so eingerichtet, dass es bei im Ruhestand auf 128 Mhz takten kann. Bei Benutzung kann es automatisch bis auf 538 Mhz getaktet werden. Die Bildschirmhelligkeit ist die Dritthelste (hab ja noch gute Augen ;-) )

Heute Morgen habe ich mein G1 vom Netz genommen. Seither habe ich 4 Emails und 5 SMS verschickt. Edge ist an und ich war bisher 3 mal im Internet.

Ich bin an dieser Stelle mit der Laufzeit sehr zufrieden, denn meine Statusanzeige zeigt mir noch den Wet von 78 % Akku. Ich finde das ist wirklich eine passable Leistung!

Mein Fazit daraus ist, dass Google sich da selbst im Wege stellt. Würden die Mal die Ressourcen auf der Rootebene für Entwickler freigeben, könnte man noch sehr viel mehr aus dem guten Gerät holen in Bezug auf die Akkulaufzeit. Bis dahin dauert es sicher von ein Weilchen.

Grüße

Anton

Neu bei Android, AndroidPIT oder dem App Center? Hier erfährst Du alles Wichtige: http://bit.ly/ccFQvI

Antworten
Friedrich W.
  • Forum-Beiträge: 265

23.09.2009, 18:35:43 via Website

Hallo Jörg,

ich hatte ja oben schon geschrieben, dass ich deine Informationen schätze und sie hilfreich sind gewisse Dinge einzuschätzen, aber ich verstehe als Laie nicht, was dort aufgelistet ist. Ich habe auch keine wirkliche Tendenz mich in diese Dinge einzuarbeiten, aber das mag ja bei anderen, die weiter sind durchaus der Fall sein und die verstehen mehr als ich und sind möglicherweise dankbar für die Details, die eher was für Experten sind.
Ich denke also, dass je nach Kenntnissstand viele daran interessiert sein können.
Ich nehme mit , was meinem Stand entspricht und ein anderer freut sich darüber auf einer anderen Ebene etwas zu erfahren, das ihn weiterbringt.

Und wenn wir alle überfordert wären, etwas zu verstehen, wäre es auch nicht schlimm, tut ja nicht weh. Man kann ja überfliegen und stoppen, wo es für einen wieder interessant wird, ist halt nur blöd, wenn du dir Arbeit machen würdest, die von niemandem geschätzt werden kann, weil sie unsere momentanen Möglichkeiten überschreiten.
Aber ich kann nur sagen, ich gehe durch deine Erklärungen relaxter und etwas verständnisvoller an den Akkuverbrauch ran.

Danke!
Friedrich

— geändert am 23.09.2009, 18:36:15

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 19:02:36 via Website

Hallo noch mal zusammen,

das mit diesem USSM oder wie diese Nummern heißen hatte ich völlig vergessen.

Klar, diese INTERNAL App bezieht ihre Information aus genau diesen im Bugreport zu lesenden Angaben.

Um Euch allen da zu vereinfachen und diese Nummer nicht immer eintippen zu müssen hab ich das mal so gelöst :

Ein kleine Miniapp, die einfach dieses InfoApp startet. Nicht fein aber es reicht. Wenn Ihr das Icon auf den Desktop legt, ist das ein Klick. Gut aussehen tut das Icon auch noch :)

Hier die App zum Download: http://vosotarius.dyndns.org/akkuinfo.apk

So, die Infos sind dann eher verständlich, wenn auch nicht so aussagekräftig. So kann nun jeder für sich entscheiden was er benutzen möchte.

Ab Android 1.6 gibts das ja wohl eh offiziell von Haus aus mitgeliefert.

lg
Voss

lg Voss

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

23.09.2009, 19:20:01 via Website

Hallo Jörg,

soll ich denn das nächste Mal so einen Artikel besser nicht schreiben?


ganz im Gegenteil! Deine Artikel sind hier jederzeit willkommen und vor allem sehr Informativ.
Aber ich gehe davon aus, das mehr als 2 Drittel unserer Mitglieder (mich eingeschlossen) ganz
normale Anwender sind, denen wichtig ist, das sie mit ihrem Handy telefonieren, surfen, ihre E-Mails
abrufen können, Facebook, Twitter, G-Talk G-Maps usw.benutzen können, und das der Accu das möglichst
lange durchhält - das ist uns wichtig,

Der Bugreport eines Android Handys kann mit dem ADB Tool erstellt werden, dass Bestandteil des Android SDK ist. Bei installiertem SDK und vorhandenem SystemPfad auf das SDK/Tools Verzeichnis sowie per USB an den PC angeschlossenem Handy gibt man folgenden Befehl auf der CMD (Commandline/DOS-Box...) ein:


Alleine dieser Satz ist für die meisten von uns nicht Nachvollziehbar....
Du lebst in der Großstadt, geh mal ins Cafe - schau dich ein wenig um, sicher wirst du bald einen Androiden
entecken - frag ihn mal wie er mit seinem Gerät zufrieden ist? - Als Antwort wirst du hören:
Ja ist ein tolles Gerät, was mich stört, ist das das Handy kein BlueTooth hat und das der Accu viel zu schnell leer ist. und er wird dich fragen ob es bei dir auch so ist?

Dann wirst du
mit dem oben zitierten Satz antworten - er wird dich ansehen als würdest du von einem anderen Stern kommen wird aufstehen und gehen....
Hättest du gesagt: Ja das ist bei mir auch so, aber Android steckt noch in den Kinderschuhen und wird
laufend verbessert - ja, dann würdet Ihr euch wohl jetzt noch unterhalten!

Jörg - Was ich damit sagen will ist, deine Berichte sind toll, qualitativ sogar spitze!
Aber es soll jeder sofort verstehen können (egal ob Dr. Joe oder Josef Huber) um was es geht
und es soll für uns Anfänger nicht so sein, dass ich vorher mal 2 Stunden auf Wikipedia suchen muss
was String - Unplugged Statistics - Appi´s - Sourcecodeanalyse usw. heißen könnten...

Du als Entwickler wirst mich zwar jetzt wieder nicht verstehen - aber das ist Egal
"Keiner versteht mich" :grin:

Gruß Manfred

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

23.09.2009, 19:33:02 via Website

Hallo Jörg,

ja wenn wir dich nicht hätten - habe das Programm mal runtergeladen und installiert
Ja genau, das ist es
Alles schön übersichtlich - damit können sogar Josef Huber und Manfred Z. etwas anfangen
Und der Icon ist sowieso spitze!!!

*GroßesHutziehabvonDir*

Ab in den Market damit auf sowas hat die Androidenwelt gewartet.

Danke und schönen Abend noch - mach dir ein gepflegtes Bierchen auf - du hast es dir verdient :)

lg Manfred

Antworten
Gelöschter Account
  • Forum-Beiträge: 6

23.09.2009, 19:46:05 via Website

Hallo allerseits,

Danke zunächst an Dich, Jörg, der Du Dir extra die Mühe gemacht hast.

Für mich, meines Zeichens tatsächlich Lateiner, ist der "Kram" verständlich und hilfreich für die Interpretation des momentanen status quo bzgl. meiner Akku-Lebensdauer. Ich, mit einem Samsung Galaxy bestückt, ärgere mich momentan über den fast Dauer Zustand battery low und würde mich freuen, wenn ich anhand Deines Programms meine Parasiten rausschmeißen kann :-)

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 20:03:24 via Website

Ok Manfred,

und es soll für uns Anfänger nicht so sein, dass ich vorher mal 2 Stunden auf Wikipedia suchen muss
was String - Unplugged Statistics - Appi´s - Sourcecodeanalyse usw. heißen könnten...

mit solchen Aussagen kann ich was anfangen.

Da kann ich dran arbeiten solche Termini zu vermeiden, dass soll das Ding nicht sein.

lg
Voss

lg Voss

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 20:05:43 via Website

Danke Manfred,

aus dem Bierchen wird heute mal ein gepflegter Grüner Veltliner werden :)

lg
Voss

— geändert am 23.09.2009, 20:38:31

lg Voss

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

23.09.2009, 20:16:31 via Website

lass ihn dir schmecken

- werde noch 3 Stunden arbeiten und dann bekomme ich meine kühle Blonde :grin:

lg Manfred

Antworten
Friedrich W.
  • Forum-Beiträge: 265

23.09.2009, 21:18:52 via Website

Hallo Jörg,

danke für die Anwendung, die auf meinem G1 funktioniert, wo ich 4 Optionen habe: Telefoninformation, Akkuinformationen, Akkuprotokoll und Nutzungsstatistik.

Nun habe ich auch noch das Hero. Dort werden die beiden Punkte "Akkuprotokoll" und "Nutzungsstatistik" nicht angezeigt. Woran es liegt, I really do not know.

Gruß
Friedrich

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

23.09.2009, 22:25:23 via Website

Das kann ich Dir auch nicht genau sagen Friedrich.

Die Anwendung selber hab ich ja gar nicht geschrieben. Das ist die welche normalerweise nach eingabe der Folge : *#*#4636#*#* auf dem Bildschirm erscheint.

Ich dachte lediglich das wäre etwas zu kompliziert und hab es daher vereinfacht. Ein Icon anzuklicken ist doch einfacher als sich diese kryptische Zahlenfolge zu merken.

Es ist auch zu befürchten, dass mit Erscheinen eines Updates diese App nicht mehr funktionieren wird oder nur noch eingeschränkt. Auch auf einigen Handys dürfte die Applikation nicht zur gänze implementiert bzw. eingebaut zu sein.

lg
Voss

lg Voss

Antworten
Sebastian Preisner
  • Forum-Beiträge: 533

23.09.2009, 22:32:02 via Website

sau cool, das ist natürlich sehr viel aussagekräftiger als diese Accuinformation... den Bugreport werde ich mir auch nochmal genau anschauen, ich habe huete noch eine App gelöscht da der akku wieder so schnell leer war und der Market ging aber ;).

LG Sebastian

Antworten
Friedrich W.
  • Forum-Beiträge: 265

26.09.2009, 10:31:59 via Website

Hallo Jörg,

vielleicht hast du eine Idee, woran das liegen kann.

Also nachdem ich das neue ROM fürs Hero installiert hatte, hielt der Akku unmittelbar danach genau 3 Tage durch. Zugegeben in der Zeit nicht viel damit herumgespielt.
Ohne bewusst etwas verändert zu haben (z. B. keine neuen Apps installiert) hielt der Akku ca. 2 Tage durch und gestern war es nur ein Tag, extrem wenig damit herumgespielt.
Im übrigen hab ich bei allen Apps, die sich mit dem Netz für Datenupdates verbinden auf große Intervalle gestellt.

Ich habe oben ja gelernt, dass es im Hintergrund Porzesse gibt, die den Akku belasten können, kann das denn zu einer Akkuspanne von einem bis drei Tagen führen?

Leider funktioniert das Auslesen mit deiner App nicht beim Hero.

Wenn es eine einigermaßen plausible Erklärung dafür gibt, wäre ich schon zufrieden. Gibt es andere Heroes, die bestätigen können, dass der Akku unterschiedlich lange hält, ohne dass sie dafür eine Erklärung finden könnten?

Danke!
Friedrich

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

26.09.2009, 12:56:56 via Website

Hallo Friedrich,

Friedrich Wulf
Hallo Jörg,
Ich habe oben ja gelernt, dass es im Hintergrund Porzesse gibt, die den Akku belasten können, kann das denn zu einer Akkuspanne von einem bis drei Tagen führen?
Kurz und knapp, JA!

Friedrich Wulf

Leider funktioniert das Auslesen mit deiner App nicht beim Hero
Nur zur Klarstellung, ich starte mit meiner App lediglich bereits auf dem Handy installierte Software die Bestandteil der Android Distribution ist. Ist jetzt nicht böse gemeint, wollte nur erläutern das ich nichts auslese.

Grundsätzlich sind so allgemein gehaltene Fragestellungen extrem schwer zu beantworten.

Du schreibst nicht welches Rom (vielleicht haben ja andere mit diesem Rom die gleichen Erfahrungen gemacht ... )
Du schreibst, du hast bei "allen Apps" die Datenverbindungen aufbauen lange Intervalle eingestellt...
Kann man das denn bei allen? Ich bin mir in diesem Fall ziemlich sicher das man genau das eben nicht bei allen kann. Im Android laufen sehr viele Dinge im Hintergrund ab, ohne das Du Dir dessen bewusst wirst. Was genau das alles ist, ob das bei Deinem ROM auch so ist .. ich weiss es nicht.

Eine Möglichkeit herauszufinden, ob es bspw. an Prozessen liegt, die auf Internetressourcen zugreifen, wäre wenn Du Dein Handy mal einen Tag lang wirklich in den Airplane Mode schaltest und dann beobachtest wie sich die Akkulaufzeit verändert im Vergleich zu eingeschaltetem Netzwerken. (Non-Airplane modus.)
Mit Airplane Mode meine ich den Flugzeugmodus.

Das ist zeitaufwendig, sicher, aber solange wir keine weitergehenden Dokumentationen zu den Dingen haben und es ansonsten technisch eher sehr aufwendig wird, sehe kaum andere Möglichkeiten dies herauszufinden.

lg
Voss

lg Voss

Antworten
Friedrich W.
  • Forum-Beiträge: 265

26.09.2009, 18:32:45 via Website

Hallo Jörg,

danke für die Informationen und Anregungen. Bei der Verwendung des Begriffs "auslesen" hab ich mir nichts weiter gedacht. Und ich weiß, nachdem du das schon geschrieben hattest, dass du mit deiner kleinen Anwendung "nur" auf vorhandene Möglichkeiten zugreifst.

Beim Hero ROM handelt es sich um das letzte update. Und wenn ich geschrieben habe, ich hätte "allen Apps" lange Intervalle zugeordnet, dann meine ich damit die, bei denen das möglich ist: pure calendar, snowstorm, twitter, etc.

Deinen Vorschlag mal für einen Tag in den Flugzeugmodus zu schalten, werde ich eventuell aufnehmen. Ich warte aber noch mal ein paar Tage und schaue, ob sich so etwas wie eine durchschnittliche Akkuleistung einpendelt.

Auf jeden Fall, besten Dank für deine Überlegungen.

Herzliche Grüße
Friedrich

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

26.09.2009, 21:35:25 via Website

Hallo friedrich,

Remote aus nem lokal .... gern geschehen!

Es ist einfach zu schwierig so Ferndiagnosen zu machen....

Viel Erfolg!

Lg
Voss

lg Voss

Antworten
Friedrich W.
  • Forum-Beiträge: 265

02.10.2009, 11:52:04 via Website

Hallo,

ich habe ja dieses Problem mit der Akkuleistung beim Hero und inzwischen alles Mögliche ausprobiert. Im Moment scheint es so, als hätte ich das Programm gefunden, das für die Akkuentleerung in großem Stile verantwortlich war: Peep! Seit ich es deaktiviert habe, hält der Akku wieder länger.

Können das die Herobesitzer bestätigen? Wie ist eure Akkuleistung mit bzw. ohne Peep? Um wie viel Prozent fällt bei euch die Akkuleistung über Nacht? Ich gehe mal von einem Zeitraum zwischen 6 und 8 Stunden aus. Mit Peep bei mir weit über 10 Prozent, ohne Peep ca. 2-3 Prozent. Könnt ihr das bestätigen. Lag das evtl. am fehlerhaften Peep? Soll ja beseitigt sein. Oder wird das selbst dann so sein, wenn der Fehler ausgebügelt wurde?

Danke!
Friedrich

Antworten
Friedrich W.
  • Forum-Beiträge: 265

24.10.2009, 18:50:08 via Website

Hallo,

noch einmal ein paar Wunderlichkeiten über die Akkuentladung. Ich habe seit einiger Zeit aufgeschrieben, wie lange meine Akkus in den beiden Geräten (G1 und Hero) durchhalten.
Beim Hero hab ich nun diese seltsame Erfahrung gemacht. Hab schon mal bei geringem Gebrauch 3 Tage geschafft. Dann aber auch wieder gleicher oder ähnlich geringer Gebrauch nur 1,5 Tage.

Nun die Überraschung, ohne dass ich etwas bewusst verändert hätte, liegt die Akkuladung im Moment bei 74% und das nach genau 2 Tagen oder 48 Stunden. Das gibt es doch nicht, oder?

Wie es es möglich, dass ohne Veränderungen am Hero (keine Apps installiert, wohl vorhandene aktualisiert) der Akku auf einmal gar nicht leer werden will (74% nach 2 Tagen), aber vor ein paar Tagen nur ca. 36 Stunden insgesamt durchhielt?
Very, very strange.

Gruß
Friedrich

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

24.10.2009, 20:00:56 via Website

Hallo Friedrich,

in gewissen Fällen kann das auch von äußeren Umständen abhängen, die Dir zunächst gar nicht auffallen, weil sie sich für Dich in erster Linie unsichtbar, hinter den Kulissen abspielen.

Beispiel: Bei mir steigt zum Beispiel der Akkuverbrauch immer dann an wenn ich im Krankenhaus zur Behandlung bin. Ich telefoniere dabei nicht mehr oder weniger wenn ich zuhause bin.
Der Grund findet sich in der dort vor Ort gegebenen GSM Versorgungssituation. Rund um Krankenhaus tritt eine extreme Nutzungssituation der vorhandenen GSM Masten auf. Durch das Große Krankenhaus und die dadurch extreme Konzentration von Handys auf engem Raum werden die GSM Masten nahezu völlig aus bzw. überbucht. Nun muss das Handy sehr oft versuchen auf benachtbarte, weiter entfernte Masten auszuweichen. Hierzu fährt das Handy die Sendeleistung ziemlich weit hoch und nimmt Kontakt zum weiter entfernten Sendemast auf. Jetzt ist aber nicht gesagt, das der auch frei ist ...

Genau das gleich Spiel gilt dann auch noch mal für die Datenübertragung .. wenn eine anfällt .. Sendeleistung hochfahren .. kontakt aufnehmen usw.
Hinzu kommt im AKH, das die Abschirmung dort relativ hoch ist durch den sehr kompakten Bau und die verwendeten Alubedampften Fenster .. auch das beeinflusst die notwendige Sendestärke Deines Handys.

Nun kann es ausserdem noch sein, dass Dein Provider vielleicht ab und zu Änderungen an den Einstellungen der Masten vornimmt. (Software release Wechsel, Anpassung der Softwareeinstellungen, oder oder oder ... ) Alleine ein Baukran der in der Nähe aufgestellt wird kann Dein Handy wenn es blöd hergeht schon dazu bringen plötzlich auf einen anderen Mast auszuweichen. Rein HF-technisch betrachtet.

Besonders beim Autofahren wirst Du einen steigenden Akkuverbrauch bemerken, weil sich ständig die Masten ändern und Dein Handy von einer Station zur nächsten weitergereicht wird. Auch dabei entstehen wieder starke Akkuverbräuche durch permanentes ein und ausbuchen bei den jeweiligen Masten.

Ich hoffe ich konnte da einigermaßen verständlich darstellen.

lg
Voss

lg Voss

Antworten
Looks
  • Forum-Beiträge: 1.184

24.10.2009, 20:14:44 via Website

Hallo Friedrich,

Ich habe ja auch ein Hero und bei mir ist vor ein paar Tagen plötzlich mein Akku ganz schnell, auch so 1.5 Tagen geringer gebrauch entladen gewesen. Ich habe sonst auch wie Du so ca. drei Tagebis ich laden muss (nachts schalte ich aus). bei dem Fall, als die zeit so kurz war bin ich kaum auswärts gewesen und kein Autofahrten, also ist der Mastenjump nicht vorhanden gewesen. Ich habe die Idee, dass ich bevor das passiert ist beim Laden bei 99% aufgehört habe und mir ist scho aufgefallen, dass es wenn mein Ladestand bei 99% ist noch ziemlich lange geht, bis dann wirklich 100% kommt. Also viel länger dauert, als z.B. von 98% auf 99%. irgendwie habe ich den Verdacht, dass man nicht so auf diese % Anzeige gehen kann und dass ich einfach zu wenig geladen habe. Ich lass auf jeden Fall jetzt immer bis 100% laden.
Weiss nicht, was Du oder andere damit für Erfahrungen haben, aber vielleicht ist das ja auch noch jemadem aufgefallen.

gruss

Looks

LukiLuke, el Suizo

Antworten
Friedrich W.
  • Forum-Beiträge: 265

24.10.2009, 21:45:32 via Website

Ein herzliches Hallo,

ja Jörg, auch wenn ich die technischen Hintergründe nicht im einzelnen verstehe, so kann ich nachvollziehen, was du schreibst und es klingt in der Tat plausibel. Fazit: Mit "rätselhaften" Akkukapriolen ist zu rechnen.

Lukas, deine Beobachtung mag so stimmen, aber ich habe immer darauf geachtet, dass ich 100% hatte. Ja, ich fahre das Teil sogar runter, ziehe Kabel ab und stecke es wieder dran, dann leuchtet das Lämpchen meist für einen Moment rot, bis der Akku sich nach ein paar Sekunden den letzten Stromkick geholt hat.
Ich schätze also, die Akkuleistung wird ein Thema bleiben, solange kein Nanokraftwerk in die Gadgets eingebaut wird.

Wünsche euch ein schönes Wochenende.
Friedrich

Als ich vorherigen Beitrag geschrieben hab, war es kurz vor 7 und Akku lag bei 74%
Jetzt um 21:40 noch bei 73%. Ausgezeichnet!

Antworten
Gelöschter Account
  • Mod
  • Forum-Beiträge: 3.188

06.11.2009, 10:10:55 via Website

Bzgl. Akku habe ich auch so meine Erfahrungen, das die Laufzeit nicht immer nachvollziehbar ist.
Aber was mir heute aufgefallen ist, das es wohl seit Android 1.6 unter Einstellungen / Telefoninfo einen Punkt Akkuverbrauch gibt. Und siehe da, als Hauptverbraucher bei mir sind da Display und WLan gelistet. WLan kann ich mir gut vorstellen, bin öfters quer durch München unterwegs, und nehm an das Android versucht den üblichen AP bzw. neue zu finden.

Antworten
Moritz L.
  • Forum-Beiträge: 434

06.11.2009, 12:00:59 via Website

Bei mir sind auch WLan und Display die Hauptfresser. WLan halt immer ausmachen, wenns nicht gebraucht wird, lässt sich ja mit locale angeblich gut lösen.

— geändert am 06.11.2009, 12:01:28

Antworten
Gelöschter Account
  • Mod
  • Forum-Beiträge: 3.188

06.11.2009, 12:16:39 via Website

Inwischen habe ich mir ein Widget installiert, mit dem man per Schalter einfacher alles ein- und auschalten kann. Das Display frist ist klar, das WLan ungefähr auf das gleiche kommt, hätte ich so nicht erwartet. Nun denn, werde mal alles beobachten.

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

06.11.2009, 13:58:28 via Website

Ob diese Anzeigen stimmen bezweifle ich sehr stark, da ich auf meinem G1 WLan abgeschaltet habe und trotzdem 53 % angezeigt werden.
Die Helligkeit des Displays lässt sich auch einstellen und somit könnte man da auch nochmals Akku sparen

Antworten
Gelöschter Account
  • Mod
  • Forum-Beiträge: 3.188

06.11.2009, 15:51:53 via Website

War das WLan immer ausgeschaltet ? Ich muss mal recherchieren, woher das Dingens seine Daten bezieht. Momentan wird ein Spielchen mit 50% Verbrauch angezeigt, das eigentlich schon ein paar Tage nicht mehr aktiv war, und das G1 zwischendurch auch ausgeschaltet war.

— geändert am 06.11.2009, 16:20:21

Antworten
Moritz L.
  • Forum-Beiträge: 434

06.11.2009, 16:00:44 via Website

Programme wie Taskiller oder Advanced Task Killer sind für sowas denke ich sehr hilfreich. Bei mir laufen jedenfalls ständig irgendwelche Sachen im Hintergrund weiter.

Antworten
Gelöschter Account
  • Mod
  • Forum-Beiträge: 3.188

06.11.2009, 17:33:08 via Website

Taskkiller habe ich drauf. Deswegen war ich ja verwundert, denn das Spielchen war auch nicht aktiv und war auch nicht im Hintergrund. Was mir bei der Akkuverbrauchanzeige fehlt, ist die Möglichkeit alles zurückzusetzen.

Antworten
Gelöschter Account
  • Admin
  • Forum-Beiträge: 3.718

06.11.2009, 17:42:26 via Website

Michael Hillebrand
Taskkiller habe ich drauf. Deswegen war ich ja verwundert, denn das Spielchen war auch nicht aktiv und war auch nicht im Hintergrund. Was mir bei der Akkuverbrauchanzeige fehlt, ist die Möglichkeit alles zurückzusetzen.

Du kannst die Akkuanzeige über das Menü aktualisieren

Antworten
Gelöschter Account
  • Mod
  • Forum-Beiträge: 3.188

06.11.2009, 17:47:08 via Website

Ich weiss, ändert aber nichts.

Antworten
Moritz L.
  • Forum-Beiträge: 434

06.11.2009, 18:48:17 via Website

Michael Hillebrand
Was mir bei der Akkuverbrauchanzeige fehlt, ist die Möglichkeit alles zurückzusetzen.

Handy an den Strom anschließen und wieder trennen oder ganz neu starten, dann wird der Verbrauch resettet, zumindest bei meinem Magic.

— geändert am 06.11.2009, 18:56:54

Antworten