Nexus 4 Fixes: Custom kernel installer mods & more - Nexus 4 General

Intro
Over the past while I've finally decided to fix all minor annoyances on my Nexus 4. Here is a guide where I'll share all my modifications to make Mashmallow on the Mako as good as can be.
Kernel
Kernel Proper
The actual kernel included in this guide is HellSpawn kernel by @spezi77 which is based on hells-Core for Marshmallow, with all up-to-date Linux patches (3.4.112) and Google security patches (June 1). (Although I use, advocate, and absolutely recommend HellSpawn, feel free to use another custom kernel in the installer. You'll have to replace zImage and make your own changes to kernel/sema-boot.sh if your kernel doesn't include the same governors, hotplugs, etc.)
Here are a few highlights of HellSpawn itself:
- Includes the elementalx governor from @flar2 and lightweight mako_hotplug driver from @franciscofranco, which are much better than the stock ondemand governor and mpdecision hotplugs.
- Includes franciscofranco's gamma control, which is a much better default gamma for your screen and can be changed with franco's Nexus Display Control app or other Kernel Tweaker Apps.
- Includes a GPU overclock (400 -> 487 MHz) for when really demanding graphics operations require it.
- Includes BFQ, an optimized version of the default kernel's CFQ i/o scheduler. It helps when Play Store updates occur or when apps perform a lot of disk activity.
- Includes double tap to wake feature, which uses minimal extra battery and is much more convenient than the power key.
- When the screen is off, and not sleeping, only one CPU is active and it's limited to 1 GHz, which helps standby battery life with running background services.
Custom Kernel Installer
(original post with r1 was made on reddit)
I've adjusted many default kernel settings, based on a few years experience of running custom kernels. It uses the optimized elementalx governor from ElementalX kernel and lightweight mako_hotplug from franco kernel, with some of flar2's N5 settings, some of @hellsgod's N6 settings, and some of mine. There are other governors and hotplugs available, but from my experience, these offer the best balance of speed and battery life.
It includes a small, safe, -50 mV undervolt for a bit less heat from the CPU. - a user on reddit reported a reboot with r1, so I've removed voltage settings. It's probably useless to include such a small undervolt anyway. Change voltage settings in an init.d script or Kernel Tweaker app if you wish.
It activates double tap to wake by default, and also turns on power key suspend. If you press the power key with the screen on, double tap to wake will be turned off. Those on custom ROMs or Xposed's GravityBox can activate features to turn the screen off (double tap status bar, lock screen, nav bar, etc.) and keep double tap to wake on. Those without custom ROMs can perhaps use something like Greenify which can remap the home button long-press to turn the screen off.
It includes a patch to sepolicy which allows Viper4Android to work in selinux enforcing mode. You need to have SuperSU installed to have this work.
I've adjusted the io scheduler and page cache for better performance, tuned towards random reads.
It includes stock thermald and a tweaked thermald configuration that scales CPU frequencies up and down a little smoother when your temps get high. It should be noted that most custom kernels disable thermald for their own in-kernel thermal driver. I never liked doing this, as thermald does more than just adjust CPU frequencies - it also throttles GPU, screen brightness, and most importantly, battery charging. When your device gets too hot while charging, the worst thing to do is keep up the current and let the battery go over 45 degrees.
It includes a service to do 'Shared Cpufreq Policy', which lets thermald throttle all cores properly, and also lets the Battery Saver feature work correctly, by limiting all cores. This hasn't worked since KitKat and was one of my biggest annoyances. Many, if not all custom kernels just deleted the Power HAL libraries so battery saver feature doesn't work at all!
Includes Semaphore's 'mpdfake', a service to eat the touch boost spam that the Power HAL generates when not using mpdecision. If a custom kernel does not delete the Power HAL libraries, then your logcat is being spammed and logd process uses a lot of background CPU!
Includes a service to attempt to fix once and for all the location/GPS issues. I'm not going to state it works 100% yet, as I've only had max 24 hr uptime while making changes from the r1 release, but so far so good. Fingers crossed...
Includes a service to give SystemUI and Phone/Dialer higher priority. I haven't had a chance to really test it, as my device is sans-SIM at the moment, but it hopefully will lead to better responsiveness when you receive a call. (Under testing: giving some background processes lower priority, so they don't interrupt app usage.)
Move dalvik-cache to /cache partition and free 300-500 MB:
On each boot, it will check to see if you have a /cache/dalvik-cache folder, and will use it as the dalvik-cache if so.
If you are clean flashing a ROM and want to use /cache for dalvik-cache, create an empty dir in TWRP: /cache/dalvik-cache
If you just want to switch from /data to /cache, copy the /data/dalvik-cache to /cache/dalvik-cache and reboot.
Remember to be careful not to wipe /cache when 'dirty' flashing if you do this!
How to reset the mediaserver process quickly to get videos playing:
While your screen has been on for a few seconds or longer, double press the power key. You'll have to try it a few times to get the timing right, because a quick double press activates the camera in some ROMs. Also you're waiting for the screen to go off, not just dark. Practice a few times in low light, and you'll get the hang of the timing: each press should be followed by about half a second. You'll feel a short vibration when the service resets mediaserver to give some feedback that it's working. If it doesn't run the first time, keep cycling the screen off and on again until you get that vibration.
Remember: you have to start with the screen on, this allows you to quickly check on notifications from screen off without resetting mediaserver.
How to reset the sensors if ambient brightness, auto rotation, GPS, or any other sensors stop working:
Same as above, but this time you do the action twice. That is, screen on - double press power - vibrate once - double press power. You must do the two double presses within a second or two, so a little more practice may be needed. You'll feel two short vibrations when the service resets the sensors.
*** As of mod-r4, the new method to reset both mediaserver and sensors is Hold Volume Up and Power.
How to reset the touch screen if it becomes unresponsive:
If you happen to double tap to wake, the screen comes up, but no touches are being registered, tap on the screen with five fingers. If this doesn't reset it, turn the screen off and on again with the power key, and tap on the screen with both hands, all ten fingers. This will reset the driver and get it going again without a reboot.
Download & Installation
The installer is attached to this post. It's for AOSP ROMs, and uses the UberTC 5.4 toolchain. I'll post up CM versions on request.
Flash the zip with TWRP 3.0.2. If you have made any changes to your Marshmallow ROM (other custom kernels, etc.) you must remember to always flash custom kernels after (dirty) flashing custom ROMs! This is especially important, as if you are missing thermald you're going to have a bad time. FLASH YOUR ROM BEFORE THIS KERNEL INSTALLER UNLESS YOU HAVEN'T MADE ANY CHANGES. You can kill your device without thermal throttling!
Wiping dalvik-cache, and /cache is never necessary when flashing a custom kernel only.
ROM
Graphics Drivers
Audio
SuperSU - System or systemless?
Changelog: r14-mod-r3 - r13-mod4 - r16-mod-r5 - r04-mod-r6 - r05-mod-r7

