Related
I have perpetually experienced overheating issues while using 4.4-based ROMs; typically while using Navigation as part of Google Maps and while docked in the Galaxy Nexus Car Dock.
My frustration lead to inquiring with some skilled members of the Galaxy Nexus community, including @Ziyan, @freshgiammi, and @aosp. They have indicated that 4.4-based ROMs seem to be afflicted with this problem, but that it might also be tied to the kernel being used.
I have two phones; one running stock 4.3 (Sprint) and another running CM11 M8 (also Sprint).
Testing Setup:
I have Google Maps (and all other software, including Google Play and Play Services) completely updated. The screen brightness is set to auto. I've tested using Navigation initiated by WiFi, and then disabling the cellular radio (to ensure that the overheating is not being caused by radio activity.) I checked OS Monitor by switching through recent apps mid-testing; this gave me a snapshot of system temperatures and a glimpse of CPU usage.
Stock - Worked perfectly. Navigation, at any time of day, seems to work wonderfully. I do notice that the phone does get warm, and using OS Monitor, can confirm that it reaches 47 degrees C (and holds), never exceeding it. The phone continues to charge without issue. OS Monitor cited CPU usage of 29% at the highest (note that this does not indicate that Maps never used more than 29%, just that 29% was the most I witnessed while checking 15-20 times over the course of 10 miles.)
CM11 - Phone overheats within minutes of starting Navigation, reaching temperatures of 53 degrees C--and as high as 58 degrees C. The phone stops charging as soon as the system registers an "overheated" state. OS Monitor's highest CPU usage was 52%, which is almost double as high as I saw under the stock firmware.
IMGUR link of screenshots while Navigating, idle temperature, overheating, etc.
So far, it appears when my phone has been asleep or idle, it's operating at 29-35 degrees C; so it's nearly doubling it's temperature when Navigating. Additionally, this behavior occurs at night, when the sun (and warmer temperatures) are no longer a factor, which seems to rule out the idea that the environment is a major contributor.
I have a good friend who also as a Sprint Galaxy Nexus running CM11; he is a Waze user, and is experiencing the same issue.
Is this a known issue/problem with 4.4-based ROMs? This has been speculated in other threads, but perhaps a more definite answer/explanation is warranted?
Might this be related to the kernel in use, and the thermal throttling limits? What would be the best method of testing such?
What tests or other steps should I take to gather more information or test more factors?
EDIT 1: At @aosp 's recommendation, I'm looking for thermal throttling capabilities via the Kernel Tuner (2014 beta) application. The "Thermal" button is available, but grayed out. Is it safe to assume that means the kernel I'm using has no thermal throttling capabilities, which would (probably) explain how the Galaxy Nexus seems to be able to work itself into an overheated state?
Shidell said:
I have perpetually experienced overheating issues while using 4.4-based ROMs; typically while using Navigation as part of Google Maps and while docked in the Galaxy Nexus Car Dock.
My frustration lead to inquiring with some skilled members of the Galaxy Nexus community, including @Ziyan, @freshgiammi, and @aosp. They have indicated that 4.4-based ROMs seem to be afflicted with this problem, but that it might also be tied to the kernel being used.
I have two phones; one running stock 4.3 (Sprint) and another running CM11 M9 (also Sprint).
Testing Setup:
I have Google Maps (and all other software, including Google Play and Play Services) completely updated. The screen brightness is set to auto. I've tested using Navigation initiated by WiFi, and then disabling the cellular radio (to ensure that the overheating is not being caused by radio activity.) I checked OS Monitor by switching through recent apps mid-testing; this gave me a snapshot of system temperatures and a glimpse of CPU usage.
Stock - Worked perfectly. Navigation, at any time of day, seems to work wonderfully. I do notice that the phone does get warm, and using OS Monitor, can confirm that it reaches 47 degrees C (and holds), never exceeding it. The phone continues to charge without issue. OS Monitor cited CPU usage of 29% at the highest (note that this does not indicate that Maps never used more than 29%, just that 29% was the most I witnessed while checking 15-20 times over the course of 10 miles.)
CM11 - Phone overheats within minutes of starting Navigation, reaching temperatures of 53 degrees C--and as high as 58 degrees C. The phone stops charging as soon as the system registers an "overheated" state. OS Monitor's highest CPU usage was 52%, which is almost double as high as I saw under the stock firmware.
IMGUR link of screenshots while Navigating, idle temperature, overheating, etc.
So far, it appears when my phone has been asleep or idle, it's operating at 29-35 degrees C; so it's nearly doubling it's temperature when Navigating. Additionally, this behavior occurs at night, when the sun (and warmer temperatures) are no longer a factor, which seems to rule out the idea that the environment is a major contributor.
I have a good friend who also as a Sprint Galaxy Nexus running CM11; he is a Waze user, and is experiencing the same issue.
Is this a known issue/problem with 4.4-based ROMs? This has been speculated in other threads, but perhaps a more definite answer/explanation is warranted?
Might this be related to the kernel in use, and the thermal throttling limits? What would be the best method of testing such?
What tests or other steps should I take to gather more information or test more factors?
EDIT 1: At @aosp 's recommendation, I'm looking for thermal throttling capabilities via the Kernel Tuner (2014 beta) application. The "Thermal" button is available, but grayed out. Is it safe to assume that means the kernel I'm using has no thermal throttling capabilities, which would (probably) explain how the Galaxy Nexus seems to be able to work itself into an overheated state?
Click to expand...
Click to collapse
IMHO, handling of thermal throttling in 4.4 should be secondary thing to investigate about.
Shouldn't we first think of why for the same application, CPU is hogging this much?
Is it that CPU is not offloading its tasks to GPU which is supposed to happen, and happening with 4.3?
Good thing is that you have two tuna phones available to test out various scenarios.
If you use a ROM's stock kernel, thermal throttling is enabled correctly.
Give Omni and Trickster Mod a try. Omni is more stable & bug-free than CM, and Trickster will show you your CPU temps, as you only posted your battery temps - which are way too high! How the hell did you reach it? Even if I do some antutu, mine never reaches more than 40 °C. 58 °C is either a sensor misbehaving, or you put your phone in a jacket, lol, as it's far enough from the CPU to not heat up.
Post some Omni & Trickster temps with it's stock kernel something must be wrong, as I didn't notice anything like this on my maguro.
Ziyan said:
If you use a ROM's stock kernel, thermal throttling is enabled correctly.
Give Omni and Trickster Mod a try. Omni is more stable & bug-free than CM, and Trickster will show you your CPU temps, as you only posted your battery temps - which are way too high! How the hell did you reach it? Even if I do some antutu, mine never reaches more than 40 °C. 58 °C is either a sensor misbehaving, or you put your phone in a jacket, lol, as it's far enough from the CPU to not heat up.
Post some Omni & Trickster temps with it's stock kernel something must be wrong, as I didn't notice anything like this on my maguro.
Click to expand...
Click to collapse
My battery goes to about 44 degrees C when watching Netflix and charging and about the same during navigation and charging. Only time it's gotten hotter than that is due to environmental issues (such as very hot car interior before ac cools down). I run cm11 and faux123 kernel. Looks like OP is having some kind of hardware issues.
Shidell said:
I have Google Maps (and all other software, including Google Play and Play Services) completely updated. The screen brightness is set to auto. I've tested using Navigation initiated by WiFi, and then disabling the cellular radio (to ensure that the overheating is not being caused by radio activity.) I checked OS Monitor by switching through recent apps mid-testing; this gave me a snapshot of system temperatures and a glimpse of CPU usage.
Stock - Worked perfectly. Navigation, at any time of day, seems to work wonderfully. I do notice that the phone does get warm, and using OS Monitor, can confirm that it reaches 47 degrees C (and holds), never exceeding it. The phone continues to charge without issue. OS Monitor cited CPU usage of 29% at the highest (note that this does not indicate that Maps never used more than 29%, just that 29% was the most I witnessed while checking 15-20 times over the course of 10 miles.)
CM11 - Phone overheats within minutes of starting Navigation, reaching temperatures of 53 degrees C--and as high as 58 degrees C. The phone stops charging as soon as the system registers an "overheated" state. OS Monitor's highest CPU usage was 52%, which is almost double as high as I saw under the stock firmware.
Click to expand...
Click to collapse
I think it would be helpful to try to narrow down where the heat is coming from. Some possibilities:
1. Mobile data or LTE - a likely suspect, but you've already eliminated this one.
2. GPS - set Google Maps aside for a bit, get an app like GPS Status and Toolbox, set it to keep the screen on, and see if this still causes the heating issues.
3. GPU (or lack of proper use of GPU) - If Google Maps overheats the phone but GPS Status does not, it could be how CM is handling the display for Google Maps.
I got a chance to do some testing yesterday afternoon while driving. Toroplus on Page Plus, OmniROM 8-31 nightly, NukedTrinity kernel (was running it to test something else, will test stock kernel today but I fully expect results to be the same). Mobile data off as always. Started GPS right after a 15 minute phone call, battery was at 40 C. Hooked up the charger and ran GPS Status for 5 minutes, battery temp went up to 44 C. Ran Google Maps for 15 minutes (had previously downloaded offline maps for the area), still charging. Battery temp had gone back down to 40 C.
Sdobron said:
My battery goes to about 44 degrees C when watching Netflix and charging and about the same during navigation and charging. Only time it's gotten hotter than that is due to environmental issues (such as very hot car interior before ac cools down). I run cm11 and faux123 kernel. Looks like OP is having some kind of hardware issues.
Click to expand...
Click to collapse
Can you provide me with a link to the exact kernel you're using? I'd like to test it as well. Thanks!
Shidell said:
Can you provide me with a link to the exact kernel you're using? I'd like to test it as well. Thanks!
Click to expand...
Click to collapse
http://faux.romhost.me/tuna/kk44/tuna-kk-kernel-039m-sr.zip
Thank you. I'll test with this shortly as well.
@Ziyan
I agree that these temperatures are way too high; as you'll see below, though, my phone is reaching 46 degrees C simply by using GPS Status! I don't know what to make of that.
@musical_chairs
Thank you for testing as well. I agree that your hypothesis about separate testing is sound, and so I've been testing using GPS Status. I've tried @bsmitty83 's kernel, FancyKernel v56, and Laux123's kernels--all provide slightly different results, but to varying degrees of bizarre behavior using GPS Status.
Stock 4.3 works very well; it determines a bearing indoors without GPS fix and maintains it, with almost no change over a 10 minute period of time. Also, 4.3 warms up, but it never exceeded 44 degrees C.
CM11 w/ Laux123, Fancy Kernel and bsmitty83's all exhibit strange heading behavior. If you'll watch this youtube clip I uploaded (2:45), you'll notice that the phone is laying flat on a wooden table, and yet the Heading will change by 15 or more degrees on it's own. Later in the clip, I move the phone manually to force it to readjust, and you'll see that finds a new bearing from the beginning.
Laying both phones down next to one-another, stock 4.3 indicated the bearing was approximately 219 degrees. In this video clip (FancyKernel r56), my phone believes the bearing is 285 degrees (to begin with) and 260 degrees at the end.
Might GPS be the problem? I suppose I should flash Stock 4.3 to my phone, to make sure it does not continue to behave this way and rule out hardware problems/failure, right?
This just seems really bizarre. Especially that using a GPS fix application can ramp up the temperature so quickly, and so dramatically. Perhaps is the driver/kernel making too many callbacks, causing an escalation in CPU use and heat?
Finally, where can one find the CM11 M8 kernel (indivdually)? I'd like to re-flash it and compare it as well.
Thanks for the continued help in troubleshooting what's happening, everyone.
YouTube CM11 FancyKernel r56
@Shidell just download cm11 m8 and pull out the boot.img so you can fastboot flash it
I managed to gain -5°C on my maguro.
Basically just lowered the thermal throttle to stock values, and now it feels cooler. However still hotter than 4.3 so we're now sure that's not the culprit. Just FYI.
freshgiammi said:
I managed to gain -5°C on my maguro.
Basically just lowered the thermal throttle to stock values, and now it feels cooler. However still hotter than 4.3 so we're now sure that's not the culprit. Just FYI.
Click to expand...
Click to collapse
That's really interesting--5 degrees makes a pretty big difference.
I think I'm going to put stock back on my phone soon, in order to make sure it isn't some sort of hardware failure (maybe the chips in the GNex start to fail if they overheat too high/much? I've heard of that type of failure causing strange issues.)
I'm not sure what to chalk up as the culprit yet, but something is amiss.
If anyone else is reading this thread with a Galaxy Nexus and can comment on their experiences, that information would be useful.
@Ziyan A stock 4.2 or 4.3 kernel should work with any ROM, such as CM10.2 or CM11, is that correct?
I've tried pushing boot.img via fastboot, against both, but neither wants to boot. Am I doing something incorrectly?
Shidell said:
@Ziyan A stock 4.2 or 4.3 kernel should work with any ROM, such as CM10.2 or CM11, is that correct?
I've tried pushing boot.img via fastboot, against both, but neither wants to boot. Am I doing something incorrectly?
Click to expand...
Click to collapse
Yep, but you should only flash the zImage, as flashing the full boot.img flashes the 4.2/3 ramdisk too, which won't work.
BTW, it would be much easier to just flash the latest Omni to your phone. It uses a kernel close to stock, and it's close to AOSP... unlike CM
Ziyan said:
Yep, but you should only flash the zImage, as flashing the full boot.img flashes the 4.2/3 ramdisk too, which won't work.
BTW, it would be much easier to just flash the latest Omni to your phone. It uses a kernel close to stock, and it's close to AOSP... unlike CM
Click to expand...
Click to collapse
I plan on testing Omni today. The reason I ask about the kernel is because I'd also like to test various other ROMs using one of the stock 4.2 or 4.3 kernels.
Can I extract the zImage from the boot.img to ensure I'm only flashing the kernel?
Shidell said:
I plan on testing Omni today. The reason I ask about the kernel is because I'd also like to test various other ROMs using one of the stock 4.2 or 4.3 kernels.
Can I extract the zImage from the boot.img to ensure I'm only flashing the kernel?
Click to expand...
Click to collapse
Yes Connect the gnex via usb and "fastboot flash zimage zImage"
Thanks @freshgiammi I've done some extensive testing, so I hope that this helps us determine where the problem is. @Ziyan, @aosp, @musical_chairs, @poo706, @rkpeterson, @MWisBest, @BigBrother1984, @something15525 I'm hoping you might be able to lend a hand as well.
I created this thread based on the Galaxy Nexus tending to overheat when Navigating. However, I've found another discrepancy--live wallpaper performance with the Google Now Launcher. When using the GNL with the Phase Beam wallpaper, sometimes the GNex can draw it just fine; it's smooth, no (or few) dropped frames--it looks and works great. However, with other ROMs, it's very janky, stuttering and performing poorly.
(Note that GNL with a static picture works fine.)
I suspect that there might be a GPU driver issue, or perhaps a configuration issue, in some ROMs that's causing this behavior. Perhaps a certain GPU driver is used in some ROMs, and not others, causing the problem? Perhaps there is a config file with GPU settings where one has specific features enabled, others do not, and it results in poor performance in certain rendering cases?
I wonder if it might be related to overheating on the Galaxy Nexus when Navigating, watching video, playing games--items that tax the GPU. If it is such an issue, though, it might also mean extra work is being performed to compensate, and that would mean extra heat and battery use.
Here are two YouTube links displaying the behavior in question. First is Factory Stock 4.3--I wasn't able to directly record the screen (as that feature wasn't introduced with ADB until 4.4), but hopefully it's clear enough to see that it's smooth. (There is one hiccup when the cards are loading, but that's it.) The second video shows the same test, but running on CM11 M8--it's very choppy and lags behind input, and it's extremely noticeable in person.
I tried to capture video from OmniROM, but received this error while using ADB:
Code:
D:\Android\sdk\platform-tools>adb shell screenrecord /sdcard/omni44.mp4
WARN: Unable to set device connection state for audio submix IN
WARN: Unable to set device connection state for audio submix OUT
Unable to instantiate audio source (error -1)!
Factory 4.3
CM11 M8
I've conducted some tests on a spare Galaxy Nexus, and wiped my own personal model, to be sure that the behavior is the same on both devices--to ensure I don't have a damaged GPU or some other weird hardware issue that might be responsible.
Results:
Factory 4.2.1 - OK
Factory 4.3 - OK
LiquidSmooth LS-KK-v3.2-2014-09-03 - OK
Paranoid Android 4.6 Beta 1 - OK
OmniROM 4.4.4 - 20140905 Nightly - FAIL
CM10.2 RC 1 - FAIL
CM11 M8 - FAIL
Further, I extracted the kernel zImage from Factory 4.2.1 and 4.3, and flashed it into CM11 M8 just to see if the kernel alone made any difference. The 4.2.1 kernel wouldn't boot; 4.3 booted up properly, but the lag/choppiness persisted, which seems to indicate that the problem is not kernel related.
What should I investigate next? Clearly LiquidSmooth and ParanoidAndroid are getting smooth GPU performance, which I expect is also what's causing Navigation to cause my phone to overheat (but I can't prove that, unless we can solve this issue and then I can test with a fix and determine if it's the cause or not.)
Could a config file be at fault? A difference in drivers being used?
I'm having a huge lag with the latest version of Chrome which updated with material design. I'm afraid will we be having these gpu related bugs with Android L as well.
Will these gpu drivers issues be fixed with 3.4 kernel?
sagara.sandaru said:
I'm having a huge lag with the latest version of Chrome which updated with material design. I'm afraid will we be having these gpu related bugs with Android L as well.
Will these gpu drivers issues be fixed with 3.4 kernel?
Click to expand...
Click to collapse
Hm, I'm not sure I can answer that without more information.
What ROM and Kernel are you using? What type Galaxy Nexus? If you are using 4.4, can you do a screencap of what you're experiencing and upload it to YouTube as I have?
Shidell said:
Thanks @freshgiammi I've done some extensive testing, so I hope that this helps us determine where the problem is. @Ziyan, @aosp, @musical_chairs, @poo706, @rkpeterson, @MWisBest, @BigBrother1984, @something15525 I'm hoping you might be able to lend a hand as well.
I created this thread based on the Galaxy Nexus tending to overheat when Navigating. However, I've found another discrepancy--live wallpaper performance with the Google Now Launcher. When using the GNL with the Phase Beam wallpaper, sometimes the GNex can draw it just fine; it's smooth, no (or few) dropped frames--it looks and works great. However, with other ROMs, it's very janky, stuttering and performing poorly.
(Note that GNL with a static picture works fine.)
I suspect that there might be a GPU driver issue, or perhaps a configuration issue, in some ROMs that's causing this behavior. Perhaps a certain GPU driver is used in some ROMs, and not others, causing the problem? Perhaps there is a config file with GPU settings where one has specific features enabled, others do not, and it results in poor performance in certain rendering cases?
I wonder if it might be related to overheating on the Galaxy Nexus when Navigating, watching video, playing games--items that tax the GPU. If it is such an issue, though, it might also mean extra work is being performed to compensate, and that would mean extra heat and battery use.
Here are two YouTube links displaying the behavior in question. First is Factory Stock 4.3--I wasn't able to directly record the screen (as that feature wasn't introduced with ADB until 4.4), but hopefully it's clear enough to see that it's smooth. (There is one hiccup when the cards are loading, but that's it.) The second video shows the same test, but running on CM11 M8--it's very choppy and lags behind input, and it's extremely noticeable in person.
I tried to capture video from OmniROM, but received this error while using ADB:
Code:
D:\Android\sdk\platform-tools>adb shell screenrecord /sdcard/omni44.mp4
WARN: Unable to set device connection state for audio submix IN
WARN: Unable to set device connection state for audio submix OUT
Unable to instantiate audio source (error -1)!
Factory 4.3
CM11 M8
I've conducted some tests on a spare Galaxy Nexus, and wiped my own personal model, to be sure that the behavior is the same on both devices--to ensure I don't have a damaged GPU or some other weird hardware issue that might be responsible.
Results:
Factory 4.2.1 - OK
Factory 4.3 - OK
LiquidSmooth LS-KK-v3.2-2014-09-03 - OK
Paranoid Android 4.6 Beta 1 - OK
OmniROM 4.4.4 - 20140905 Nightly - FAIL
CM10.2 RC 1 - FAIL
CM11 M8 - FAIL
Further, I extracted the kernel zImage from Factory 4.2.1 and 4.3, and flashed it into CM11 M8 just to see if the kernel alone made any difference. The 4.2.1 kernel wouldn't boot; 4.3 booted up properly, but the lag/choppiness persisted, which seems to indicate that the problem is not kernel related.
What should I investigate next? Clearly LiquidSmooth and ParanoidAndroid are getting smooth GPU performance, which I expect is also what's causing Navigation to cause my phone to overheat (but I can't prove that, unless we can solve this issue and then I can test with a fix and determine if it's the cause or not.)
Could a config file be at fault? A difference in drivers being used?
Click to expand...
Click to collapse
Could you give FML a try? In particular the latest beta build...
not sure if you're on a maguro or a toro, so I'll link them both:
omni-4.4.4-20140825-maguro-FML.zip (159.56 MB)
omni-4.4.4-20140824-toro-FML.zip (159.41 MB)
With FML being based on OmniROM, if there's an issue with OmniROM but not FML or vice-versa it can help narrow down what might be the difference that causes the issue.
I'm also interested if screen record via adb works with that build for ya as well, so if you could test that it'd be much appreciated.
sagara.sandaru said:
I'm having a huge lag with the latest version of Chrome which updated with material design. I'm afraid will we be having these gpu related bugs with Android L as well.
Will these gpu drivers issues be fixed with 3.4 kernel?
Click to expand...
Click to collapse
The 3.4 kernel isn't looking to be the smoking gun we were hoping for, however if we can get Ducati (hardware video encode/decode and camera stuff) working with the updated GPU drivers in the 3.0 kernel that would definitely be helpful. The newer GPU drivers have better power management by a landslide.
I'm on the US NG1 firmware on the Tab Pro 8.4 (all stock) and I seem to have this situation where CPU Cores #2 and #3 are always on, and always running at least 1.5GHz. In fact they seem locked at 1.5GHz (they don't seem to go faster or slower) which is very strange. Both CPU-Z and the "device info" screen of AnTuTu show evidence of this.
Any ideas?
I've already tried killing all programs/tasks/recent apps ... no change.
( A few days ago I had the issue where even when the tablet was idle (screen turned off) for several hours it was basically almost fully awake, and the main culprit was "Google Play Services" which used way more battery than even the SCREEN. Very weird. But after 2 days of this weird behaviour, it stopped and the tablet was able to stay in deep sleep most of the time in Idle )
Strange behaviour indeed...I have troubles with deep sleep to, but not related to the cores locked to max freq.
Try hard reset, and if it doesn't work, go for replacement. ..
I cleared Cache from Settings->Storage and did a cold boot (turn off, wait, then turn on)
The issue seems to be gone. I quickly opened each of my most-freq-used apps at least once ... then checked CPU-Z again, and it's still fine (CPU cores are sleeping).
So it's not one of my frequently used apps.
I'll probably check my Battery specs on a daily basis for the next little while to ensure it doesn't come back.
BTW are there any apps for unrooted phones which can detect wakelocks? All the ones I saw on the Play Store require Root to detect wakelocks
Dears,
I bought a G3 phone just a month ago and, apparently, the battery was lasting almost a whole day in the first two weeks, but, after that, the battery became to last less than half day. Of course I've installed some applications since then, but it's very strange because the Android doesn't report any abnormal processing load of any application, so I'm presuming the OS is causing the high battery consumption. After I bought the phone, I upgraded the OS to Lollipop almost forthwith. I'd like to know if it's a known issue of G3 with L version and there is something I can do to increase the battery life.
I've installed some applications that utilize the location services, but Android doesn't claim those applications are draining the battery. According to what Android reports, the screen and the OS are main things that are consuming more battery ( 24% for screen and 16% for OS )
Thanks in advance
nasordev said:
Dears,
I bought a G3 phone just a month ago and, apparently, the battery was lasting almost a whole day in the first two weeks, but, after that, the battery became to last less than half day. Of course I've installed some applications since then, but it's very strange because the Android doesn't report any abnormal processing load of any application, so I'm presuming the OS is causing the high battery consumption. After I bought the phone, I upgraded the OS to Lollipop almost forthwith. I'd like to know if it's a known issue of G3 with L version and there is something I can do to increase the battery life.
I've installed some applications that utilize the location services, but Android doesn't claim those applications are draining the battery. According to what Android reports, the screen and the OS are main things that are consuming more battery ( 24% for screen and 16% for OS )
Thanks in advance
Click to expand...
Click to collapse
You should root your LG G3, then install xposed, greenify amplify and powernap. Those apps will control your wakelocks and alarms. This will also improve your battery life.
May I also suggest to reduce screen DPI. Reduced mine from 640 to 534, added about 45-60 mins of SOT
Are you talking screen on time? Or idle battery drain. Because these are two very different things. Quite often it is the way you are using your phone and the applications installed that will cause your battery life to become worse.
Of course you have the obvious things such as disabling data when you aren't using it and wifi and so on. Through my experience I have found amplify to be of little use if you are generally cautious about the apps you install. Facebooks apps are terrible. Any instant messager will be causing some sort of drain. The problem definitely arrises from these things and while you can install many other apps to limit these things. I often find it is best to address the problem at the source. Perform a factory reset. Then begin installing your apps one by one and seeing when the hit comes. Thats my advice. Then find an alternative to the problematic app. That or BBS to find what is causing wakelocks. Remember, if you are gaming the processor is going to eat battery.
To follow up on orcam he is in the perfect rite direction as for reducing the dpi its a placebo effect you can read up on it on many threads and sot is in most case 7 to 12 min longer reduce britghness get rid of carrier iq is a big battery hog debloat the system apps like facebook and all the other bloat that lg uses is bad on battery life
The best way to get better battery:
1. Root
2. Debloat - delete useless app's and files from root directory!
3. 3845*#855# (855 its international model, put your model: 851, 852, etc) and search for Thermal Daemon Mitigation OFF, then click and enable it, and search Fast Dormancy and turn off, and in High Temperature Property OFF enable it too and turn off your phone for atleast 40 seconds, turn on and wait 1 minute with screen on to update those things.
4. Xposed with Greenify
5. TricksterMOD and set the CPU freq. to min. 300Mhz and max to 1.540MHz (if you use the phone normally, and dont play games).
6. in TricksterMOD set the GPU to 330Mhz for powersave.
7. Developer Options active the "Force GPU to 2D graphics"
8. Use brightness according with your needs, not only keep it in 100% (i know in 100% looks beautyful but screen is a battery beast).
This is what i have in mine and i can guarantee if you use moderate it can go up to 3 day's, mine got 5 hours and 20 minuts in On Screen Time so...
Background:
5X 16GB
Chroma 12/10/2015 release
ElementalX 1.04 (DT2W disabled. Sweep2Wake enabled)
Open Gapps Mini ARM64: Google Now Launcher installed but disabled. Ok Google disabled, GPS disabled. 2G (Data off)
Interactive governor tweaks applied as explained in this widely famous thread by soniCron
I am witnessing 1.3-1.5% drop per hour when the phone is in deep sleep (!). Have a look at the screenshots attached, especially the one with graph. That screen off time is 1.5 hours when I was asleep.
Phone configs: WiFi on throughout. Maps + Google Now Launcer force stopped. Chrome, AdAway, Telegram, ES Explorer added in Greenify. Whatsapp was the only app running in background. No Hangouts, Facebook, Kik, Pushbullet or other memory intensive apps.
After tweaking the governor as per thread above, my CPU clock speeds are working awesome, mostly 384Mhz. Touchboost disabled via /sys/mns_performance/modules/parameters/touchboost. It's only the wakelocks which needs to be fixed now otherwise everything is near perfection.
My questions:
In the 3rd image, you'll notice the screen was off for a long time and then turned on once in between. However, I didn't do it because I was asleep. I have Ambient display and wake on notifications disabled, there was no missed call so why did it turn on the screen? I have noticed this other times happening in front of me. The phone will suddenly wake up and sleep immediately within half a second ever since I came to ElementalX.
In the same image you see so many wakelocks while the screen is off. Have a look at the other images to see what's causing this. I believe it's mostly point number 3 (below)
PowerManagerService.Wakelock taking up 51%! while qpnp-smbcharger and qpnp_memaccess take around 30%.
I read PMS.Wakelock is cumulative of Partial wakelocks, I have attached it's screen shot as well but the graphs there are 0%. Am I reading something wrong?
I am not particularly familiar with BetterBatteryStats and dealing with wakelocks in general so looking for some pointers here. Thanks for your help!
You have sweep2wake enabled. It drains 1.3 to 1.5% per hour on idle. The screen flashing on and off is a timeout to disable sweep2wake. After that, idle drain returns to normal.
I know that many of you are satisfied to get through the day with one battery charge because you use the device permanently. At night, the smartphone is connected to the charger and that's it. If you belong to exactly this group of users, you can save yourself the further reading
Well, I am a bit different in this aspect. I sit in front of the PC for most of the day and use the smartphone comparatively rarely. I want to be reachable by phone, but I don't need to chat via Messenger all day. When I have time, I turn on WiFi or mobile data and retrieve messages manually. Generally, I only turn on all needed connections when I'm actively using them - the only exception is cellular for calls and text messages, that only gets turned off at night with flight mode. I also don't watch Netflix & Co via smartphone, in general I rather rarely watch videos on the smartphone. I also do not need to play games with the smartphone and if I do, then Sudoku or similar is enough for me For all these applications I have a PC, large monitors and an even larger TV as screen. Sounds oldscool, and yeah, that's me
I also have relatively few apps installed - only the ones I actually use. When possible, I use the mobile versions of websites rather than installing an app for them. This has the advantage that I only need one app for many things, and I need to keep it up-to-date: a browser.
In short: I am not interested in benchmark numbers of CPU/GPU. I need a reasonably good camera and a not too lame CPU for post-processing. In my free time, I am usually in the outback for several days/weeks without a power source (well, I have a small powerbank, of course), so a long runtime is mandatory. I want an enduring and reasonably smooth running phone that I don't have to charge every day or even every two or three days.
When I (not entirely voluntarily) switched from the F1 to the F3, I expected a lot because of the OLED screen and the larger battery. However, I had to realize that I have problems to even come close to the runtimes of my optimized F1.
I started logging the battery charges of the F1 purely out of interest.
A few relevant averages from 119 logged charges (in 787 days) are as follows:
Run time: 109 hours (so about 4.5 days).
SOT: 8 hours
Phone calls: 2.5 hours
I continued the log with the F3. The averages from 30 logged charges (in 111 days):
Run time: 62 hours (so just over 2.5 days).
SOT: 6.5 hours
Phone calls: 1.5 hours
Of course, AOD, pocket mode, DT2W, light sensor and all that stuff is disabled and I only use dark themes and 60 Hz. Just like on the F1, I don't use any Google services on the F3. Practically nothing changed in my usage behavior. However, the results are mighty disappointing...
I experimented a lot, other kernels, other ROMs, but it was practically the same/similarly bad everywhere. Now I'm running HavocOS with its own Kernel for the time being, because the idle consumption seemed to be lower than with other ROMs/Kernels. However, I made a few tweaks (all apps are available in the F-Droid Store):
1. Smartpack Kernel Manager: I lowered the boost clocks of the prime core and of the 3 main cores by a few 100 MHz.
2. Konabess: I undervolted the GPU and flashed the modified Kernel.
3. SuperFreeze: Most apps are frozen when the screen is locked. There are a few exceptions (Tidal, OsmAnd+, AntennaPod, etc.) that are allowed to run in the background until I force them to stop.
4. Autostart: I disabled the start triggers of almost all apps to keep closed apps closed.
Of course, my F3 does not break any benchmark records with this, but that is not my point. Everything still runs smoothly. With these things in place, I'm finally getting these averages from 3 charges:
Run time: 83 hours (so about 3,5 days)
SOT: 9 hours
Phone calls: 2 hours
That's still far from my original hope, but at least it's a significant increase. I very much hope that I have not yet reached the maximum.
TLDR
I would be interested to know if there are any people here at XDA who are similarly "passive". And if so, how satisfied they are with the F3 and/or what settings/tweaks they have made to achieve long runtimes and good SOT at the same time. I would be pleased about a few experiences and comparison values
I know this is probably the opposite of what you want to read, and I'm just a simple active user of my phone, but I'd say, don't get too frustrated with battery life / SOT. I'd say it just is what it is.
If you adjust your phone to as much battery saving as possible, it's probably not fun, because you have so many cool awesome features on the Poco F3, like 120 Hz and MEMC for YouTube etc...
I'd say if you want to keep Bluetooth on to receive notifications and calls on your smartwatch then just go ahead.
Instead of going for maximum battery saving, you could go for a balance of enabling some of the cool features and ditching the ones you don't want as much, like AOD or a 2. sim-card..
I don't know if this reply is any helpful, probably not, but what gives シ
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
dreamytom said:
I don't know if this reply is any helpful, probably not, but what gives
Click to expand...
Click to collapse
Haha, thanks for your answer
Indeed, I have set up the phone according to my needs and wishes and I am disappointed that contrary to the logical assumption (that a larger battery and an OLED display promise longer runtimes), the runtime has decreased significantly compared to the F1.
I'm not limiting myself, if that's how you understood my post. I have to limit the phone and turn off all the unnecessary stuff, because a smartphone is more a useful tool than a toy for me. I don't need permanent location tracking. Most of the time I know where I am and where I want to go. If not: It takes 2-3 seconds for the GPS to find me after switching on... I don't need 120 Hz, because I don't see any difference in my usecases... Beyond that, I don't need a smartwatch either. I'm glad I don't have to wear a watch anymore since there are mobile phones.... And after all, I don't need to be permanently available via chat. Whoever has something important to say can call me. Otherwise this one can wait for an answer... When my smartphone is locked, so the screen is off, it should be quiet, unless it is important or I explicitly want to get notified. If it's constantly blinking, vibrating or jingling, I would never get to work
I know, it sounds not very trendy: Many of the "innovative" features bring solutions to problems that I didn't/don't have.
Good idea. When I used mi 9 lite or poco x3 nfc I was able to use my phone from 3 to 5 days without chargeing. Now I have poco f3 and I have to change something. Ok, I use only LOS from years on all my devices ... maybe time to change ...
My way to manage battery was and is now is a script in Automagic. When I lock the screen I turn off interfaces like wifi, mobile data, locatin/gps, bluetooth, nfc, (cellular in tablets without card) and turn on when screen is unlocked. Never use airplane mode for cut LTE signal and smses. When the phone is locked more than 60 minutes I turn on battery saver mode.
Of course , each device has predefined which interface can be turned off ... Autostart I control in SDMaid. If I cut init signals app will not be able to start and use energy in background in exception I will call it. (The games are the best example to want do something in background what is absolutely not needed for me) I never freeze any apps neither overeclock cpu nor undervoltage gpu.
This what I see on my new F3 is no power after 40 hours of work. I found wakelock in LOS but blocking it in Optimus does not change many - I see deep sleep but 1%/h night lost is not very big difference when I had no deep sleep in LOS kernel. Baallam is empty of this problem but 1%-0.9% is the same result.
I have to say goodbye to LOS , I afraid.
Today I have active drain 8%/h, idle drain 0.86%/h (LOS 18.1 and baalam).
To be honest, I am OK with the battery backup of the F3. With all the modifications I could now at least manage to equalise the running time of the F1 (with LOS 16, Android Pie). But considering that the battery of the F3 is 500 mAh bigger than that of the F1, this is somehow quite bad.
Now, however, I have recently received a battery dump of my old F1, with Havoc 4 (Android 11, without major optimisations). The analysis shows a significantly lower runtime and at the same time a significantly lower sum of call time and SOT as it was with Android 9. This suggests that Android itself is a major contributor to the fact that consumption has increased significantly in recent years (with the same hardware).
@Tomek0000
I had the problem that the consumption in idle mode suddenly increased massively. After each restart everything was fine, but at a certain point the consumption was like hell. Although I could never find the cause, I found a solution: I was able to prevent this by freezing most of the apps as soon as I turn off the screen (with SuperFreeze). Now the idle drain keeps low over the whole runtime.
The last run with the F3 (Havoc 4.14, NOKernel 2.3 battery, CPU underclocked, GPU undervolted):
Run time: 158 hours (about 6.5 days).
SOT: 9 hours
Phone calls: 1 hour
I have played with havoc yesterday and have results from the night. I moved my card to old x3 nfc and night lost of energy is 0.25% without freezing, down voltage or airplane mode. The havoc in F3 eats 1% of battery during each night hour and it was without using gsm card suppoort! I thought, havoc is better in this subject and additionaly has adaptive charging and wakelock blocker. No it is not better. Adaptive charging does not work and wakelock blocker blocks but not wakelocks. I did not find wakelocks on its list. I do not know what is on this list ... it is all but not wakelocks.
Ok I invested time in havoc and I will play with it some time, but card will be in x3, and ... LOS is better in the first sight.
I know, you will suggest additional apps (freezing ...) , but I will use it when I will decide which custom rom will be the best for it.
I think, I made a big mistake when I decided to buy new smartfon with snap 8xx. It should be 778 or 780. This is excelent lesson for the future.
Havoc has the same wakelock problem like LOS and it has to be result of MIUI 12.5.6.0 using as a base. Ironic ... build in wakelock blocker does not see it at all. When I will finish with Havoc I will have to use older MIUI as a base.
Let me know how you's go with this. I seem to have this same wake lock regardless of which ROM I use, losing 7-8% battery OVERNIGHT is far from normal.
I'm currently on HelluvaOS "HOS" 12 on base V12.5.6.0.RKHMIXM, as far as I recall the issue was present on older bases back from when I bought my F3 on launch.
The way to fix the wakelock is to block it. Havoc has not working wakelock block. You have to use optimus or ballam kernel. The both have working blocker. Optimus will block it but ( a supprise) ballam does not have this wakelock problem. This is my experience from time of use LOS 18.1. I tested N0Kernel 2.3 too, but it doubling energy use and does not have blocker.
Did you write, the c440000.qcom,spmi:qcom,[email protected]:qcom,qpnp-smb5 problem exists from earlier versions of MIUI ? Is not only in 12.5.6.0 ?
Vulnerability said:
Let me know how you's go with this. I seem to have this same wake lock regardless of which ROM I use, losing 7-8% battery OVERNIGHT is far from normal.
I'm currently on HelluvaOS "HOS" 12 on base V12.5.6.0.RKHMIXM, as far as I recall the issue was present on older bases back from when I bought my F3 on launch.
Click to expand...
Click to collapse
Does this wakelock exists in earlier miui versions? Which version number has the oldest you tried?
Tomek0000 said:
I think, I made a big mistake when I decided to buy new smartfon with snap 8xx. It should be 778 or 780. This is excelent lesson for the future.
Click to expand...
Click to collapse
I totally understand!
The thing with these new Snappys is that although they might be more efficient than their predecessors, this advantage is thrown overboard by constant clocking at the limit. Unfortunately, a modern Snappy from a smaller series is not necessarily more efficient. They all seem to be maxed out...
Tomek0000 said:
I do not know what is on this list ... it is all but not wakelocks.
Click to expand...
Click to collapse
You cannot block every system/kernel wakelock because your system would break then.
Regarding a full cycle, my phone has
1.5 to 11 app wakelocks per hour
1500 to 4000 kernel wakelocks per hour
- depending on what I've done during the cycle.
The number of kernel wakelocks sounds a lot at first, but they do not necessarily mean to effect the idle drain of your phone. The cycle I mentioned above, shows 2,276 app wakelocks and 266,641 (!) kernel wakelocks in sum (runtime 158h). Both, the app wakelocks and the kernel wakelocks did wake the phone for about 2 hours each.
The exact wakelock you mentioned (c440000.qcom,spmi:qcom,[email protected]:qcom,qpnp-smb5) didn't show up on my device at all. I've installed the latest EEA firmware (12.5.8).
Did you make a clean flash with formatting all data?
I have read more and this wakelock could be connected to ACC app. If you do not control your charging process maybe you do not see this problem. I do not use ACC in havoc , but initiated adaptive charge and adaptive battery. I have to decide if I use 12.5.8 or like LOS requires 12.5.3.
Yep, I don't use adaptive charging. I charge my F3 every 4 days (in average) with 12 W. The battery is full in less than 1.5 hours. That's ok... And I always charge up to 100 %. Within the >11 months I own the F3 I charged it about 100x (84 of which are protocolled; 34 of which with a full bugreport incl, battery dump).
I don't see the benefit of smart/adaptive charging. All my previous phones lasted 5 years or more with always full charging - it never was the battery which gives up. I still use my ZUK Z1 as mp3 player (always power on, about 1h per day active usage as mp3 player) and I have to charge it once in 2-3 weeks...
So, adaptive charging doesn't work in Havoc? Then turn it off and you're rid of the wakelock!
I always use battery charge limit but it did not worked with LOS on F3. Maybe when I change kernel it will start working. I use it for keep battery in good condition for additional 25% of live time. I be voice informed by script about 30% or lower and I connect charge for all night and charge will stop when level will be 85%. And it was enough for 3-5 days of using my previous smartfons.
I reinstalled 12.5.8 and April LOS and did not install ACC. No wakelock, very good power consumption during screen off.
In my experience, exposing the battery to heat/cold and/or charging/discharging excessively quickly is much more damaging to the battery than charging it gently up to 100 % and then unplug. But, of course, if you charge your phone overnight and it's plugged for hours, it might be useful to stay below 100 %.
However, in our case (charging only once every few days), it will probably be the lack of updates/features that drives us to switch the phone...
Tomek0000 said:
I reinstalled 12.5.8 and April LOS and did not install ACC. No wakelock, very good power consumption during screen off.
Click to expand...
Click to collapse
Great. Would you mind writing here how long your phone last on one cycle?
One cycle ? I am not sure how to check it. 95% deep sleep and FKM report 0.35%/h nightly lost using LOS kernel. Previous result was ~1.8% with ACC installed.
Tomek0000 said:
Does this wakelock exists in earlier miui versions? Which version number has the oldest you tried
Click to expand...
Click to collapse
I've had the phone since day 1 and have had this idle drain issue since. The oldest I've tried is whatever shipped with the first batch of phones
Interesting. I found this wakelock in LOS if I installed Acc and in Havoc when activated adaptive charge. If I do not use it , the problem does not exist. The use of Battery Charge Limit does not activate the wakelock too.
This is very interesting like kernels work. If the wakelock was a problem, the best result was with balaam kerenl. When no problem , the balaam seems to be the worst.
esszett said:
2. Konabess: I undervolted the GPU and flashed the modified Kernel.
Click to expand...
Click to collapse
Could you share your definition file ?
I used this app and idle lost jumped 250%.
Do you use version 0.16 or older?
Tomek0000 said:
Could you share your definition file ?
I used this app and idle lost jumped 250%.
Do you use version 0.16 or older?
Click to expand...
Click to collapse
I use 0.14b... I only changed the voltages of the existing frequencies, saved and then flashed the modified kernel.
305 MHz --> MIN_SVS
400 MHz --> MIN_SVS
441 MHz --> MIN_SVS
490 MHz --> LOW_SVS_L1
525 MHz --> SVS_L0
587 MHz --> SVS_L0
670 MHz --> SVS_L2
Anyway, that doesn't affect the idle consumption at all, of course. It should only affect the SOT.
esszett said:
1. Smartpack Kernel Manager: I lowered the boost clocks of the prime core and of the 3 main cores by a few 100 MHz.
Click to expand...
Click to collapse
BTW: In the meantime I used FKM for that. But i stopped underclocking, because several tests with my phone showed me that underclocking is more or less useless. Although a significantly lower frequency was reliably applied, this did not reduce the consumption or at best minimally - but without any influence on the runtime... I now have uninstalled both Smartpack Kernel Manager and FKM.
I still only understand the consumption of the F3 to a very limited extent. While I now have the consumption in idle under control, the consumption remains very high during light and medium loads. For example, when I make calls with the F3 with LTE, the consumption is 1.5-2x as high as with the F1 with LTE. I just don't know how to lower the consumption
Thank you. I used config file from thread about optimum setting for overclock and downvoltage. It has to be not optimum solution.
Could you write your consumption during light and medium load for F1 and F3 ? (For compare possibility)
Have you ever thought about using runinbackgroundper1.5.apk ? I found it this week .
[APP][Root][7.0+]RunInBackgroundSetter v1.4 :: [25.07.2017]
Few hours ago explainAndroid posted article on xda main page onto how to use android's hidden RUN_IN_BACKGROUND permission to restrict app's background behavior. I made an app for that. Here's link to original article...
forum.xda-developers.com