Since there's so "high" idle battery drain
(7% per 10 hours if several apps are disabled, PowerNap + Greenify running)
compared to the baseline which usually should be there (1% per several hours)
I've taken a look at the MRA (mobile radio active) bug of Lollipop and it still appears to be there and triggerable on MM:
https://code.google.com/p/android/issues/detail?id=165558
Luckily there's a XPosed module for it:
http://repo.xposed.info/module/com.pyler.mobileradioactivefix
but there reportedly have been bootloops and other issues with that version,
so @glauberlima has stepped up to the rescue to make it more compatible with MM: http://forum.xda-developers.com/showpost.php?p=65068405&postcount=183 Version 1.2 DEBUG BUILD - No more bootloops!
I've disabled MyXperia and dozens other components that reportedly used to work (and help) on the Z3 with battery runtime,
but my Z5 is happily draining along compared to AOSP or CM
This for the actual moment is something like my last straw to get it to a really great idle battery runtime
Anyone tried it ?
Hello,
(Owning Z5 compact, currently on E5823_Customized FR_1299-1743_32.1.A.1.163_R5C, stock kernel repacked to get root).
I too am struggling to get good standby battery drain.
I tried a lot of things, and I never lose less than 1% / hour (testing different things every night, during 6-7 hours).
A friend's HTC One A9 on 6.0.1 lose 1% every 3-5 hours... I'd like to get that.
I also wait to get below 95% to begin a test (if just full charged, one can stick to 100% for hours, so let it unstick from that to get correct numbers).
I have no background app (no facebook/whatsapp & co). All sync'ing disabled. All wifi/bluetooth/nfc/gps/mobile data disabled. Sticking to 2G, signal 'great'.
I tried airplane mode, wifi off. I also tried a night in safe mode (you lose ur widget settings, but at least no market app is running) with 2G : always 1%/h.
Even when Doze activates, it changes nothing ; I tried agressive doze, i even tried disabling doze (thinking motion detection could be the culprit) by setting a high 'inactive_to' value : no change, always 1%/h.
CPU Spy and alike apps report 99% deep sleep.
I tried activating powersave governor (all core stuck to 340 Mhz) : still 1%/h.
I tried some analysis with GSam battery monitor, BetterBatteryStats, Wakelock Detector, nothing shocking.
Found yesterday another more detailed way to analyse battery stats :
(oups, can't post links, so search google for "batterystats historian")
adb shell dumpsys batterystats > batterystats.txt
You can get a python script that will make a nice HTML page from that batterystats.txt, so you can see everything that happened in the night :
(go to the github link, click on '18 commits', find 'Sync with internal version 44.', click on it, then view, and you can get historian.py , the latest python standalone single script, before they made something bigger in Go).
The sad things is that not much happens ! A dozen wakelocks and alarms for some google apps, some broadcast of GCM_RECONNECT, never actvating for more than 1 second.
And my friend's HTC One A9 gets the same events during the night, and dont lose as many % !
So, my conclusions with all this :
- The drain is not due to Android system and its activity (even Google's apps). So, no greenify/amplify/doze tweak will change anything.
- I checked linux processes after 24 hours, really not much process accounting for more than 10s cpu use.
- I tested for a few days with AndroPlus kernel v20: same 1%/h
- I dont really understand this mobile data bug. I dont use mobile data, always on 2G, only wifi when needed : does that mean i can't be impacted by this bug, and that we can rule it out ?
I think that during the few days I was on Lollipop, I got the feeling of great standby low-drain. But i may have started at 100% and rejoice when seeing 99% in the morning.
Could it be that the radio/baseband firmware that was updated with MM is now draining ? Does airplace mode really shut radio chip off ? (it may drain without being accounted by android's battery stats).
Do people that updated to 32.1.A.1.185 noticed a change (baseband version was updated in .185) ?
I'd like people that do NOT observe > 1%/h standby drain to tell their versions (LL, MM, region, stock kernel or else, rooted or not), even if Z5/Z5P, not only Z5C ?
Could it be that some cpu cores are not offline or sleeping when the system is inactive ? (I dont know how cpuspy/cpuZ report some single cpu states, when we have 8 cores that can all be in different states) ?
Or is it some other piece of hardware that is draining ? Or the battery itself ?
Thanks for the feedback.
(a bit tired struggling with this, if nobody gets less drain, at least I can admit it's the phone, and focus on something else)
LolaPalocz said:
Could it be that the radio/baseband firmware that was updated with MM is now draining ? Does airplace mode really shut radio chip off ? (it may drain without being accounted by android's battery stats).
Do people that updated to 32.1.A.1.185 noticed a change (baseband version was updated in .185) ?
I'd like people that do NOT observe > 1%/h standby drain to tell their versions (LL, MM, region, stock kernel or else, rooted or not), even if Z5/Z5P, not only Z5C ?
Could it be that some cpu cores are not offline or sleeping when the system is inactive ? (I dont know how cpuspy/cpuZ report some single cpu states, when we have 8 cores that can all be in different states) ?
Or is it some other piece of hardware that is draining ? Or the battery itself ?
Thanks for the feedback.
(a bit tired struggling with this, if nobody gets less drain, at least I can admit it's the phone, and focus on something else)
Click to expand...
Click to collapse
Hello, last night i got about 0,7%/h standby drain (8 hours, offline mode, running MM .185, Z5c), but it's usually more around 1%. No excessive wakelocks, practically always in deepsleep, and doze mode (with default values) activated correctly. If i remember well, on stock Lollipop it was similar. I am rooted, with xposed and some modules.
On my previous Android phone it was less.
It could be related simply to SD 810 or it could be related to not optimized kernel. Or battery calculation incorrect?
If you have time, you could try also analyzing logcat and dmesg log.
And we should try running tests on stock non rooted no xposed.
Does your Wifi activity go off when you are in offline/mobile data mode? You can check it in battery usage -> tap on the graphic draw of battery decrease
I noticed that even on Data mobile mode, "wlan_wd_wake" alarm count keeps growing second after second.
It stops only when phone goes in offline mode. It has an enormous count number on my phone, still with low minutes on.
Might it be a Wifi driver issue?
Thanks for the feedback.
So LL and .185 are no obvious solutions.
I checked logcat & co, nothing obvious.
And I dont have wifi nor data enabled, I only activate them when i need them. I want my smartphone to be a dumb phone during the night and in my pocket
Other things I tried :
- removed SIM and SD cards during the night : still 1%/h
- let wifi active (so that sony's and google's background apps would get what they want and stop trying) : still 1%/h (not really more drain than what I see when everything is off).
I even let the phone powered off during a night to see if there was some residual drain of the battery : stayed at 64% ! Good, it's not a hardware deffect !
Just installed this morning xposed with amplify and powernap. I'll see what happen with them.
PS: "wd" in "wlan_wd_wake" means "watchdog", so may be you have some option like "scan wifi network to guess my location" (battery efficient GPS-like), and it is scanning wifi SSID around to transmit them to google via your data connection ?
LolaPalocz said:
Thanks for the feedback.
So LL and .185 are no obvious solutions.
I checked logcat & co, nothing obvious.
And I dont have wifi nor data enabled, I only activate them when i need them. I want my smartphone to be a dumb phone during the night and in my pocket
Other things I tried :....
PS: "wd" in "wlan_wd_wake" means "watchdog", so may be you have some option like "scan wifi network to guess my location" (battery efficient GPS-like), and it is scanning wifi SSID around to transmit them to google via your data connection ?
Click to expand...
Click to collapse
Are you using torch during the evening? I noticed that using flashlight seems not to clearly decrease battery: either it's not a big drain (for the few minutes i use it) or it is not correctly reported to the battery monitor.
Thanks for the info, it was probably the location option "always scan for wifi even if it is not connected" that triggered wlan_wd_wake. Still, in my opinion, wlan kernel wakelocks/wlan drivers could be further optimized by Sony.
Speculating on your tests, it seems that , generally, hardware components suck too much battery on idle mode. This might or might not be optimizable with new drivers. If it is the normal idle consumption of the Snapdragon 810, then we could not do much, i suppose.
@zacharias.maladroit i see you started this topic, and now you are developing a kernel for z5 and z5c.
What do you think about our tests and opinions?
Never using flashlight, so can't say.
Spent the night with amplify and powernap, set up to the point of not even updating clocks (status bar and widget) : still 1%/ hour, with very clean batterystats (only a few wake triggered from rtc alarm, that I guess Amplify can't prevent, just intercept) (the numbers 022-018 are battery %) :
Code:
[FONT="Courier New"][SIZE="2"] +8h41m22s968ms (2) 022 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+8h41m23s417ms (1) 022 -running
+8h43m29s580ms (2) 022 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+8h43m30s051ms (1) 022 -running
+8h44m19s130ms (2) 022 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+8h44m19s611ms (1) 022 -running
+9h09m50s982ms (3) 022 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h09m51s440ms (1) 022 -running
+9h12m36s122ms (2) 021 volt=7399 +running
Details: cpu=179840u+157680s
/proc/stat=254070 usr, 150670 sys, 7480 io, 22050 irq, 7740 sirq, 4278000 idle (9,4% of 13h 6m 40s 100ms)
+9h12m36s126ms (3) 021 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+9h12m36s144ms (2) 021 stats=0:"get-stats"
+9h12m37s558ms (1) 021 -running
+9h39m50s981ms (3) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h39m51s427ms (1) 021 -running
+9h44m49s974ms (2) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h44m50s454ms (1) 021 -running
+9h51m52s998ms (2) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h51m53s436ms (1) 021 -running
+10h09m50s982ms (3) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+10h09m53s949ms (1) 021 -running
+10h23m07s976ms (3) 020 temp=242 +running
Details: cpu=0u+0s
/proc/stat=0 usr, 0 sys, 0 io, 0 irq, 0 sirq, 0 idle
+10h23m07s987ms (3) 020 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+10h23m08s221ms (2) 020 stats=0:"get-stats"
+10h23m09s458ms (1) 020 -running
+10h39m51s010ms (3) 020 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+10h39m51s462ms (1) 020 -running
+11h06m53s721ms (3) 020 +running wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h06m55s204ms (1) 020 -running
+11h09m51s027ms (2) 020 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h09m51s515ms (1) 020 -running
+11h21m16s573ms (3) 020 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+11h21m17s211ms (1) 020 -running
+11h21m17s265ms (2) 020 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+11h21m17s742ms (1) 020 -running
+11h54m25s045ms (3) 019 +running
Details: cpu=1160u+2440s
/proc/stat=1410 usr, 2330 sys, -150 io, 100 irq, 40 sirq, -270630 idle
+11h54m25s058ms (3) 019 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+11h54m25s103ms (2) 019 stats=0:"get-stats"
+11h54m26s537ms (1) 019 -running
+11h58m08s043ms (2) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h58m08s524ms (1) 019 -running
+12h27m41s052ms (3) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+12h27m43s151ms (1) 019 -running
+12h29m49s048ms (2) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+12h29m49s533ms (1) 019 -running
+12h41m34s068ms (3) 018 +running
Details: cpu=1510u+1930s
/proc/stat=1420 usr, 1780 sys, 30 io, 160 irq, 30 sirq, 3590 idle (48,8% of 1m 10s 100ms)
+12h41m34s072ms (3) 018 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+12h41m34s135ms (2) 018 stats=0:"get-stats"
+12h41m35s544ms (1) 018 -running
+12h58m08s061ms (4) 018 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"get-stats"[/SIZE][/FONT]
Strange thing I always see in batterystats output :
Code:
[FONT="Courier New"][SIZE="2"] Estimated power use (mAh):
Capacity: 2700, [COLOR="SeaGreen"]Computed drain: 317[/COLOR], actual drain: 540-567
[B][COLOR="Red"]Unaccounted: 223 ( )[/COLOR][/B]
Screen: 94.8
Cell standby: 87.0 ( radio=87.0 )
Idle: 63.9
Phone calls: 47.8
Uid 0: 7.80 ( cpu=6.60 wake=1.20 wifi=0.0000475 )
Uid u0a284: 4.64 ( cpu=4.64 )
Uid 1000: 3.00 ( cpu=2.36 wake=0.562 wifi=0.0000146 sensor=0.0766 )[/SIZE][/FONT]
I'd be happy without these mAH unaccounted :|
I guess these numbers of mAH are not measured, but computed from some rules and the time spent in each state. And I've been always observing that Unaccounted makes like 30-50 % of the actual drain...
So, maybe Sony's have their computing rules wrong. And radio or the kernel uses more power / cpusecond that they estimated...
Did a full wipe this morning and installed .185 NOBA (thinking the radio update could help), unlocked but not yet rooted. All wifi/data disabled, no google account yet set : still 1%/h over a few hours not using it...
Also curious about Zacharias's thoughts !
Posting some other test results, for completeness.
All with 2G, data/wifi/bt/nfc/gps disabled, with no google account setup. Observed over a 7 hours standby night :
Code:
MM .185 NOBA : still 1 %/h
LL .200 normal : 1 %/h
LL .200 with stamina mode : 0.8 %/h
LL .200 with ultra stamina mode : 1.3 %/h (!)
Before giving up testing and going back to .185, I installed CTXz's build of CM13 (unnofficial, alpha) with GApps pico and got ... 0.3%/h !
Quite amazing. The process list is quite cleaner (without all the sony apps), but, according to batterystats, the wakelocks distribution does not seem very different than with stock ROMs...
I don't get how standby battery usage can be so different...
Only thing I observed is, when screen on but idle :
- stock or androplus kernel : all 4 little cores online, 1 or 2 big cores online
- cm13 : only 1 little core online, 0 big core online
But in standby and with screen off, all the 8 cores should be offline (can't verify thus).
I still got 0.3%/h after setting up a google account and installing a few apps.
Quite usable (except camera and fingerprint are not working). Althought a few time when taking the phone out of sleep, it was crashed, probably for a few hours (needed Vol Up + power to powert it on again...
I've the same issue. By example this night, I lost 14% for 12h of idle.
I tried several things like you LolaPalocz, like the airplane mode, the WiFi off, or the location off, but without success...
I've an E6633 (Z5 Dual), with the MM .185 ROM, unlocked BL, and rooted device. Also, I use Greenify, PowerNap, Amplify, but they don't help me :/
When I was on LL with the STAMINA enabled, I didn't have this issue, really ><
So, I'm waiting to see if the return of STAMINA will change something or not, in a next update (the STAMINA mode is already reimplanted in the japanese ROM).
LolaPalocz said:
Posting some other test results, for completeness.
....
....
Only thing I observed is, when screen on but idle :
- stock or androplus kernel : all 4 little cores online, 1 or 2 big cores online
- cm13 : only 1 little core online, 0 big core online
But in standby and with screen off, all the 8 cores should be offline (can't verify thus).
I still got 0.3%/h after setting up a google account and installing a few apps.
Quite usable (except camera and fingerprint are not working). Althought a few time when taking the phone out of sleep, it was crashed, probably for a few hours (needed Vol Up + power to powert it on again...
Click to expand...
Click to collapse
Again good information and tests, thank you.
I don't know how CPU core management is different in CM13 build for Z5, we should ask the author.
One thing i think is that we need at least one week tests to produce rational results. One night is just not enough. If you still have CM13 running on your device, if you can, you can keep the rom and update your results after some days.
One other hypotesis is that during long sleep there's a kind of slow recalculation of the remaining battery power. Maybe it's just a stupid fantasy.
Unfortunately Zacharias didn't reply. I don't want to bother him with private messages if he chosed not to continue here.
Maybe we can check the commits that are added to his kernel source to see if he's addressing this "issue" (and also Androplus).
Overall, i'm satisfied with the battery life (using amplify, greenify with aggressive doze, doze settings editor...), i can reach 2 days with about 4h/ 5h screen on time and 1 hour 2G call.
LolaPalocz said:
Never using flashlight, so can't say.
Spent the night with amplify and powernap, set up to the point of not even updating clocks (status bar and widget) : still 1%/ hour, with very clean batterystats (only a few wake triggered from rtc alarm, that I guess Amplify can't prevent, just intercept) (the numbers 022-018 are battery %) :
Code:
[FONT="Courier New"][SIZE="2"] +8h41m22s968ms (2) 022 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+8h41m23s417ms (1) 022 -running
+8h43m29s580ms (2) 022 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+8h43m30s051ms (1) 022 -running
+8h44m19s130ms (2) 022 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+8h44m19s611ms (1) 022 -running
+9h09m50s982ms (3) 022 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h09m51s440ms (1) 022 -running
+9h12m36s122ms (2) 021 volt=7399 +running
Details: cpu=179840u+157680s
/proc/stat=254070 usr, 150670 sys, 7480 io, 22050 irq, 7740 sirq, 4278000 idle (9,4% of 13h 6m 40s 100ms)
+9h12m36s126ms (3) 021 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+9h12m36s144ms (2) 021 stats=0:"get-stats"
+9h12m37s558ms (1) 021 -running
+9h39m50s981ms (3) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h39m51s427ms (1) 021 -running
+9h44m49s974ms (2) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h44m50s454ms (1) 021 -running
+9h51m52s998ms (2) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+9h51m53s436ms (1) 021 -running
+10h09m50s982ms (3) 021 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+10h09m53s949ms (1) 021 -running
+10h23m07s976ms (3) 020 temp=242 +running
Details: cpu=0u+0s
/proc/stat=0 usr, 0 sys, 0 io, 0 irq, 0 sirq, 0 idle
+10h23m07s987ms (3) 020 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+10h23m08s221ms (2) 020 stats=0:"get-stats"
+10h23m09s458ms (1) 020 -running
+10h39m51s010ms (3) 020 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+10h39m51s462ms (1) 020 -running
+11h06m53s721ms (3) 020 +running wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h06m55s204ms (1) 020 -running
+11h09m51s027ms (2) 020 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h09m51s515ms (1) 020 -running
+11h21m16s573ms (3) 020 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+11h21m17s211ms (1) 020 -running
+11h21m17s265ms (2) 020 +running wake_reason=0:"200:qcom,smd-rpm:57:qcom,smd-modem"
+11h21m17s742ms (1) 020 -running
+11h54m25s045ms (3) 019 +running
Details: cpu=1160u+2440s
/proc/stat=1410 usr, 2330 sys, -150 io, 100 irq, 40 sirq, -270630 idle
+11h54m25s058ms (3) 019 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+11h54m25s103ms (2) 019 stats=0:"get-stats"
+11h54m26s537ms (1) 019 -running
+11h58m08s043ms (2) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+11h58m08s524ms (1) 019 -running
+12h27m41s052ms (3) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+12h27m43s151ms (1) 019 -running
+12h29m49s048ms (2) 019 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm"
+12h29m49s533ms (1) 019 -running
+12h41m34s068ms (3) 018 +running
Details: cpu=1510u+1930s
/proc/stat=1420 usr, 1780 sys, 30 io, 160 irq, 30 sirq, 3590 idle (48,8% of 1m 10s 100ms)
+12h41m34s072ms (3) 018 wake_reason=0:"485:delta-soc:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"battery-level"
+12h41m34s135ms (2) 018 stats=0:"get-stats"
+12h41m35s544ms (1) 018 -running
+12h58m08s061ms (4) 018 +running wake_reason=0:"459:qpnp_rtc_alarm:222:fc4cf000.qcom,spmi:200:qcom,smd-rpm" stats=0:"get-stats"[/SIZE][/FONT]
Strange thing I always see in batterystats output :
Code:
[FONT="Courier New"][SIZE="2"] Estimated power use (mAh):
Capacity: 2700, [COLOR="SeaGreen"]Computed drain: 317[/COLOR], actual drain: 540-567
[B][COLOR="Red"]Unaccounted: 223 ( )[/COLOR][/B]
Screen: 94.8
Cell standby: 87.0 ( radio=87.0 )
Idle: 63.9
Phone calls: 47.8
Uid 0: 7.80 ( cpu=6.60 wake=1.20 wifi=0.0000475 )
Uid u0a284: 4.64 ( cpu=4.64 )
Uid 1000: 3.00 ( cpu=2.36 wake=0.562 wifi=0.0000146 sensor=0.0766 )[/SIZE][/FONT]
I'd be happy without these mAH unaccounted :|
I guess these numbers of mAH are not measured, but computed from some rules and the time spent in each state. And I've been always observing that Unaccounted makes like 30-50 % of the actual drain...
So, maybe Sony's have their computing rules wrong. And radio or the kernel uses more power / cpusecond that they estimated...
Did a full wipe this morning and installed .185 NOBA (thinking the radio update could help), unlocked but not yet rooted. All wifi/data disabled, no google account yet set : still 1%/h over a few hours not using it...
Also curious about Zacharias's thoughts !
Click to expand...
Click to collapse
I'm also experiencing unaccounted battery use and its draining 1%/h when screen off and i see no issues from battery stats app. Even android battery usage does not show usage properly and its missing something which is draining from the chart as I can see only 21%(15% phone idle, 6% wifi) and nothing else to make up 100% which is really strange. Do you have any ideas about my issue with android battery usage not showing 100% usage ?
Thanks
Related
Hello everyone,
I’ve been trying to find a solution for this problem but haven’t found a precise/working solution yet so I thought to ask if someone would have solved or encountered this problem with Samsung Galaxy Tab P1000. My problem is as follows:
My phone got water/moist damage (wine to be precise). The phone still worked fine 2 weeks afterwards but then when some rusting started to happen the problem arrived as well. Now when I connect a charger to the phone it tells: “Charging paused. Battery temperature too high or too low”
When I was searching through the web I found than someone had found a solution for other Samsung phone (he did not mention what model it was), and the solution was as follows:
“I noticed there was some internal phone menus dealing with charging temperature. Using this method I was able to resolve my problem for now:
step 1. *#197328640#
step 2. [9] common
step 3. [1] Batt, Temp
-> next to Batt temp ADC it said 254 for me. Obviously it's incorrect, I think the sensor for the battery temp somehow messed up. Take note of that number.
step 4. Go back to the main menu and select [2] Version Information
step 5. [4] Charging Temperature
step 6. I changed [1] high stop to 255 and [2] high recover to 254.
With those changes, my phone now actually charges off the wall and car charger. Anyways hopefully this helps someone.”
I tried to do this but because this was not Galagy Tab (GT-P1000) I could not find settings for charging temperature to change high stop and high recovery values (Of course did found a lot of other options). By going more through the internet I could find list of phone codes for GT-P1000 and with one code: “*#0228#" (ADC Reading) I was able to get info on what my phone “thinks” the values are:
Voltage: 3734.0 (mV)
ADC: 0
Temperature: -21.0 (‘C)
ADC: 800
VF ADC : 0
Level: 29 (%)
Average Value
Voltage: 0.0 (mV)
ADC: 0
Cal.: 0
Temperature: -21.0 (‘C)
ADC: 810
It basically seems that the temperature probe is damaged due to the moist damage (the base value is lost downwards like > 40 degrees).
So the does anyone know how can I change ADC acceptance values in Galaxy Tab? Or any other solutions for the problem like switching off the temperature indicator or change its base value that I can “jump” it to range where my phone will accept charging. Any other solution rather than buying a new phone would be more than appreciated.
For any advice, thank you in advance.
-Antti
AnttiSoininen said:
Hello everyone,
I’ve been trying to find a solution for this problem but haven’t found a precise/working solution yet so I thought to ask if someone would have solved or encountered this problem with Samsung Galaxy Tab P1000. My problem is as follows:
My phone got water/moist damage (wine to be precise). The phone still worked fine 2 weeks afterwards but then when some rusting started to happen the problem arrived as well. Now when I connect a charger to the phone it tells: “Charging paused. Battery temperature too high or too low”
When I was searching through the web I found than someone had found a solution for other Samsung phone (he did not mention what model it was), and the solution was as follows:
“I noticed there was some internal phone menus dealing with charging temperature. Using this method I was able to resolve my problem for now:
step 1. *#197328640#
step 2. [9] common
step 3. [1] Batt, Temp
-> next to Batt temp ADC it said 254 for me. Obviously it's incorrect, I think the sensor for the battery temp somehow messed up. Take note of that number.
step 4. Go back to the main menu and select [2] Version Information
step 5. [4] Charging Temperature
step 6. I changed [1] high stop to 255 and [2] high recover to 254.
With those changes, my phone now actually charges off the wall and car charger. Anyways hopefully this helps someone.”
I tried to do this but because this was not Galagy Tab (GT-P1000) I could not find settings for charging temperature to change high stop and high recovery values (Of course did found a lot of other options). By going more through the internet I could find list of phone codes for GT-P1000 and with one code: “*#0228#" (ADC Reading) I was able to get info on what my phone “thinks” the values are:
Voltage: 3734.0 (mV)
ADC: 0
Temperature: -21.0 (‘C)
ADC: 800
VF ADC : 0
Level: 29 (%)
Average Value
Voltage: 0.0 (mV)
ADC: 0
Cal.: 0
Temperature: -21.0 (‘C)
ADC: 810
It basically seems that the temperature probe is damaged due to the moist damage (the base value is lost downwards like > 40 degrees).
So the does anyone know how can I change ADC acceptance values in Galaxy Tab? Or any other solutions for the problem like switching off the temperature indicator or change its base value that I can “jump” it to range where my phone will accept charging. Any other solution rather than buying a new phone would be more than appreciated.
For any advice, thank you in advance.
-Antti
Click to expand...
Click to collapse
Hi Antti, I am just curious, how do you know your sensor is damaged and it has rusted? It may be caused by malfunction of the processor detecting from the temperature of the battery.
Secondly, your level 29% doesn't tally with 3734.0mV. Theoretically, when battery reaches almost zero, it should read close to 3200mV, fully charge it should be 4200mV. I am assuming that this is the battery percentage indication for your battery, please do a check on by going > Settings=>About Device=>Status and check battery level. If it is 29%, your battery status has gone "crazy" and so does your temperature readings.
Just leave a feedback if you have such an issue.
AnttiSoininen said:
Hello everyone,
I’ve been trying to find a solution for this problem but haven’t found a precise/working solution yet so I thought to ask if someone would have solved or encountered this problem with Samsung Galaxy Tab P1000. My problem is as follows:
My phone got water/moist damage (wine to be precise). The phone still worked fine 2 weeks afterwards but then when some rusting started to happen the problem arrived as well. Now when I connect a charger to the phone it tells: “Charging paused. Battery temperature too high or too low”
When I was searching through the web I found than someone had found a solution for other Samsung phone (he did not mention what model it was), and the solution was as follows:
“I noticed there was some internal phone menus dealing with charging temperature. Using this method I was able to resolve my problem for now:
step 1. *#197328640#
step 2. [9] common
step 3. [1] Batt, Temp
-> next to Batt temp ADC it said 254 for me. Obviously it's incorrect, I think the sensor for the battery temp somehow messed up. Take note of that number.
step 4. Go back to the main menu and select [2] Version Information
step 5. [4] Charging Temperature
step 6. I changed [1] high stop to 255 and [2] high recover to 254.
With those changes, my phone now actually charges off the wall and car charger. Anyways hopefully this helps someone.”
I tried to do this but because this was not Galagy Tab (GT-P1000) I could not find settings for charging temperature to change high stop and high recovery values (Of course did found a lot of other options). By going more through the internet I could find list of phone codes for GT-P1000 and with one code: “*#0228#" (ADC Reading) I was able to get info on what my phone “thinks” the values are:
Voltage: 3734.0 (mV)
ADC: 0
Temperature: -21.0 (‘C)
ADC: 800
VF ADC : 0
Level: 29 (%)
Average Value
Voltage: 0.0 (mV)
ADC: 0
Cal.: 0
Temperature: -21.0 (‘C)
ADC: 810
It basically seems that the temperature probe is damaged due to the moist damage (the base value is lost downwards like > 40 degrees).
So the does anyone know how can I change ADC acceptance values in Galaxy Tab? Or any other solutions for the problem like switching off the temperature indicator or change its base value that I can “jump” it to range where my phone will accept charging. Any other solution rather than buying a new phone would be more than appreciated.
For any advice, thank you in advance.
-Antti
Click to expand...
Click to collapse
so did you fixed it?
AnttiSoininen said:
Hello everyone,
I’ve been trying to find a solution for this problem but haven’t found a precise/working solution yet so I thought to ask if someone would have solved or encountered this problem with Samsung Galaxy Tab P1000. My problem is as follows:
My phone got water/moist damage (wine to be precise). The phone still worked fine 2 weeks afterwards but then when some rusting started to happen the problem arrived as well. Now when I connect a charger to the phone it tells: “Charging paused. Battery temperature too high or too low”
When I was searching through the web I found than someone had found a solution for other Samsung phone (he did not mention what model it was), and the solution was as follows:
“I noticed there was some internal phone menus dealing with charging temperature. Using this method I was able to resolve my problem for now:
step 1. *#197328640#
step 2. [9] common
step 3. [1] Batt, Temp
-> next to Batt temp ADC it said 254 for me. Obviously it's incorrect, I think the sensor for the battery temp somehow messed up. Take note of that number.
step 4. Go back to the main menu and select [2] Version Information
step 5. [4] Charging Temperature
step 6. I changed [1] high stop to 255 and [2] high recover to 254.
With those changes, my phone now actually charges off the wall and car charger. Anyways hopefully this helps someone.”
I tried to do this but because this was not Galagy Tab (GT-P1000) I could not find settings for charging temperature to change high stop and high recovery values (Of course did found a lot of other options). By going more through the internet I could find list of phone codes for GT-P1000 and with one code: “*#0228#" (ADC Reading) I was able to get info on what my phone “thinks” the values are:
Voltage: 3734.0 (mV)
ADC: 0
Temperature: -21.0 (‘C)
ADC: 800
VF ADC : 0
Level: 29 (%)
Average Value
Voltage: 0.0 (mV)
ADC: 0
Cal.: 0
Temperature: -21.0 (‘C)
ADC: 810
It basically seems that the temperature probe is damaged due to the moist damage (the base value is lost downwards like > 40 degrees).
So the does anyone know how can I change ADC acceptance values in Galaxy Tab? Or any other solutions for the problem like switching off the temperature indicator or change its base value that I can “jump” it to range where my phone will accept charging. Any other solution rather than buying a new phone would be more than appreciated.
For any advice, thank you in advance.
-Antti
Click to expand...
Click to collapse
reflash with stock rom and test again for me that is a problem with hardware...
Help
I have the same problem , any one can help me?
Sam
for me i try to buy new charger at first ok. the temp problem gone. but another come out
when it says battery full when i unplug the charger it went down to 65 or 70 then i need to plug it again after few hours say 2 hour it will indicate again battery full
at this time its really full
i am facing the same problem right now.
notification: charging problem. battery temperature too high or too low.
battery status (*#0228):
current value:-
voltage: 3739.0 (mV)
adc: 0
temperature: 7.0 ('C)
adc: 0
vf adc: 0
level: 72%
actually my phone got splashed with water and i found out that the water got into the speaker when i open the back cover, i can see (a little) water.
some suggestion on how to fix this error? maybe some software or hardware modification?
update 26/06/12:
- my gtab haven't charged for 2 days now. last night i power off, then just this afternoon i power on it back to see the status. last night battery level is >20%, when it power on just now, is says only 8%, checking *#0228#
voltage: 3832.0 (mV)
temperature: 41.9 ('C)
level: 10%
- i think the water on the motherboard/battery has dry (remarks, saltwater) and now the circuit/electronic/battery is back to normal.
- if anything wrong again i update it here.
Accessing menus?
Sorry but I must not have seen the correct page or forum yet, but where do you enter this :
battery status (*#0228):
I need to change the battery charging temperature on my gt-p1000r but I don't seem to be able to access any place to do this.
I have rooted it. And I have tried to enter various codes into memo with out any success. Just need a little help or direction with this one.
Thanks,
Need to set my battery charging temperature
jasoncummer said:
Sorry but I must not have seen the correct page or forum yet, but where do you enter this :
battery status (*#0228):
I need to change the battery charging temperature on my gt-p1000r but I don't seem to be able to access any place to do this.
I have rooted it. And I have tried to enter various codes into memo with out any success. Just need a little help or direction with this one.
Thanks,
Click to expand...
Click to collapse
Just a bump I still haven't had a response from any of the forums I've posted on.
any one have a Samsung technical repair line I can call?
A little bump in this old post.
Let me know if anyone had a work around
Sent from my GT-I9300T using Tapatalk 2
Cool %Battery Drain/Hr Widget using Tasker and Minimalistic Text
Minimalist widget that displays:
- % of battery drain or charge per hour... ie "-6.89 /hr"
- time in hours remaining till fully charged or discharged at the accumulated average % drain per hour... ie "14.2 hrs"
- % of battery lost or gained in hours since plugged in or unplugged... ie "-2% in 0.29"
Requires Minimalistic Text App from Market: https://market.android.com/details?id=de.devmil.minimaltext&hl=en
If anyone has any suggestions on how to simplify it... let me know.
4 Profiles Total:
Profile 1 - OnBoot - Clears and sets variables for new battery drain/charge stats
Profile 2 - PluggedIn (AC or USB) - Clears and sets variables for new battery drain/charge stats
Profile 3 - BattCharging - Calculates %charge/hr, time till 100% charge and %battery increase since start of charging
Profile 4 - BattDraining - Calculates %drain/hr, time till 0% charge and %battery decrease since start of discharging
The first two profiles are designed to clear and reset the battery% and timestart variables when the phone boots up or when the power profile changes. The first one is the OnBoot profile which is a useful profile to have in the first place. You can have your phone start a program or do some other useful task when your phone first starts up.
The second one will activate when the phone is plugged in either via usb or the wall plug. This is also a useful profile for other reasons... for example you can make your timeout longer when the phone is plugged in and make it go back to a shorter timeout when it's unplugged with the exit task.
I would imagine some people already have an OnBoot and a Charging profile, so just add the following tasklist to them to keep from cluttering up your tasks if it's viable, otherwise just create the profiles as they are below.
Profile 1: OnBoot
Context: Event > System > Device Boot
Task:
1. Variable Clear: %BATTSTART
2. Variable Clear: %TIMESTART
3. Variable Set: %BATTSTART To %BATT
4. Variable Set: %TIMESTART To %TIMES
5. Minimalistic Text: Configuration - %BATTDRAIN = Please
6. Minimalistic Text: Configuration - %BATTLEFT = wait...
7. Minimalistic Text: Configuration - %TIMEBATT = (blank)
Profile 2: PluggedIn
Context: - Choose State > Power > Power > Source: Any
Task:
1. Variable Clear: %BATTSTART
2. Variable Clear: %TIMESTART
3. Variable Set: %BATTSTART To %BATT
4. Variable Set: %TIMESTART To %TIMES
5. Minimalistic Text: Configuration - %BATTDRAIN = Please
6. Minimalistic Text: Configuration - %BATTLEFT = wait...
7. Minimalistic Text: Configuration - %TIMEBATT = (blank)
Exit Task:
1. Variable Clear: %BATTSTART
2. Variable Clear: %TIMESTART
3. Variable Set: %BATTSTART To %BATT
4. Variable Set: %TIMESTART To %TIMES
5. Minimalistic Text: Configuration - %BATTDRAIN = Please
6. Minimalistic Text: Configuration - %BATTLEFT = wait...
7. Minimalistic Text: Configuration - %TIMEBATT = (blank)
The next two profiles are where all the math is done. One profile is setup for when the phone is plugged in and charging. The other is setup for when the phone is unplugged and discharging. An IF statement was implemented because Tasker seems to track battery changes very frequently even when the actual battery percent hasn't changed. So a variable called %BATTPREV was created to do a quick check... If the battery % hasn't changed then it doesn't do anything until it does change. Also... I personally have the results written to a battlog.txt file because I found it handy to see a log of data.
I used the Variable Section task to drop one of the decimal points... Precision to 3 decimals is not necessary I don't feel, but there is no way to round it to 1 or 2 decimals yet. I think to the 10ths is plenty for this application.
Profile 3: BattCharging:
Context: Event > Power > Battery Changed
Context: State > Power > Power > Source: Any
Task:
1. If - %BATT !~ %BATTPREV
2. Variable Set: %BATTUSED To %BATT - %BATTSTART - Check "Do Maths"
3. Variable Set: %TIMEBATT To (%TIMES - %TIMESTART)/3600 - Check "Do Maths"
4. Variable Section: %TIMEBATT From 1 Length 4
5. Variable Set: %BATTDRAIN To %BATTUSED/%TIMEBATT - Check "Do Maths"
6. Variable Section: %BATTDRAIN From 1 Length 4
7. Variable Set: %BATTLEFT To (100-%BATT)/%BATTDRAIN - Check "Do Maths"
8. Variable Section: %BATTLEFT From 1 to Length 4
9. Minimalistic Text: Configuration - %BATTLEFT = %BATTLEFT hrs
10. Minimalistic Text: Configuration - %BATTDRAIN = +%BATTDRAIN /hr
11. Minimalistic Text: Configuration - %TIMEBATT = +%BATTUSED in %TIMEBATT
12. OPTIONAL - Write File: battlog.txt Append:On - Text:"CHG: %DATE, %TIME, %BATT, +%BATTDRAIN / hr %UPS"
13. End If
14. Variable Set: %BATTPREV To %BATT
Profile 4: BattDraining:
Context: Event > Power > Battery Changed
Context: State > Power > Power > Source: Any INVERT!!
Task:
1. If - %BATT !~ %BATTPREV
2. Variable Set: %BATTUSED To %BATT - %BATTSTART - Check "Do Maths"
3. Variable Set: %TIMEBATT To (%TIMES - %TIMESTART)/3600 - Check "Do Maths"
4. Variable Section: %TIMEBATT From 1 Length 4
5. Variable Set: %BATTDRAIN To (%BATTUSED/%TIMEBATT)*-1 - Check "Do Maths"
6. Variable Section: %BATTDRAIN From 1 Length 4
7. Variable Set: %BATTLEFT To %BATT/%BATTDRAIN - Check "Do Maths"
8. Variable Section: %BATTLEFT From 1 to Length 4
9. Minimalistic Text: Configuration - %BATTLEFT = %BATTLEFT hrs
10. Minimalistic Text: Configuration - %BATTDRAIN = +%BATTDRAIN /hr
11. Minimalistic Text: Configuration - %TIMEBATT = -%BATTUSED in %TIMEBATT
12. OPTIONAL - Write File: battlog.txt Append:On - Text:"CHG: %DATE, %TIME, %BATT, -%BATTDRAIN / hr %UPS"
13. End If
14. Variable Set: %BATTPREV To %BATT
Finally.... Create a Minimalistic Text Widget size of 1x1 to display the data on your homescreen
Setup a Custom Layout with 3 Levels...
Level 1: Add Local Variable from the Misc tab: Variable Name: %BATTDRAIN, Style: Normal Override Size: 15
Level 2: Add Local Variable from the Misc tab: Variable Name: %BATTLEFT, Style: Normal, Override Size: 15
Level 3 (OPTIONAL): Add Local Variable from the Misc tab: Variable Name: %TIMEBATT, Style: Normal, Override Size: 10
Thanks man.
You have no idea how long I was investigating somethig light and easy way to show discharge rate on the home screen.
I test your build and can confrim, that it works as prescribed even after 2 years you wrote first post.
Anyway I hope you did not stop to work on it and you can improve it. After few first days I am planning to study deeper your original work. I am new not new to Tasker but I never work with variables.
I would like to improve and add some stuff:
1. I want to see current discharge rate of last 1%.
2. show time in format "X hours X minutes"
Lol... blast from the past
Actually I still use it... but I've made some modifications and tweaks since.
I've simplified it a bit and changed what it watches for...
When it is draining it keeps track of:
Drain/hr... (ex) -2.5 %/h
Estimated time remaining: (ex) 10h 53m
Screen on time accumulated/total screen time expected: (ex) 0.48 / 4.58
When it's charging it keeps track of the first two things... charge per hour and estimated time till 100% and the bottom figure counts how many % have charged since plugged in and how long it's been.
Works reliably still... I've been meaning to program it in java and make a tiny app independent of these 3rd part apps... but eh.
Glad you like it.
Sent from my SM-N900T using Tapatalk
This is how it looks now while discharging.
Sent from my SM-N900T using Tapatalk
This is on my home screen
Do you mind sharing version with screen on time?
Give me a day or two and I'll write a detailed update for the profiles.
I really should just learn to program this sometime. It would be a lot easier.
Sent from my SM-N900T using Tapatalk
It's too much too type... I exported the profiles. Remember... you need minimalistic text to display the information on your home screen. I'm including the profiles and the minimalistic text profile as well. You can figure out how to import tasker profiles and the minimalistic folder is accessed from within the program... you have to save it to the sdcard/Minimalistic TextPreferences folder on your phone to be accessed.
Good luck!!
There are six profiles.
1. BatteryDraining - Tracks when your phone is unplugged and only performs a % drain / hour calculation when the battery % goes down and displays on the minimalistic text widget.
2. BatteryCharging - Tracks when your phone is plugged in and only performs a %charge / hour calculation when the battery % goes up and displays on the minimalistic text widget.
3. PluggedIn - Resets the variables used by the BatteryCharging profile in order to track charging % / hour statistics. When phone is unplugged variables are again reset for the BatteryDrain profile to track drain % / hour. (You may want to edit this profile because I have it set my screen time out to 15 minutes when it's plugged in and goes back to 30 seconds when unplugged. Also writes the stats to a text file on the phone storage... this is not necessary, but it's interesting for logging purposes to me.)
4. OnBoot - Resets all variables and will automatically calculate and display % drain or % charge wether phone is plugged in or not. (This profile also appends some information to the same battery log on the phone memory.)
5. ScreenOn - simple profile that sets the time that the phone screen is turned on
6. ScreenOff - another simple profile that sets the time that the screen is turned off and appends cumulative screen time and calculates an estimate of maximum screen on time which displays via minimlalistic text widget when phone is unplugged.
Alright... it works really well and I use it constantly. Next to zero battery drain because it only does anything when the battery actually changes. There is no active "monitor" mechanism.. it works entirely on reports of the system of battery changes.
Thanks for profiles, but i have a problem.
PluggedIn profile points to BattFull Profile Status...
I have exclamation mark on that profile, under Profile Status.
I set it to PluggedIn, and I'm testing it right now.
Will report later
It works fine, thanks again
Oh yeah... BattFull is another profile I created. It is very simple... when battery hits 100% it makes a sound and then turns itself off. When you plug in the phone it activates BattFull again. You can just delete that task... or make battful
Sent from my SM-N900T using Tapatalk
I'm not trying to do this exactly but something similar and maybe you can help me.
What I'm trying to do is make tasker alert me if my battery drops more than 2% per hour during my workday.
This is a little long so please bear with me:
I have 2 profiles. The first happens at 8:45 AM. The second happens every hour from 9:30AM to 4:30PM
Profile 1)
Variable Set %BATTLEVEL to %BATT
Profile 2)
Variable Set %CURRENTBATT to %BATT
Variable Set %BATTDIFF to %BATTLEVEL - %CURRENTBATT (do maths checked)
Alert - Notification LED - If %DIFFBATT > 2
This should happen at the 1/2 hour mark in each hour, but it is not performing the Variable Set tasks. The thing is I know these profiles are active and working because I have them doing other things like turing my data off, setting ringer volumes...and all those things are working.
The battery was at 56% at 2:15 PM when i set this up. So at 2:45PM I ran a test task Flash %BATTLEVEL, and Flash %CURRENTBATT, it gave me 56% for both. Then I purposefully drained it to 53% by 3:15PM so that I could test to see if it was working. I was expecting it to start flashing my notification light at 3:30PM. But it did not, so at 3:45 PM I checked the test task and the %BATTLEVEL and %CURRENTBATT are still at 56. So it just never ran the Variable Set commands. I don't understand why it wouldn't run those. Any suggestions?
Is that Calendar widget Tasker-based? If so, do you mind sharing?
Has anyone got a profile for estimating how long until the battery is fully charged?
Is there anyway to display the battery stats in a notification instead of a widget?
Please guide me how to add current mA to this settlement
In looking at C-States (not P-States), that is, simply switching between normal and idle (State 0 and State 1) reported on HTC One X...
I made the following script (WARNING: BACKUP, ETC ETC)
#!/bin/sh
echo "Idle_Analyser_by_sr2012: GPL3 Licensed"
#echo "State 0"
a=$(cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time | sed 's/......$//')
echo "Normal (State0): " $a" sec"
a1=$(cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage )
echo "Normal (State0): " $a1" times entered"
#echo "State 1"
b=$(cat /sys/devices/system/cpu/cpu0/cpuidle/state1/time | sed 's/......$//')
echo "Idle (State1): " $b" sec"
b1=$(cat /sys/devices/system/cpu/cpu0/cpuidle/state1/usage)
echo "Idle (State1): " $b1" times entered"
echo "Difference(0-1): " $(( ($a-$b) ))" sec (to nearest second)"
echo "Difference(0-1): " $(( ($a1-$b1) ))" times entered"
sleep 1
clear
sh Idle_Analyser_by_sr2012.sh
This shows how much time the processor is in normal or idle states. Of course, since the script is recursive, the processor won't idle. It is recursive just to see that the timing was correct in displaying the data.
The question is, and since I haven't yet/can't make an app that graphs this over time without blocking idle states, it is interesting to run this script from time to time to see what the statistics are. Since TricksterMod and Cpuspy don't report these figures, as far as I can tell.
Can TricksterMod or Cpy spy incorporate these somehow?
The other question is, what is the 51mhz state and the idle state? How do these interact?
Also, what is the threshold for C-state Race-To-Idle. That means, let's say I load an app. Then I don't touch the screen for 200ms, 500ms, 1sec, 2sec. At what point does the kernel (not governor, since that relates to P-States only?) switch to Idle? Every 100ms? Every 1sec? More?
Here are some good resources of an overview of C-States, P-States and their governors, etc.
(I can't post links) Pallipadi.pdf and ols2007v2-pages-119-126.pdf (Google it)
Of course Kernel developers also know a lot on these forums so I'm curious about also Ladder vs Menu Governors and how we can have tools to tweak this? In lieu of improving and/or validating the race-to-idle strategy.
EDIT: "RACE-TO-IDLE"
See (I can't post links) White_Paper_7_-_Five_Ways_to_Save_Power.pdf (Google it)
Now, what does someone mean when they say Race-To-Idle. Is it
(a) Race to 5% or below CPU ~load~
(b) Race to clear all tasks to low enough load such that C-State enters C1, C2, etc.
(c) Both the above
Let's consider the case of (a) only, such as in the attached thumbnails, where we ignore C States and look at P States only. I am curious as to whether the P State governor Performance is better than the governor OnDemand.
This is because if you look at the attached image technically because the OnDemand governor ramps up as required it consumes less energy. But Race-To-Idle (case (a) only) would say that for the Performance governor, if you are running at 1ghz you slam through the task and then your load goes from x% at 1ghz to <5% at 1ghz, say. Rather than OnDemand where your load increases accordingly as clock speed is ramped from 200mhz to 1ghz or whatever. However, given the ramp up and down, that means that your idle time (by "idle" I mean <5% cpu load, for exampe) at xghz (say the minimum frequency you set) is ~less~ than idle time (<5% cpu load, for example) of the 1ghz frequency all the time.
How do we analyse and/or verify this?
Consider the 2nd attachment below. If energy consumption per load is linear, and energy consumption per frequency is linear, then does ramping the frequency help save energy? or use more.
Nougat Battery Saving - Amplify (no Greenify or Power Nap) - < 0.5% / hour -Feb 2018
Guide to 200 hours standby / 10 hours SOT:
I'm obsessed with battery life, and assume some others on here are as well. After much experimentation, I have found what works best for me on Nougat - Samsung S7 Edge sd820, and I'm thinking it will likely help any other device get the best battery life possible, at < 0.5% per hour.
SUMMARY: Use XPOSED and AMPLIFY Pro, that is all.
First, I removed any bloatware (and there's much of that on a Samsung device.) I used this to help with my Samsung (I'm on S7 Edge, but this S8+ list works fine for debloating) - thanks @tawh!d : https://forum.xda-developers.com/galaxy-s8+/help/s8-debloat-list-t3703985
Next, install XPOSED now that it's out for Nougat - thanks @rovo89 - and install Amplify, then donate to get PRO : https://play.google.com/store/apps/details?id=com.ryansteckler.nlpunbounce
You will need AMPLIFY DONATION package for full functionality.
I will include pictures attached at the bottom of my limited Wakelocks, Services and Alarms, I basically limited everything I could while still keeping functionality of Maps, Phone, Messages, and System (so you can adjust as you see fit), but basically this is a good start - thanks @v7 :
Limit the following:
Alarms
Alarms(Allow every 600 seconds)
com.android.internal.telephony.data-stall
Alarms(Allow every 1800 seconds)
com.oasisfeng.greenify.CLEAN_NOW
Alarms(Allow every 3600 seconds)
android.appwidget.action.APPWIDGET_UPDATE
Alarms(Allow every 7200 seconds)
android.content.syncmanager.SYNC_ALARM(delays sync)
Alarms(Allow every 10800 seconds)
android.net.ConnectivityService.action.PKT_CNT_SAM PLE_INTERVAL_ELAPSED
com.facebook.common.executors.WakingExecutorServic e.ACTION.ALARM.com.facebook.katana
com.google.android.apps.hangouts.CLEANUP_DB
com.pushbullet.android/.gcm.GcmFixReceiver
com.android.server.action.NETWORK_STATS_POLL
com.diune.pictures.intent.action.MEDIA_CHECK
LocationManagerService
Alarms[LOCATION](Allow every 41400 seconds)
ALARM_WAKEUP_LOCATOR(com.google.android.gms.nlp.AL ARM_WAKEUP_LOCATOR)
ALARM_WAKEUP_CACHE_UPDATER
ALARM_WAKEUP_BURST_COLLECTOR(com.google.android.gm s.nlp.ALARM_WAKEUP_BURST_COLLECTOR)
com.google.android.gms.location.fused.GPS_ALARM_BA LANCED_ACCURACY
ALARM_WAKEUP_ACTIVE_COLLECTOR
ALARM_WAKEUP_PASSIVE_COLLECTOR
ALARM_WAKEUP_BURST_COLLECTION_TRIGGER
com.google.android.intent.action.SEND_IDLE
ALARM_WAKEUP_ACTIVITY_DETECTION
com.google.android.location.reporting.ACTION_UPDAT E_WORLD
Alarms(Allow every 93600 seconds)
android.app.backup.intent.RUN
com.google.android.gms/.checkin.EventLogService$Receiver
com.google.android.gms/.checkinCheckinService%Receiver
Wakelocks
Wakelocks(Allow every 800 seconds)
WakefulIntentService[GCoreUlr-LocationReportingService]
RILJ
NetworkStats
Wakelocks(Allow every 3600 seconds)
WeatherUpdateService
Wakelocks(Allow every 10800 seconds)
SyncLoopWakeLock(delays sync)
*net_scheduler*
GCoreFlp
Icing
Wakeful StateMachine: GeofencerStateMachine
NfcService:mRoutingWakeLock
wake:com.pushbullet.android/.gcm.GcmService
SyncService(Package: Push Bullet)
ai(Package: Push Bullet)
ae(Package: Push Bullet)
AsyncService
Wakelocks(Allow every 41400 seconds)
NlpWakeLock
NlpCollectorWakeLock
LocationManagerService
Config Service Fetch
Wakelocks(Allow every 9999999 seconds)
*job*/com.facebook.katana/com.facebook.analytics2.logger.LollipopUploadServi ce
JobSchedulerHack-com.facebook.analytics2.logger.LollipopUploadServi ce
UploadServiceLogic-com.facebook.analytics2.logger.LollipopUploadServi ce
*job*/com.facebook.orca/com.facebook.bugreporter.scheduler.LollipopService (com.facebook.orca.Messenger)
*job*/com.facebook.katana/com.facebook.bugreporter.scheduler.LollipopService (com.facebook.katana.Facebook)
Services
Services(Block/Deny)
com.google.android.gms.analytics.AnalyticsService
com.google.android.gms/com.google.android.location.internal.GoogleLocatio nManagerService(Location Service)
com.android.gms.Feedback.FeedbackService(Breaks Play Games)
com.android.gms.ads.AdRequestBrokerService
com.google.android.gms/com.google.android.location.network.NetworkLocatio nService(Location Service)
com.google.android.location.geofencer.service.Geof encerProviderService(GPS Service)
com.google.android.gms/com.google.android.location.copresence.service.Pro ximitySettingInjectorService
com.facebook.katana/com.facebook.analytics.service.AnalyticsService
com.facebook.orca/com.facebook.analytics.service.AnalyticsService
com.android.cellbroadcastreceiver/.CellBroadcastAlertService
com.android.cellbroadcastreceiver/.CellBroadcastConfigService
NB:I don't use Location Service.That's why I've disabled the location Services.If your'e using Location service,do not disable the services with location and GPS tag)
Alarms(REGEX Blocking)
ALARM_WAKEUPxxxxx
CONTEXT_MANAGER_ALARM_WAKEUP_xxxxx
Procedure:
Open Amplify.
Select Alarms from the menu.
Tap the list icon on the top right corner
Tap + button on top.
Add the following code to 'Enter Regex to match'
Code:
ALARM_WAKEUP[0-9]+
and
Code:
CONTEXT_MANAGER_ALARM_WAKEUP_[0-9]{3,}
Set the interval to 9999999 seconds.
SOURCE: https://forum.xda-developers.com/android/general/guide-extreme-battery-life-t3095884
So that's it, I have tried Greenify and it USED more battery than it saved. I have tried Power Nap, and it USED more battery than it saved. I used the scripts to limit Google Services and it USED more battery than it saved (based on this script: https://forum.xda-developers.com/lg-g2/general/guide-reducing-google-play-services-t3139032 .) I assume that Greenify, Power Nap, the Fix Google Services script, don't work with Nougat as they cause some apps to thrash about, reawakening and being shutdown continuously etc..
Enjoy this guide and comments (improvements) are VERY welcome!
D.
hey nice work there ,im gonna try it out and let u know
Can I ask for how long you've been operational and fully functional with these settings? Other than that: thanks for sharing!
Classmate search: Frank Hodge Cartersville, GA
Classmate search: Frank Hodge Cartersville, GA
How did you make Amplify work properly please?
Good work
Still many off my wakelocks,alarms and services in not in ur list. I have many unknown but few safe to limit. How to decide which unknown i can limit to what second??
For more tips to save battery go to
Reply to save
Can You update with new alarms, wakelocks and something else.
Hi @davecotefilm
Thank you for your great work.
I have a question about alarms :
(REGEX Blocking)
ALARM_WAKEUPxxxxx
CONTEXT_MANAGER_ALARM_WAKEUP_xxxxx
What these codes do?
thanks.
alispeedsport said:
Hi @davecotefilm
Thank you for your great work.
I have a question about alarms :
(REGEX Blocking)
ALARM_WAKEUPxxxxx
CONTEXT_MANAGER_ALARM_WAKEUP_xxxxx
What these codes do?
thanks.
Click to expand...
Click to collapse
Yes I block those in amplify
Hi @davecotefilm
What do you think about limit *vibrator* to 800 and Connectivity Service to 7200 on Wakelocks?
alispeedsport said:
Hi @davecotefilm
What do you think about limit *vibrator* to 800 and Connectivity Service to 7200 on Wakelocks?
Click to expand...
Click to collapse
Vibration yes, connectivity no. The new kernel in op (toxic oc) gives best battery though (efficiency mode)
@davecotefilm
alarms:
com.android.server.NetworkTimeUpdateService.action.Poll to 1200
greenify REVIVE service to 5600
ScheduleConditionProvider.EVALUATE to 240
wakelocks:
WifiSuspend to 800
StartingAlertService & MMS_RESEIVER to 600
Services:
greenify notification service to deny
alispeedsport said:
@davecotefilm
alarms:
com.android.server.NetworkTimeUpdateService.action.Poll to 1200
greenify REVIVE service to 5600
ScheduleConditionProvider.EVALUATE to 240
wakelocks:
WifiSuspend to 800
StartingAlertService & MMS_RESEIVER to 600
Services:
greenify notification service to deny
Click to expand...
Click to collapse
Greenify uses more battery than it saves, not needed for nougat
Configuration XML file for download
Could you make the configuration XML file available for download?
The file name is com.ryansteckler.nlpunbounce_preferences.xml
Path: /data/data/com.ryansteckler.nlpunbounce/shared_prefs
Thanks!
oFonsecaSioux said:
Could you make the configuration XML file available for download?
The file name is com.ryansteckler.nlpunbounce_preferences.xml
Path: /data/data/com.ryansteckler.nlpunbounce/shared_prefs
Thanks!
Click to expand...
Click to collapse
Here ya go!
Sent from my klte using XDA Labs
Nice articale thanks.But Don't give your wroung thinking to people.Greenify and amplify is most advanced battery saver.Greenify nearly uses 0 cpu if you check your battery details in 24 hour after finishing setup it will not consume more than 1 to 2% of your bettery.And yuo just say It's drain more battery than It's saves.grenify work with the force agrasive does mode while screen goes off.in that time all wakelock will be stoped which is amplify does and It's more powerfull than amplify as It's blocks all wakelock.But It's not as effective as Amplify does.Because After screen goes on all wakelock work again that's the problem.In order to maximise the battery life and speedup the device greenify background free app close and system app with wake up cut off feature is no deny it’s the best smart battery saver out there.Amplify Helps furthere that dose mode lacks in and greenify too because when we are use phone we are not gone hibarenet all apps while using.Like i am using Facebook now and just for saving battery i wont go to greenify to close other all system and used apps.And that’s the most beautiful part of amplify because it does automatically by limiting wakelock.So for best bettery life and speed one should use both battery saver combined.As bouth are extremely light on size as well ram and battery consumption.
Safiqul said:
Nice articale thanks.
Click to expand...
Click to collapse
Um, this is a bit outdated now with safety net. Can't even use amplify. Appops can control a lot of bad app behavior, as can MyAndroidTools. Other than that I use naptime now for deep sleep..
Hi,
Here you can test my new app Android:
Title : Battery Info
Battery Info is an application that displays the details of your battery
This can be very useful in order to know the state of health of your battery, to see if it does not heat too much or to check if the charging is done well.
Here are the details that will be displayed Battery Info:
- state of health
- being loaded or not
- remaining autonomy
- temperature - (celcius)
- voltage - mV
Here is the info that can be displayed for your battery:
- Health:
cold, dead, good, overheat, over voltage, unknown, unspecified failure
- Level:
between 0% and 100%
- Plugged:
usb, ac, wireless or unknown
- Status:
charging, full, discharging, charging
- Temperature in celcius
- Voltage in millivolts
Google Play : https://play.google.com/store/apps/details?id=com.sospc95.Battery_Info
Install it and test it
Thanks