Sorry, ran out of time for now but I'll continue the post soon...

If I want to customise the features, do I only comment out the features which I don't need in sema-boot.sh? Thx!

Hi @xenyz,
Thank you for your new kernel, I have to say that I missed using your projects.
Until now I'm testing it and the only cons I found is that with mako_hotplug when (temp increases) 1026 frequency makes mako very unresponsive.
Is there a way to change this frequency through a init.t script?
Thanks for keeping mako alive!

jer_ying_fd said:
If I want to customise the features, do I only comment out the features which I don't need in sema-boot.sh? Thx!
Click to expand...
Click to collapse
Sure, or another option is to put your overrides in /system/etc/init.d
jolas said:
Until now I'm testing it and the only cons I found is that with mako_hotplug when (temp increases) 1026 frequency makes mako very unresponsive.
Is there a way to change this frequency through a init.t script?
Click to expand...
Click to collapse
Carefully edit /system/etc/thermald.conf either in the installer before flashing, or on your device after flashing, and make your changes near the end of the file.
Can anyone comment on whether their location services are working better? I'm still undecided.
Sent from my Nexus 4 using Tapatalk

With the introduction of the new features of hellspawn r14, will it still work as it is?

jer_ying_fd said:
With the introduction of the new features of hellspawn r14, will it still work as it is?
Click to expand...
Click to collapse
I'm testing it out to make sure it's stable first. At least one change has to be made, turning off the new msm_hotplug which is enabled by default in r14.
Sent from my Nexus 4 using Tapatalk

xenyz said:
I'm testing it out to make sure it's stable first. At least one change has to be made, turning off the new msm_hotplug which is enabled by default in r14.
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Ahh of course, I forgot to edit that out....

I've gotten strange behavior after installing the kernel on my Chroma ROM Nexus 4.
The touchscreen began to have bouts of unresponsiveness, when it never had it prior to installation
Extremely slow on wakeup after a long time in sleep mode. Once again, never had that issue before
Overall lag and slowdown that wasn't present on the stock kernel
I've enabled only D2TW, the new I/O scheduler, 1 core active on sleep, Schedule workqueues on awake cores, and ThermalId
Just now, it did a random reboot. Any idea on what the issue could be?

ArtOfSnaila said:
I've enabled only D2TW, the new I/O scheduler, 1 core active on sleep, Schedule workqueues on awake cores, and ThermalId
Just now, it did a random reboot. Any idea on what the issue could be?
Click to expand...
Click to collapse
Could you try it without changing any settings? Force stop the kernel app and reboot.
Do you use any Doze modification apps? Greenify aggressive doze?
Was it a reboot or a SystemUI restart? Did you see the Google bootloader logo? If so, send me last_kmsg
Sent from my Nexus 4 using Tapatalk

xenyz said:
Could you try it without changing any settings? Force stop the kernel app and reboot.
Do you use any Doze modification apps? Greenify aggressive doze?
Was it a reboot or a SystemUI restart? Did you see the Google bootloader logo? If so, send me last_kmsg
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Alright, I'll try it without any settings modified.
I do use Aggressive Doze, could that be conflicting with the kernel? It never seemed to affect the stock kernel besides making the wake take a bit longer, but no lag afterwards.
It was a complete reboot, with the Google logo and everything. Here's the last_kmsg.

ArtOfSnaila said:
I do use Aggressive Doze, could that be conflicting with the kernel? It never seemed to affect the stock kernel besides making the wake take a bit longer, but no lag afterwards.
Click to expand...
Click to collapse
I have noticed some erratic behaviour when modifying doze settings. My best guess is that there are certain assumptions made in Marshmallow as to when the device will be in Doze mode, and changing them can have unintended consequences.
ArtOfSnaila said:
It was a complete reboot, with the Google logo and everything. Here's the last_kmsg.
Click to expand...
Click to collapse
That is strange, the reboot was caused by a restart to recovery request. If it happens again, grab another last_kmsg?
Sent from my Nexus 4 using Tapatalk

xenyz said:
I have noticed some erratic behaviour when modifying doze settings. My best guess is that there are certain assumptions made in Marshmallow as to when the device will be in Doze mode, and changing them can have unintended consequences.
That is strange, the reboot was caused by a restart to recovery request. If it happens again, grab another last_kmsg?
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Ah crap, about the last.kmsg, I think I know what happened. To pull the .txt file I had to reboot into recovery and use terminal to mount /system and then pull it. It might've pulled data off of that restart.
Currently using the phone with no kernel app active, and it's doing fine. I'll keep you posted if weird stuff happens.
Another thing I noticed is that when I plugged in the charger, the phone would slow down a lot.

