No dobra, trochę się pomęczyłem z testowaniem. Zrobiłem backupa, i wgrałem najpierw villaina 4 beta v0.2a -> występuje to samo, i chyba teoria z dźwiękiem jest trafna. Po ustawieniu dzwonka, awake time zaczyna chodzić cały czas. Wgrałem dodatkowo jeden z pierwszych ROMów by sanpei v0.2 bazowany na erisie, na tym ROMie bateria całkiem nieźle mi chodziła. Ale również tutaj jest problem z awake time (również związany z dźwiękiem).
Wróciłem do robomixa, i postanowiłem potestować go trochę z zaglądaniem do logcata (dzięki robocik za dołączenie programu quickinfo, nie chciałoby mi się instalować znowu sterowników adb na kompie 😉 ). A oto rezultaty:
Długość testu: 15-20 min
Moje wnioski i legenda do logcatów po 2 teście na dole postu
Test 1: awake time dobrze chodzi, omijam szerokim łukiem aplikacje związane z dźwiękiem. Usypiam, godzina 13:07, budzę 13:21. Oto logcat (potrzebny do porównania z drugim testem bo jest różnica 😉 ): //od set_screen_state 0 do set_screen_state 1, czyli od wyłączenia ekranu do włączenia.
04-06 13:07:01.046 I power 98 *** set_screen_state 0
04-06 13:07:01.055 D CIQ 98 throwUI02
UI02
04-06 13:07:01.075 I HtcLockScreen 98 HtcLockScreen:onPause
clearArrowAnimation
04-06 13:07:01.075 D LockExchangeUtils 98 isLockExchangeEnabled = false
isLockExchangeEnabled = false
04-06 13:07:01.085 D BluetoothA2dpService 98 Received intent with action: android.intent.action.SCREEN_OFF
04-06 13:07:01.186 D SurfaceFlinger 98 About to give-up screen, flinger = 0x177800
screen given-up
04-06 13:07:12.259 V AutoSetting 249 receiver - ***onReceive: com.htc.app.autosetting.retrylocation
04-06 13:07:12.268 V AutoSetting 249 receiver - startAutosettingService, action: com.htc.app.autosetting.retrylocation,notifyWhenNoResult:false
04-06 13:21:21.540 D KeyguardViewMediator 98 wakeWhenReadyLocked(6)
mWakeAndHandOff.acquire() -- start
mWakeAndHandOff.acquire() -- end
handleWakeWhenReady(6)
pokeWakelock(15000)
04-06 13:21:21.540 I power 98 *** set_screen_state 1
Test 2. Wchodzę do ustawień dźwięku, ustawiam ponownie dzwonek żeby sobie zagrał, na kilkanaście sekund usypiam, żeby sprawdzić czy znowu zaczął ciągle chodzić awake time - zgadza się, świadomie zepsuty awake time 😉 13:48 wyłączony ekran, 14:09 wybudzony. Logcat ponownie od set_screen_state 0 do set_screen_state 1:
04-06 13:48:53.550 I power 98 *** set_screen_state 0
04-06 13:48:53.550 D KeyguardViewManager 98 show()
04-06 13:48:53.550 D LockExchangeUtils 98 isLockExchangeEnabled = false
04-06 13:48:53.560 D LockExchangeUtils 98 isLockExchangeEnabled = false
04-06 13:48:53.590 D CIQ 98 throwUI02
UI02
04-06 13:48:53.600 D BluetoothA2dpService 98 Received intent with action: android.intent.action.SCREEN_OFF
04-06 13:48:53.670 D SurfaceFlinger 98 About to give-up screen, flinger = 0x177800
screen given-up
04-06 13:48:53.690 D HtcLockScreen 98 onScreenRestart
04-06 13:48:53.690 I HtcLockScreen 98 updateStatusViewByPriority, mIsSimCheckView = false, mIsBatteryInfo = false, mIsMusicPlaying = false, mIsAirPlaneMode = false
clearAlertViewIcon
04-06 13:48:53.710 I HtcLockScreen 98 HtcLockScreen:onResume
04-06 13:48:53.850 D KeyguardViewMediator 98 handleKeyguardDoneDrawing: notifying mWaitingUntilKeyguardVisible
04-06 13:48:59.530 D dalvikvm 645 GC freed 479 objects / 24000 bytes in 205ms
04-06 13:49:05.630 D dalvikvm 147 GC freed 133 objects / 4952 bytes in 229ms
04-06 13:49:10.580 D dalvikvm 149 GC freed 19 objects / 664 bytes in 168ms
04-06 13:50:05.620 D dalvikvm 249 GC freed 901 objects / 35656 bytes in 218ms
04-06 13:51:00.750 D dalvikvm 98 GC freed 27257 objects / 1450872 bytes in 556ms
04-06 13:51:06.220 D dalvikvm 439 GC freed 1773 objects / 140568 bytes in 200ms
04-06 13:51:11.220 D dalvikvm 470 GC freed 1286 objects / 88832 bytes in 200ms
04-06 13:51:16.220 D dalvikvm 499 GC freed 1167 objects / 78864 bytes in 197ms
04-06 13:51:21.210 D dalvikvm 478 GC freed 604 objects / 31768 bytes in 189ms
04-06 14:05:14.560 D dalvikvm 499 GC freed 269 objects / 20344 bytes in 171ms
04-06 14:09:20.980 D KeyguardViewMediator 98 wakeWhenReadyLocked(6)
mWakeAndHandOff.acquire() -- start
mWakeAndHandOff.acquire() -- end
handleWakeWhenReady(6)
pokeWakelock(15000)
04-06 14:09:20.980 I power 98 *** set_screen_state 1
Niebieskim kolorem zaznaczyłem ostatnią linijkę przy usypianiu telefonu, którą oba testy mają wspólną - później się różnią.
Zielonym kolorem zaznaczyłem linijkę, w której w obu testach telefon wychodzi z uśpienia i dalej działa tak samo.
Nas interesuje to co jest pomiędzy tymi dwoma linijkami, czyli czym się różnią te dwie sytuacje (kolorem czerwonym).
Test 1
W pierwszym przypadku mamy jakieś dwie linijki na czerwono, nie wiem czy mają coś wspólnego z zżeraniem baterii, ale one nie występują w kolejnym teście więc je zaznaczyłem na czerwono. Możliwe, że się pojawiły tam, bo jest to po rebootcie. W każdym razie po tych dwóch linijkach mamy ciszę, nic nam telefon nie robi, dopiero budzi się po naciśnięciu przycisku power (zaznaczone na niebiesko). Tu chodzi ok awake time.
Test 2
I tutaj mamy już dużo więcej czerwonego. Nie wiem co myśleć o kilku linijkach HtcLockScreen, ale wydaje mi się, że prawie na pewno niepożądane są linijki typu:
04-06 13:49:05.630 D dalvikvm 147 GC freed 133 objects / 4952 bytes in 229ms
Zmieniają się tam tylko cyfry. Uaktywnia się to zaraz po zablokowaniu (13:49), później 13:51, 14:05. Nie mam pojęcia co to są za działania, ale biorąc pod uwagę, że sytuacja z testu nr 1 była u Edka Łomiarza w nocy i bateria nie zeszła ani o 1%, a sytuacja z testu nr 2 była u mnie i bateria zeszła o kilkanaście %, to chyba mogę stwierdzić że to coś pożera baterię.
Test nr 3 potwierdzający
W trakcie pisania tego postu, również wyłączyłem telefon, wybudziłem i zajrzałem do logcata. Nie będę przytaczał wyników, bo i tak już Wam sporo natrułem tym postem. Wyłączony 14:16 (nasz niebieska linijka), wybudzony 14:40. Między tym trochę linijek, które wyszczególniłem w 2 teście na czerwono. Telefon robi coś o 14:20, 14:25, 14:35.
To by było na razie tyle z mojej strony, mam nadzieję, że robocikowi to pomoże 🙂
PS: Tak BTW to co się dzieje z forum? Coś kombinują z technicznymi sprawami czy co? (error 404)