Took me 2 hours to figure out why my phone was lagging out even more than it was prior to root. Slow dialing, lagged texting, lagged screen on, etc. Once I reverted back to "moto_hotplug" governor in SetCPU, everything is perfect.
Sent from my DROID3 using Tapatalk
That's strange my default setting in setcpu was ondemand and all is well
I was experiencing the same issue every time I turned my screen off, except my phone would completely freeze and my only option was pulling the battery. Finally I discovered it was the one profile in SetCpu that was set to clock down and scale to ondemand when the screen was off.
Can anyone confirm that clocking down with profiles works as long as the scaling is ondemand?
djdmbrwsk said:
Can anyone confirm that clocking down with profiles works as long as the scaling is ondemand?
Click to expand...
Click to collapse
I tried that out and it doesn't seem to work even if I leave the scaling as moto_hotplug. It takes a few minutes, but it definitely completely freezes up.
djdmbrwsk said:
I tried that out and it doesn't seem to work even if I leave the scaling as moto_hotplug. It takes a few minutes, but it definitely completely freezes up.
Click to expand...
Click to collapse
Same here, but others are still reporting that they are underclocking with SetCPU just fine. I'm leaving it alone for now, since I'd rather overclock to be completely honest with you. My battery life isn't a problem at all. 17-21 hours on average unplugged before 10%. Perfectly fine for me.
Lyxdeslic said:
Took me 2 hours to figure out why my phone was lagging out even more than it was prior to root. Slow dialing, lagged texting, lagged screen on, etc. Once I reverted back to "moto_hotplug" governor in SetCPU, everything is perfect.
Sent from my DROID3 using Tapatalk
Click to expand...
Click to collapse
I can second this issue. I played around with a bunch of different settings and found it was most stable when the max was no lower than 800, but it still froze on occasion even with hotplug selected. Overall it seems SetCPU is not really compatible with the Droid 3.
I switched mine to Ondemand as well and it was quickly obvious the phone didn't like it. Quadrant scores dropped to 1000-1500 range. Setting back to moto_hotplug and Quadrant scores back over 2200 and everything is running smooth.
I learned this the hard way as well. I had it changed to the settings I used on my thunderbolt back then, using ondemand screen off 300 max 300 min. When Handcent received a message, texting would lag, etc and once I changed back to moto_hotplug everything was great again!
Sent from my DROID3 using Tapatalk
im just wondering how much does the governerr effect battary life? i changed from ondemand to smartass2 and im not sure i see any diffrent...
and im scheduales which one is best for multitasking and which is for when playing games?
and should i change the governerr setting?
i also read that sleep_ideal_frequency should be 200 and not 100 beacuse 100 wastes more or something like that, is that true?
using galaxy i9000 semaphore kernal jb
bump
I use Performance governor all the time for 3 months now, battery life is same as on demand, smartass v2 or any other governor, except my phone lags much rarely than on any other govenor. For those that dont know, CPU of PC, your phone, calculator or anything else always works at 100% of its frequency even it has no work to do (Let's take for example your PC, even cpu usage is 5%, CPU still works at full frequency, the same works for your phone), so to me there is no point of any other governor except for Performance. If you have problem with battery life, it's mostly your screen. When I drain out my battery, my battery mostly get drained by screen (70-90%), I use about 0-30% of brightness always. Screen of 60-100% brightness will probably drain your phone's battery in 2-3 hours.
Lavoslav said:
I use Performance governor all the time for 3 months now, battery life is same as on demand, smartass v2 or any other governor, except my phone lags much rarely than on any other govenor. For those that dont know, CPU of PC, your phone, calculator or anything else always works at 100% of its frequency even it has no work to do (Let's take for example your PC, even cpu usage is 5%, CPU still works at full frequency, the same works for your phone), so to me there is no point of any other governor except for Performance. If you have problem with battery life, it's mostly your screen. When I drain out my battery, my battery mostly get drained by screen (70-90%), I use about 0-30% of brightness always. Screen of 60-100% brightness will probably drain your phone's battery in 2-3 hours.
Click to expand...
Click to collapse
This is so wrong its a pain to read.:banghead: Why do we have the max and min frequency options in the semaphore app? Why do we have "Max Performance" and "Max Battery" power settings on laptops?
Sent from my GT-I9000
There was a thread some while ago that concluded in OnDemand and Performance being to two to give longest battery life and best performance.
I don't have specifics or even a link, but the thread was about schedulers and governors and which went together for best performance and battery life. I'm sure it's google'able
Sent from my GT-I9000 using xda premium
i found that thread but im just wondering how much battary life is wasted if i prefer preformence?
lets say i use smarassv2 since its faster will my phone drain lets say insted 20%\hour - 22%\hour? or is it more then that?
itzikd1 said:
i found that thread but im just wondering how much battary life is wasted if i prefer preformence?
lets say i use smarassv2 since its faster will my phone drain lets say insted 20%\hour - 22%\hour? or is it more then that?
Click to expand...
Click to collapse
maybe you can try and tell us
There should be a significant impact regarding battery life when using Performance for example. But it also depends on what you are used to. If you play games all the time or do heavy tasks, the governor will kick the CPU to 100% all the time anyway. But if you mostly surf on the Internet or read texts there's no need to let the CPU go rampage.
Oh and Btw: Modern CPUs in notebooks or computers in general clock themselves down as well when they're idle.
Sent from my Gameboy Color
BlueFlame4 said:
There should be a significant impact regarding battery life when using Performance for example. But it also depends on what you are used to. If you play games all the time or do heavy tasks, the governor will kick the CPU to 100% all the time anyway. But if you mostly surf on the Internet or read texts there's no need to let the CPU go rampage.
Oh and Btw: Modern CPUs in notebooks or computers in general clock themselves down as well when they're idle.
Sent from my Gameboy Color
Click to expand...
Click to collapse
I do use internet mostly so what will be the most effective governerr any idea?
itzikd1 said:
I do use internet mostly so what will be the most effective governerr any idea?
Click to expand...
Click to collapse
Try OnDemand or SmartAssV2.
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
Anything is valid. Preferentially without root.
[/COLOR]
wquayson said:
Anything is valid. Preferentially without root.
Click to expand...
Click to collapse
What is your current battery performance? Is your device affected with the fingerprint sensor bug that locks the CPU at highest frequency?
kandarpjha said:
[/COLOR]
What is your current battery performance? Is your device affected with the fingerprint sensor bug that locks the CPU at highest frequency?
Click to expand...
Click to collapse
About 6-8 hours in moderate-high use, I guess. I don't think it is, how can i know?
wquayson said:
About 6-8 hours in moderate-high use, I guess. I don't think it is, how can i know?
Click to expand...
Click to collapse
Install a hardware monitor app like CPU-z or DevCheck. If you CPU frequency is not coming down from the highest value (for 4 small cores: 1843 MHz and for 4 big cores: 2208 MHz), you are most probably affected by the bug. You can disable fingerprint sensor to conserve battery in that case.
wquayson said:
About 6-8 hours in moderate-high use, I guess. I don't think it is, how can i know?
Click to expand...
Click to collapse
If you are talking about SOT, it's quite normal.
You can't really improve SOT.
It depends mainly on two things : Brightness and Kernel settings. Kernel you cant tamper with without rooting/unlockin your phone, so the best improvement can be achieved via auto brighness.
If you are losing too much battery while phone is idle/screen locked, here are some steps you can follow:
Limit background use of an application from Settings/Battery (Even google play services, notifications still come through)
Disable background data use of apps from Data Usage (Especially facebook/messenger ones, notifications still come through via GCM - use to your own likings though)
Clear Google Play Services cache, as it somehows causes battery drain
Disable location and google location tracking
Disable "Data always on" at developer settings. No point of keeping an active connection while on WiFi
Change network to 3G Only, if your 4G coverage sucks, so it drains all your battery
kandarpjha said:
Install a hardware monitor app like CPU-z or DevCheck. If you CPU frequency is not coming down from the highest value (for 4 small cores: 1843 MHz and for 4 big cores: 2208 MHz), you are most probably affected by the bug. You can disable fingerprint sensor to conserve battery in that case.
Click to expand...
Click to collapse
When i quit the app and come back, the frequencys are at the maximum value for a milisecond then goes to 1401MHz(CPU 0-3) and 1113MHz(CPU 4-7). So, I don't think I have that bug. What do you say?
Reptant said:
If you are talking about SOT, it's quite normal.
You can't really improve SOT.
It depends mainly on two things : Brightness and Kernel settings. Kernel you cant tamper with without rooting/unlockin your phone, so the best improvement can be achieved via auto brighness.
If you are losing too much battery while phone is idle/screen locked, here are some steps you can follow:
Limit background use of an application from Settings/Battery (Even google play services, notifications still come through)
Disable background data use of apps from Data Usage (Especially facebook/messenger ones, notifications still come through via GCM - use to your own likings though)
Clear Google Play Services cache, as it somehows causes battery drain
Disable location and google location tracking
Disable "Data always on" at developer settings. No point of keeping an active connection while on WiFi
Change network to 3G Only, if your 4G coverage sucks, so it drains all your battery
Click to expand...
Click to collapse
Auto brightness? Really? I thought that was a battery killer. My brightness is in about 25% most of the time, so, I don't think that is the bigger problem, do you?
Well, thanks both of you guys for the help, and I will follow your instructions(but not the auto brightness one, I don't really like it), Reptant. I will try to remember and report the results at the end of the day.
wquayson said:
Auto brightness? Really? I thought that was a battery killer. My brightness is in about 25% most of the time, so, I don't think that is the bigger problem, do you?
Well, thanks both of you guys for the help, and I will follow your instructions(but not the auto brightness one, I don't really like it), Reptant. I will try to remember and report the results at the end of the day.
Click to expand...
Click to collapse
Yes, that's right. Disable auto brightness, and keep the brightness at around 10%. It is more than sufficient in indoor conditions. Further, disable high accuracy location settings and set it to battery saving or off. You should also turn off WiFi and Bluetooth scanning in location settings.
I personally use a rather far reaching way of force stopping every social media and other news apps after using them (I have never observed any 'misbehavior' as they warn, but it saves a great deal of battery life.). As you can see in the screenshot the battery has lost 7% of charge in 2 hours and it still expects to last for 1 full day.
wquayson said:
When i quit the app and come back, the frequencys are at the maximum value for a milisecond then goes to 1401MHz(CPU 0-3) and 1113MHz(CPU 4-7). So, I don't think I have that bug. What do you say?
Click to expand...
Click to collapse
Min freq should be 633 MHz for the little cluster,it a bug with the 2nd October update, many users are affected,and so i!
https://forum.xda-developers.com/mi-a2/help/frequency-sd660-stuck-maximum-t3832366
Hello, any better result if phone is rooted ? Or any other solution? Thanks a lot.
buythismobile said:
Hello, any better result if phone is rooted ? Or any other solution? Thanks a lot.
Click to expand...
Click to collapse
The suggestions from Reptant above are still valid.
Other than that:
1. Greenify. Set non system apps to shallow hibernation. Try Amplify if you dare.
2. Disable ads. The image/video ads may not occupy a lot of your screen, but they use much more data than text. disabling those ads will reduce the amount of data that the modem needs to download, hence reduce battery consumption. this will have big impact if you surf the web a lot using phone.
3. Change CPU governor to powersave and/or disable some CPUs, reduce GPU max clock speed (you may not like this since it will make the phone laggy)