ArtOfSnaila said:
...
Another thing I noticed is that when I plugged in the charger, the phone would slow down a lot.
Click to expand...
Click to collapse
Maybe it had to do with hotplug settings (I used to have similar problems until I modified thermald.conf settings)
Sent from my Nexus 4 using Tapatalk

ArtOfSnaila said:
Another thing I noticed is that when I plugged in the charger, the phone would slow down a lot.
Click to expand...
Click to collapse
That's likely because of the thermal throttle when the battery gets warm. Keep in mind this is actually good for your battery, although annoying when it slows down.
I'm thinking about raising the threshold just a bit in the next release.
Sent from my Nexus 4 using Tapatalk

xenyz said:
That's likely because of the thermal throttle when the battery gets warm. Keep in mind this is actually good for your battery, although annoying when it slows down.
I'm thinking about raising the threshold just a bit in the next release.
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
I found the following changes to accomplish best my needs (snappier phone with average temp)

jolas said:
I found the following changes to accomplish best my needs (snappier phone with average temp)
Click to expand...
Click to collapse
Cool. Er, warm. Eh, whatever.
What's your battery temps whilst charging? This is my main concern and where throttle is necessary.
All batteries achieve optimum service life if used at 20°C (68°F) or slightly below. If, for example, a battery operates at 30°C (86°F) instead of a more moderate lower room temperature, the cycle life is reduced by 20 percent. At 40°C (104°F), the loss jumps to a whopping 40 percent, and if charged and discharged at 45°C (113°F), the cycle life is only half of what can be expected if used at 20°C (68°F).
Click to expand...
Click to collapse
source
I know it's likely not that useful for those of us with original batteries on older devices, but I try to treat it as best I can.
Sent from my Nexus 4 using Tapatalk

xenyz said:
Cool. Er, warm. Eh, whatever.
What's your battery temps whilst charging? This is my main concern and where throttle is necessary.
source
I know it's likely not that useful for those of us with original batteries on older devices, but I try to treat it as best I can.
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Charging with screen on, battery temp around 40°C
Sent from my Nexus 4 using Tapatalk

After more than 24 hours of usage without kernel manager, it ran fine, until it started throttling for some reason. Turns out somehow, the max clock speed was locked to 1000 or so Mhz. I don't know if that was the kernel or the app misbehaving, but I ended up having to reactivate the kernel app to set the clock speed back to normal
There was another spontaneous reboot, here's the last.kmsg.

ArtOfSnaila said:
There was another spontaneous reboot, here's the last.kmsg.
Click to expand...
Click to collapse
Thanks for the log. I had a similar reboot but with r14, something in the wakeup_reasons code. I'll have a look through spezi77s commits in kernel/power and see if I can spot something.
I haven't had one reboot in a month or so of using r13, so it's quite strange that you had one so soon, after 24h.
As for the throttle, keep an eye on your battery temperature in Kernel Auditor or whatever and see if it's higher than 40 degrees when you get the 1 GHz max freq.
Edit: I discovered at least one bug in r2 wrt the PowerHal touch boost spam. I'm thinking of posting r14mod3 but I'm not certain r14 is stable yet (see main kernel thread)...
Sent from my Nexus 4 using Tapatalk

Related

[APP][MAY 22] Myrt Torture Tester 0.5.6 Beta

Welcome to Myrt Torture Tester.
As always, this app is BETA, expect bugs. Tested on Stock GB/HP Extreme & guestekrnL, CM7/Etana, CM9/HP ICS & Harsh.
Will only work on OC/UV-kernels.
It's primarily intended as a tester to find your stable frequencies and voltages, but can also be used as a battery-life tester and a rough benchmark.
This app comes with no more support than the 2nd post. If you don't know how to use it after reading that you don't need it.
Using this app, you will be capable of causing actual damage to your device. I take no responsibility for any consequences.
This app shall under NO CIRCUMSTANCES be included in any ROM, or uploaded any other place than this post.
Changelog
0.5.6 - Fixes crash when system is unresponsive for long periods.
0.5.5 - Keeps reading the current cpu-frequency throughout the test. (Some beta kernels unexpectedly change frequencies during the test, this allows you to see it.)
0.5.4 - CM7-compatability-fix.
0.5.3 - Fixes frequency not being set on guestekrnL.
0.5.2 - Fixed links on about page.
0.5.1 - Plays nice on non-oc kernels.
0.5.0 - First BETA-release
HOW TO USE:
In its simplest form, the app is a benchmark. You start a CPU-test at a specific frequency for a specific time-period and get the average Mflops-result. If you are going to compare different kernels, it will give you a normalized to 1Ghz result as well. Different kernels usually have different frequency-tables, so test them at the closest steps you can find, then compare the normalized result.
The more useful aspect of it is to test if a specific frequency is stable at a specific voltage. The app only allows to test the frequencies in the voltage table - because if it is stable at those frequencies it will be stable at all other frequencies which fall within those voltage-steps. If you have undervolted too much, the phone will usually reboot pretty quickly. If you have undervolted "on-the-edge", the phone will likely freeze. If you have undervolted so that it is basically stable, but sometimes fails, you'll either get a crash to the desktop or MTT will inform you of a calculation error. If you are testing for stability you need to test for at least 60 minutes to have any confidence in the result, I've had several tests fail after 45-50 minutes.
It can also be used to see what impact, if any, undervolting has on the processors' power-consumption. After you have made sure a frequency/voltage-pair is stable, you can run a battery-test and compare it to an identical test at stock voltage. This will simply run from a full(ish) battery to a certain battery percentage, and give you how long it was able to run. Since the battery-percentage is pretty loosely coupled to the actual battery-charge, it will also give figures for consumption per minute or second. This kind of test should also be run over a long a period as possible to get accurate results. Measuring from 100% to 90% will only give you an indication, prone to error. You can not compare a test between, say 100->50 and 100->20, because the discharge rate varies with the charge-level.
For most accurate testing and benchmarking: enable flightmode, unplug the device, freeze any apps which may run in the background, uninstall everything you don't need, wait 3 minutes after booting before testing, do not touch the screen or move the device while a test is running. Even then there are Android quirks which will cause some variation in the results. Therefore the same test should be repeated as many times as you can afford.
The major enemy of stability, assuming you have enough voltage, is heat. Make sure to test the device under the same conditions as it will be used. If you're going to overclock on a hot summer's day, test it on a hot summer's day. MTT dims the screen to minimize the impact it has on the battery and heat-generation, be aware that your device will be hotter when the screen is at normal brightness.
Stability tests should also be performed at different battery-levels. If your device is stable when the battery is fully charged, it does not automatically mean it will be stable when it is almost discharged.
MTT logs all succesfull tests (max 200 lines.) If you enable "Store log on sdcard" in preferences the log will be saved to /sdcard/MTT_Log.txt.
Known issues:
o Sometimes the device will give you half the score you should get. I do not know if this is a kernel or android-bug, but it seems that both test threads get scheduled to run on the same core, and the second core goes unused, even when it is active. Exiting the app and starting it again does not help usually, but killing it sometimes does. Rebooting is always an option.
o Not a "known issue", but this app lets you under- and overvolt in 5mV steps. Different kernels may handle this differently, either not undervolting at all, or adjusting it to the nearest 25mV step. It has worked on the kernels I have tried, but there are too many kernels out there to be sure.
TrymHansen said:
HOW TO USE:
In its simplest form, the app is a benchmark. You start a CPU-test at a specific frequency for a specific time-period and get the average Mflops-result. If you are going to compare different kernels, it will give you a normalized to 1Ghz result as well. Different kernels usually have different frequency-tables, so test them at the closest steps you can find, then compare the normalized result.
The more useful aspect of it is to test if a specific frequency is stable at a specific voltage. The app only allows to test the frequencies in the voltage table - because if it is stable at those frequencies it will be stable at all other frequencies which fall within those voltage-steps. If you have undervolted too much, the phone will usually reboot pretty quickly. If you have undervolted "on-the-edge", the phone will likely freeze. If you have undervolted so that it is basically stable, but sometimes fails, you'll either get a crash to the desktop or MTT will inform you of a calculation error. If you are testing for stability you need to test for at least 60 minutes to have any confidence in the result, I've had several tests fail after 45-50 minutes.
It can also be used to see what impact, if any, undervolting has on the processors' power-consumption. After you have made sure a frequency/voltage-pair is stable, you can run a battery-test. This will simply run from a full(ish) battery to a certain battery percentage, and give you how long it was able to run. Since the battery-percentage is pretty loosely coupled to the actual battery-charge, it will also give figures for consumption per minute or second. This kind of test should also be run over a long a period as possible to get accurate results. Measuring from 100% to 90% will only give you an indication, prone to error. You can not compare a test between, say 100->50 and 100->20, because the discharge rate varies with the charge-level.
For most accurate testing and benchmarking: enable flightmode, freeze any apps which may run in the background, uninstall everything you don't need. Even then there are Android quirks which will cause some variation in the results. Therefore the same test should be repeated as many times as you can afford.
The major enemy of stability, assuming you have enough voltage, is heat. Make sure to test the device under the same conditions as it will be used. If you're going to overclock on a hot summer's day, test it on a hot summer's day. MTT dims the screen to minimize the impact it has on the battery and heat-generation, be aware that your device will be hotter when the screen is at normal brightness.
Stability tests should also be performed at different battery-levels. If your device is stable when the battery is fully charged, it does not automatically mean it will be stable when it is almost discharged.
MTT logs all succesfull tests. If you enable "Store log on sdcard" in preferences the log will be saved to /sdcard/MTT_Log.txt.
Click to expand...
Click to collapse
Really interesting! Big thanks
Sent by LG Optimus 2x
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc results in that new max freq being used all the time in the program.
kfallz said:
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc also results in that new max freq being used all the time in the program.
Click to expand...
Click to collapse
Ok, thanks for the feedback. Which version of guestekrnL? I'm mainly using that myself, works here on 1.7.
EDIT: Ok, I've found the reason. I had disabled the 00cpufreqenabler script (to simulate other kernels), but it didn't work after I enabled it. Will release a fix as soon as I can override the permission properly.
kfallz said:
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc results in that new max freq being used all the time in the program.
Click to expand...
Click to collapse
App updated to 0.5.3 - fixes the issue where frequency is not set on guestekrnL.
TrymHansen said:
App updated to 0.5.3 - fixes the issue where frequency is not set on guestekrnL.
Click to expand...
Click to collapse
Giving the new version a try, and not that it matters now but I'm using 1.7.0t2
Yea working fine now
Updated to 0.5.4 - Now the sliders behave properly on CM7.
Myrt, do you think that we have more than one different hardware inside our phones? Because the results are way to different from one ppl to another, for example, Temasek can't OC even to 1.1GHz, and Vadonka puts at 1.4GHz without the burn, with the tests, I get to 70ºC in 2min with 1.1GHz, but the strange thing, is that the phone doesn't lags or anything to show that it haves an high-temp. Did you have some screen of the test in your own phone? I have exchanged my first phone because it always get too hot for me, my second gets hot always when I try to play any game.
chaozbr said:
Myrt, do you think that we have more than one different hardware inside our phones? Because the results are way to different from one ppl to another, for example, Temasek can't OC even to 1.1GHz, and Vadonka puts at 1.4GHz without the burn
Click to expand...
Click to collapse
No, we have pretty much the same hardware, specification-wise. It is very common to have different tolerances for speeds and voltages. I'm pretty sure that the moment Vadonka tries my app at 1.4Ghz, he too will get a hot CPU.
, with the tests, I get to 70ºC in 2min with 1.1GHz, but the strange thing, is that the phone doesn't lags or anything to show that it haves an high-temp.
Did you have some screen of the test in your own phone? I have exchanged my first phone because it always get too hot for me, my second gets hot always when I try to play any game.
Click to expand...
Click to collapse
I didn't take a screenshot, if that is what you ask, I have the app abort the test at 72C, and the temp falls quickly back to normal. I don't even have vadonkas kernel installed anymore, I'm a stock man, installed CM7 just to make the app compatible.
However, I guess we can encourage people to post their temps and frequencies here, in this thread. If anyone manages to run 1.4Ghz for more than 5 minutes and not reach 70C I'll be impressed. (I do all my temp-testing when plugged in though, probably easier when unplugged.)
TrymHansen said:
No, we have pretty much the same hardware, specification-wise. It is very common to have different tolerances for speeds and voltages. I'm pretty sure that the moment Vadonka tries my app at 1.4Ghz, he too will get a hot CPU.
I didn't take a screenshot, if that is what you ask, I have the app abort the test at 72C, and the temp falls quickly back to normal. I don't even have vadonkas kernel installed anymore, I'm a stock man, installed CM7 just to make the app compatible.
I had these temps in Spica HP kernel, so stock rom, CM7 with Vadonka, I saw an 84ºC (leave my brother playing in the phone, and he said to me that the phone was hot haha)
Click to expand...
Click to collapse
TrymHansen said:
However, I guess we can encourage people to post their temps and frequencies here, in this thread. If anyone manages to run 1.4Ghz for more than 5 minutes and not reach 70C I'll be impressed. (I do all my temp-testing when plugged in though, probably easier when unplugged.)
Click to expand...
Click to collapse
If we can't run 1.4GHz for me than 5min without reaching 70ºC, and 70ºC is the maximum temp, we can't play or let the phone in the frequency for daily use?
chaozbr said:
If we can't run 1.4GHz for me than 5min without reaching 70ºC, and 70ºC is the maximum temp, we can't play or let the phone in the frequency for daily use?
Click to expand...
Click to collapse
Well, no, I'm not saying that, there are too many unknowns.
1) We don't know if the reported temp is correct.
2) We dont' really know the max temp for tegra2. (The 70C figure is not from an official source.)
3) This app is meant to test stability, so temps will get as hot as possible. A game will most likely not stress the CPUs quite as much.
But, all that taken into consideration, 1.4Ghz is probably too high for sustained operation. It will probably be fine for normal use, where the CPUs get to rest once in a while, but not for prolonged CPU-heavy tasks (which this app demonstrates.) That being said, this app is designed to produce as much heat as possible to test stability.
It took me 41sec till the CPU reached 70°C from 40°C on 1408MHz using latest beta 3.0.y etana.
Tapatalk 2-vel küldve az én Optimus 2X-ről
Thanks for this, this app looks great!
I usually don't UV as it introduces some instability to my device even at low -UV values which isn't worth the rather small gain in battery life - but it's still good to know that this app existis if I'll change my mind someday
tonyp said:
Thanks for this, this app looks great!
I usually don't UV as it introduces some instability to my device even at low -UV values which isn't worth the rather small gain in battery life - but it's still good to know that this app existis if I'll change my mind someday
Click to expand...
Click to collapse
Yeah, I don't usually undervolt either, I carry spare batteries, and the fear of unstability was always lurking when I did. (I did make an undervolt app afterall, had to test it.)
So with this app my hope is that many myths will be dispelled - using this people should be able to find out what they need.
(A few weeks ago I had forgotten the batteries in a bag in a hotellroom, far away. I really, really, really needed 20 extra minutes of battery-life then. So now I will probably undervolt to voltages I know are safe, just in case something similar should happen. Sometimes 5 minutes make all the difference in the world.)
I cannot set any other V (no UV or OV) using Temasek 99 with latest Vadonka Beta 11.05. Kernel. The program always crash after the 2sec warmup.
Gesendet von meinem Optimus 2X mit Tapatalk 2
kennbo82 said:
I cannot set any other V (no UV or OV) using Temasek 99 with latest Vadonka Beta 11.05. Kernel. The program always crash after the 2sec warmup.
Gesendet von meinem Optimus 2X mit Tapatalk 2
Click to expand...
Click to collapse
Ok, I need some more info I think. First of all, is the app the latest version? If yes, do you get a superuser message the first time you start the app after a reboot? Which values do the bottom sliders show right after starting the app for the first time?
Tried it myself today on temasek 100 with both 3.0.31 OC and the latest beta (OC-only of course), worked on both for me. One installation however failed, and I had to repair the system-partition before the app would work again. (Superuser pretended to give access, but /system wasn't really writable, so it failed.) Check which apps are listed in superuser, if you see the same app listed a lot of times, that's your problem.
TrymHansen said:
Ok, I need some more info I think. First of all, is the app the latest version? If yes, do you get a superuser message the first time you start the app after a reboot? Which values do the bottom sliders show right after starting the app for the first time?
Tried it myself today on temasek 100 with both 3.0.31 OC and the latest beta (OC-only of course), worked on both for me. One installation however failed, and I had to repair the system-partition before the app would work again. (Superuser pretended to give access, but /system wasn't really writable, so it failed.) Check which apps are listed in superuser, if you see the same app listed a lot of times, that's your problem.
Click to expand...
Click to collapse
Sooorry I'm too stupid, tried the 216 Mhz only which is too slow for the total phone use and test. Program works fine!
Again sorry and thanks for the tool
kennbo82 said:
Sooorry I'm too stupid, tried the 216 Mhz only which is too slow for the total phone use and test. Program works fine!
Again sorry and thanks for the tool
Click to expand...
Click to collapse
Ok, good to know, thanks. I will have to look into it anyway, it shouldn't crash even at 216Mhz, but I'll take that as low-priority, in other words tomorrow ;-)

Let's list some battery tips

Hey! I've just bought S5 yesterday and I know it's still premature to evaluate my phone's performance. I've made my first 100% to 16% with the phone and my stats were.
Phone on: 18h
Screen: 3h
Bright auto -5, wifi on, 3g on all time.
I find it is not as much as I expected but I must admit there was an update in between of the OS, and many updates in the play store which probably drained my battery higher than normally. Then I've checked tips for reducing consumption and that what I made:
- install battery guru
- disable syncs in google account
- disable updates in play store (notifications and so)
- disable some samsung apps
- disable gestures and movements
- location on power saving mode
However, my intention in this post is to gather more tips you are using with samsung rom (no root). Disable accounts or whatever you do...
Anyway, I guess I should expect an improvement in the battery life in coming charges...right?
Thanks!
Battery guru even sucks more battery than its saves, because it needs google service -.-'
I use:
Faux kernel - with my own tweaks, for hopefull best performance and battery life. OC 2.7
Greenify - to Slumber apps / System apps (Paid)
Unbounce - to lower the wake ups etc. (Paid)
BootManager - For faster start up / Battery saving
Stop Log - Turning off trash for speed up and battery life
Everything is turned off except:
Wifi - When home and somewere were its not locked.
Mobile data - Always on
Removed:
Idunno what its called but it has a blue icon and beammode?
Turned off:
Svoice
Samsung Link and that other samsung like app
Samsung push
Software update
Phone Screen:
Depends on were im at:
Home: 50%
School: 30 - 50
Work: 50%
Gaming: 50 - 100%
Movie: 50 - 100%
Background:
Black saves more battery and mine looks cool ^_^
Faux Settings for me, higest what ive got so far using it is 17 hours phone use, with 4:35 screen time on and it was still on 24% had to charge it because of my date
CPU Clocks:
Max: 2726400
Min: 300000
Gov: Intelliactive
Cpu hotplug:
intelliplug
Touchboost turned on
Screen off Frequency: 729600
intelliplug = Balanced (4)
Thermal Manager:
Chosen everything that was recommended
GPU Manager:
msm-andreno-tz
CPU clock control: 578
rest is stock
I/O Scheduler: both row - 1024
Same Page Merge:
Iltelli-KSM Enabled - left the rest stock of it
Miscellaneous:
Power suspend modes: Userspace
Power suspend turned on
tcp congestion: westwood
Rest is stock
I would love to change the black/gray to Pure black, to save more battery life, Gravity box could do this trick, but the app froze my phone somehow, now that its gone it works fine like before. so if you can change it do it.
Thanks! I've removed battery guru. I know that without rooting phone I may not be able to disable many things but I guess I can avoid some wakelocks coming from the pre installed software. Right? Which of them could be? Should I disable Samsung account? Any app that replaces S health in using the heart rate sensor? I think this is the only functionality I would have to keep which needs a Samsung account
Summing up , things that could make android os and system android reduce
paco_ramirez said:
Thanks! I've removed battery guru. I know that without rooting phone I may not be able to disable many things but I guess I can avoid some wakelocks coming from the pre installed software. Right? Which of them could be? Should I disable Samsung account? Any app that replaces S health in using the heart rate sensor? I think this is the only functionality I would have to keep which needs a Samsung account
Summing up , things that could make android os and system android reduce
Click to expand...
Click to collapse
Well the apps that push notification these use too much battery, like samsung push, just disable the apps you dont use at all
Verstuurd vanaf mijn SM-G900F met Tapatalk
Thanks!, I've just disabled it. More things?
paco_ramirez said:
Thanks!, I've just disabled it. More things?
Click to expand...
Click to collapse
Do you have root and recovery?
Verstuurd vanaf mijn SM-G900F met Tapatalk
My #1 tip would be before you look at how bad ur battery is. realise these are smartphones. and we buy them because of connectivity. why buy a smartphone if you keep turning of its ability to be smart
these phones run HD displays constant internet connectivity and all sorts of sync options
Sock12345 - I don't have it rooted yet. I'm thinking about it because I don't want to have the warranty avoided. I don't know how is the law concerning this in Spain. However, I would like to root it so that I can find out thexactly drainers and get rid of them. I will check this possibility
-PiLoT- you're totally right. Maybe I am asking too much to the phone which works incredibly well. But I have the feeling that some pre installed apps maybe battery drainers. Maybe they do not drain as much as I think...

[Q] Nexus 6 problems: display, battery

I've received Nexus 6 from FlipKart, Its great but two major concerns:
1. Screen is very yellow (warm color) and on reducing brightness it becomes magenta. When compared to any other phone including Nexus 5, its extremely yellow. Tried couple of apps, none of them do a good job of fixing the yellows. Did anyone find a good app/setting to calibrate this screen right?
2. Battery life is pathetic: From 100% to 10% in half day. SOT is barely 3 - 3.5 hours (Greenified Facebook, Encryption off), no gaming, where as my friend gets 5hours. Sometimes phone hangs and switches off. When I switch on, it looses 15% battery. It has only been charged 2-3 times (only got it 2 days ago). Does it get better with time? or Am I having a faulty battery?
Update: forgot to mention my phone shuts down at 28% battery. And it didn't boot at all. I realized battery was zero. Is this calibration issue? Or bad battery
Flash elementalx, you'll be able to change color values and battery life is great
1. You can change your RGB using any kernel with support to it. Almost every single kernel have support to RGB LCD KCAL. Use a app such as Trickster to modify the RGB once you flashed a kernel of your choosing.
2. Battery life is subjective to how you use your device. Just because someone was able to achieve 5 hours+ SOT doesn't mean you will either because there are way too many factors that play into effect such as: cellular signal strength, wakelocks, apps installed, etc. If you want to maximize your battery life, look into underclocking the CPU/GPU frequency and flash a custom kernel (e.g. Franco) that removes mpdecision. Mpdecision is a huge battery drain and the frequencies that it selects is completely random and unnecessary in my opinion.
http://forum.xda-developers.com/showpost.php?p=57808725&postcount=7 my battery life with Franco pre-r1.
I agree that mpdecision really does drain battery a lot. I have mine OVERCLOCKED to 2.88 ghz with sensei kernel and intelliplug. And I am still getting way better battery life than stock. Just flash this kernel with intelliplug and there goes your battery issues. And you can also adjust your screen colors.
rmx36 said:
I agree that mpdecision really does drain battery a lot. I have mine OVERCLOCKED to 2.88 ghz with sensei kernel and intelliplug. And I am still getting way better battery life than stock. Just flash this kernel with intelliplug and there goes your battery issues. And you can also adjust your screen colors.
Click to expand...
Click to collapse
For more elaboration on mpdecision,
All Qualcomm based phones have Qualcomm prorprietary userspace binary called "mpdecision" aka m(ake)p(oor)decision. Instead of letting the kernel itself to decide what frequencies and how many cores to run, this "mpdecsion" binary polls the kernel run queue statistics and decides for the whole system the "optimal" frequency and the "optimal" number of cores to use. The concept is fine, except the decision making is done in userspace and it's 100% closed source so there's no way to tweak it and there's a latency (because all userspace binaries needs to "poll" the kernel for the latest information which is slightly delayed). - faux123
Click to expand...
Click to collapse
In other words, mpdecision makes your phone sit at 1.5GHz for doing the most simplest tasks, even composing a email it'll bring your frequency to be at 1.5GHz.
Download CPU Spy and use your phone, then look at CPU Spy and you'll see how much time is spent in that frequency. Then flash another kernel that does not use mpdecision then you'll see the difference, the phone sits at frequencies that makes sense for the load that is on the device.
The alternative solutions would be, Franco's Hotplugging Algorithm or intelliplug by Faux.
Battery life is very subjective.
I am still 100% stock, encrypted, auto brightness and get over 6 hours SOT every charge. Mainly WiFi, some LTE. No gaming.
I will root and switch to another kernel when I have time and see the difference. I would expect more battery.
However if you are only at 2.5 hours SOT on a full charge, I wouldn't expect it to double just by changing kernels.
JasonJoel said:
Battery life is very subjective.
I am still 100% stock, encrypted, auto brightness and get over 6 hours SOT every charge. Mainly WiFi, some LTE. No gaming.
I will root and switch to another kernel when I have time and see the difference. I would expect more battery.
However if you are only at 2.5 hours SOT on a full charge, I wouldn't expect it to double just by changing kernels.
Click to expand...
Click to collapse
Thats so impossible. I've switched to 2G only but i run on Wifi all time and yet 1 day standby and 3.5hrs SOT.
zephiK said:
1. You can change your RGB using any kernel with support to it. Almost every single kernel have support to RGB LCD KCAL. Use a app such as Trickster to modify the RGB once you flashed a kernel of your choosing.
2. Battery life is subjective to how you use your device. Just because someone was able to achieve 5 hours+ SOT doesn't mean you will either because there are way too many factors that play into effect such as: cellular signal strength, wakelocks, apps installed, etc. If you want to maximize your battery life, look into underclocking the CPU/GPU frequency and flash a custom kernel (e.g. Franco) that removes mpdecision. Mpdecision is a huge battery drain and the frequencies that it selects is completely random and unnecessary in my opinion.
http://forum.xda-developers.com/showpost.php?p=57808725&postcount=7 my battery life with Franco pre-r1.
Click to expand...
Click to collapse
Impressive! I'm trying ElementalX kernel right now. Is it safe to switch-off MP-decision on that using trickster or shall I go with franco blind folded.
taranfx said:
Thats so impossible. I've switched to 2G only but i run on Wifi all time and yet 1 day standby and 3.5hrs SOT.
Click to expand...
Click to collapse
Well, not impossible as it has been that way on my phone since day 1.
But i agree that it is really odd how some people are getting 3 hours and others getting 6.
I had the opposite on my Note 4 though. Everyone got 6 and I got 4. So who knows?
taranfx said:
Impressive! I'm trying ElementalX kernel right now. Is it safe to switch-off MP-decision on that using trickster or shall I go with franco blind folded.
Click to expand...
Click to collapse
You only want to disable MPDecision if theres a alternative. For Franco, mpdecision is 100% removed so you don't need to disable anything.
I don't know ElementalX so I can't say, ask in their thread. If you use Franco, everything is done for you and you don't need to do anything on your part.
My battery life with LK is pretty good as well! I was able to tether for 10 hours straight and still had 22% left after sleeping ~8 hours.

CPU throttle

So I've gotten my standby time to be pretty good but under moderate use, the device is getting warm and chewing through battery. I.e 4hrs off charger, 40 minutes of screen and only 71% left. I'm stock rooted and removed bloat. Even had stuff greenified (just uninstalled to test now). Is there anything I can do without tripping Knox to slow down the CPU a little? The native power save mode is all or nothing now - they used to let you control which features were enabled on older devices
km8j said:
So I've gotten my standby time to be pretty good but under moderate use, the device is getting warm and chewing through battery. I.e 4hrs off charger, 40 minutes of screen and only 71% left. I'm stock rooted and removed bloat. Even had stuff greenified (just uninstalled to test now). Is there anything I can do without tripping Knox to slow down the CPU a little? The native power save mode is all or nothing now - they used to let you control which features were enabled on older devices
Click to expand...
Click to collapse
If your rooted, download a program called Trickster Mod. (All credit to the dev) It allows you to underclock the CPU. Stock value is set at 1.5Ghz. WIthout an overclocked kernel, that value cannot change. However, underclocking is available. And since this device is a true octa-core dropping it to 1.2 Ghz shouldn't be a problem. Also you can change your governor to a conservative one. Stock is ondemand. Conservative and Performance are able to be selected. Changing your TCP congestion to cubic instead of the stock bic, in my experience, gives you a bit better battery life as well. Hope this helps.
Thanks!
The app doesn't say it supports s6, does it definitely work?
You can try kernel tweaker which is also availble on the play store. By the way we do have a Q&A forum so your questions would be better suited over there.
I can't find anything called "kernel tweaker" exactly... Also my question was about apps and this is app subforum. Sorry if that isn't correct

High CPU usage and micro shuttering

So I recently installed latest weekly RR again hoping it will be fixed of micro shuttering but nope, so here's what happening 1st cpu usage is 100% temperature are reaching 82°c, 2nd the micro shuttering is still there so I opened matlog and here's what I got I hope you guys can help me :silly: thank you very much :highfive:
https://mega.nz/#!fp0nWYga!Z9Sgco0jmB00E0TXHkbxbjIOMjMoy1QV-hk2t-x1gb8
Mataujo said:
So I recently installed latest weekly RR again hoping it will be fixed of micro shuttering but nope, so here's what happening 1st cpu usage is 100% temperature are reaching 82°c, 2nd the micro shuttering is still there so I opened matlog and here's what I got I hope you guys can help me :silly: thank you very much :highfive:
https://mega.nz/#!fp0nWYga!Z9Sgco0jmB00E0TXHkbxbjIOMjMoy1QV-hk2t-x1gb8
Click to expand...
Click to collapse
Check your CPU governor. If it's interactive, change it to anything else. The stuttering is caused by thermal throttling. Interactive governor has a bug that causes cpu to max out all the time.
xxBrun0xx said:
Check your CPU governor. If it's interactive, change it to anything else. The stuttering is caused by thermal throttling. Interactive governor has a bug that causes cpu to max out all the time.
Click to expand...
Click to collapse
I'm using the default settings, it's schedutil
This is really killing me.
I deleted the thermal files to as mentioned in the kernel thread
Core control is enabled rest is disabled.
Just see the temperatures!!!
I had the same problems and followed the recommended settings in the kernel thread.
No weird things happening when looking at a task manager. It just ran ridiculously hot all the time. Playing downloaded music through Play Music for example would send the CPU temp to ~90 degrees C.
Back to stock kernel on lineage OS and cool as a cucumber.
Mataujo said:
This is really killing me.
I deleted the thermal files to as mentioned in the kernel thread
Core control is enabled rest is disabled.
Just see the temperatures!!!
Click to expand...
Click to collapse
That's the opposite of what you want. Disable core control, enable msm_thermal. The phone gets warm, but never hot. Also, underclocking dragonxia kernel is VERY important.
xxBrun0xx said:
That's the opposite of what you want. Disable core control, enable msm_thermal. The phone gets warm, but never hot. Also, underclocking dragonxia kernel is VERY important.
Click to expand...
Click to collapse
I don't see any option for msm_thermal where do I find it?
xxBrun0xx said:
That's the opposite of what you want. Disable core control, enable msm_thermal. The phone gets warm, but never hot. Also, underclocking dragonxia kernel is VERY important.
Click to expand...
Click to collapse
Actually in the dragonxia kernel thread, it says to keep core control enabled.
FusionGhana on AKT app
I was experiencing similar issues on RR. Tried all different kinds of options. Thermal files removed (ofcourse that might have attributed to the hotness of the device since CPU was going crazy). Wanted to follow the instructions on another thread that talked about Insane speeds but couldn't since it talked about setting onDemand Governor and somehow my device does not have that.
Then I started playing around with the Balanced profiles using Advanced Kernel Tweaks app. I am currently on FusionGhana (i think that's the name), and my device is running smoooth. No lags, the device is cool most of the times.
Try it out, see if that works for you
psychedelicNerd said:
I was experiencing similar issues on RR. Tried all different kinds of options. Thermal files removed (ofcourse that might have attributed to the hotness of the device since CPU was going crazy). Wanted to follow the instructions on another thread that talked about Insane speeds but couldn't since it talked about setting onDemand Governor and somehow my device does not have that.
Then I started playing around with the Balanced profiles using Advanced Kernel Tweaks app. I am currently on FusionGhana (i think that's the name), and my device is running smoooth. No lags, the device is cool most of the times.
Try it out, see if that works for you
Click to expand...
Click to collapse
Just be careful not to do this on an EAS kernel. Last I knew there was a bug with the interactive governor that forced CPU to max all cores all the time when interactive is set. Current version of Dragonxia is an EAS kernel and most of the governors in AKT are modified interactive governors.
That being said, I think using less aggressive governors is a great way to reduce the heat. This CPU is very powerful even at lower clock speeds, there's rarely much need to ramp beyond 50% utilization for any real length of time unless you're gaming.
Hmmm. didn't know about this. I am on DragonXia EAS. Not that I know what EAS stands for, but I will try moving to a non-EAS kernel and see if i get any more improvements. Thanks for the info.

Categories

Resources