Context: You want to get some useful information about your device and store it in Tasker to further usage. Here is a guide showing some useful commands you can use from Tasker. Remember you must check root to make them work.
Requirements :Root
I. Battery Status: Display your battery level, health and temperature.
Task
1. Run Shell> Command: "dumpsys battery | grep health" Store Output in: %Dump2. Gets and stores the specific information in a variable.
2.Variable split: %Dump2 Splitter : Avoids repeating the word health
3.Run Shell > Command : "dumpsys battery | grep temperature" Store Output in : %Dump3
4. Variable Split: %Dump3 Splitter :
5. Variable Section: Name: %Dump3 From 2 Lenght 2 Avoids the incorrect format in Celsius
Now you have the info about your battery. If you want your device to say it to you proceed as following. The If conditions is necessary because the health is given in numbers from 1 to 5.
6.If %Dump22 Matches Regex 1
7. Say The battery level is %BATT and the health is excellent. The temperature now is %Dump32 degrees.
8. End if
9. .If %Dump22 Matches Regex 2
10. Say The battery level is %BATT and the health is very good. The temperature now is %Dump32 degrees.
11. End if
12. If %Dump22 Matches Regex 3
13.Say The battery level is %BATT and the health is good. The temperature now is %Dump32 degrees.
14. End if
15. If %Dump22 Matches Regex 4
16. . If The battery level is %BATT and the health is weak. The temperature now is %Dump32 degrees.
17. End if
18. If %Dump22 Matches Regex 5
19. Say The battery level is %BATT and the health is critical. The temperature now is %Dump32 degrees.
20. End if
As you created global variables, you can do whatever you want with them in Tasker, for an example create a widget.
In a next thread I will show you how to get info about the time your device is on since boot and about your storage.
This is a good method for pulling battery information if you're rooted. If you're not rooted, you can read the files in /sys/class/power_supply/battery to get the same information. Use current_now for the current, voltage_now for the voltage, temp for temperature.
MishaalRahman said:
This is a good method for pulling battery information if you're rooted. If you're not rooted, you can read the files in /sys/class/power_supply/battery to get the same information. Use current_now for the current, voltage_now for the voltage, temp for temperature.
Click to expand...
Click to collapse
Good point. As it is getting more and more difficult to root a device, it is important to have other options. The main purpose of the guide is nevertheless make people more familiar with some commands that you can also use on the Android Terminal Emulator.
Nice. Finally found out how to use battery temp. and level as variables.
Related
My phone suffers from frequent BSODs when charging overnight (battery extraction required to make it restart). Instead of keeping it completely awake with 'Stay awake' to reduce the frequency of this nasty event, you could use the app Tasker and a simple python script (requires the installation of SL4A, Scripting Layer 4 Android) to acquire a partial wake lock, keeping the CPU alive even with screen off.
How to use SL4A with Tasker
The tasker screenshot
xml task description
The python script
If the tip is effective for you, please thanks
CpuFloat
Uses a floating window or the status bar to show
# the cpu frequencies
# the cpu temperature if (available)
# the text will turn red when the cpu temperature rises above the throttle temperature. You can set custom throttle temperature in preferences.
# the gpu frequency
# Gpu load; not normalised
# the gpu temperature if (available)
# the text will turn red when the gpu temperature rises above the throttle temperature.
# awake time; the time the phone has been awake since starting the app
# deep sleep time; the time the phone has been asleep since starting the app
# battery current
# battery current
# current upload and download speed
In preferences you can choose
# floating window layout; vertical or horizontal layout
# to show the window in the status bar instead of a floating window
# the categories to monitor; all, cpu, gpu, time, network
# which temperature sensor to use for cpu and gpu temperature
# to show the temperature in Fahrenheit instead of Celsius
# cpu throttle point; cpu temperature when the text should turn red
The app uses following permissions:
"android.permission.SYSTEM_ALERT_WINDOW" Needed for floating window, draw over other windows.
"android.permission.READ_EXTERNAL_STORAGE" Read data to show e.g. Cpu frequency, temperature etc.
"android.permission.VIBRATE"
Credits to:
CM Calculator apk for user interface logic
@m11kkaa for temperature file paths and thread http://forum.xda-developers.com/xposed/modules/mod-cputemp-statusbar-t2494170
@existz for awake and deep sleep time method http://forum.xda-developers.com/google-nexus-5/themes-apps/app-cpu-spy-material-v1-0-t2948627
@Grarak for GPU frequency file paths http://forum.xda-developers.com/android/apps-games/app-kernel-adiutor-t2986129
consp1racy for SeekBarPreference https://github.com/consp1racy/android-support-preference
The Tester for catching exceptions and throwing ideas
For automatic updates:
Request
If you´d like to use the app in your native language, you can!
How?
Download the string resource file, copy it and the translate the underlined part, for example
<string name="settings">Settings</string>
becomes
<string name="settings">Instellingen</string>
and post it in this thread.
Thanks!
ChangeLog:
March 17
-startup bug, thanks to Bryan
-GPU frequency on some devices
+battery temperature
Older changelogs:
September 26
- bugs
+ battery current correction
+ clear data dialog in case of fatal crash
September 24
+ battery current monitor
+ notification; enable if CpuFloat suddenly disappears
+ set monitor defaults
+use android M (6) permissions
+important notice about app permissions for android M (6) and up
+transparent background
+GPU trippoint
+ changelog
- some bugs
June 14
Fixed crash
Improve right to left layout
June 12
Added
#Text size
#Show window on the navigation bar
#Update interval (100ms - 3000ms)
#Number of CPUs to monitor
#First time helpful animation
#About screen
#Now on Google Play Store
Fixes and improvements
#Don´t update when the screen is off
#Don´t kill service when changing the window layout
#Language in settings
#Support more GPUs
#Use SeekBarPreferences in settings
November 12
# added some animations
# 'material' window look
# layout changes in case of more than 7 cpu cores
# broadcast listener for landscape/ portrait change
in preferences
# turn on/off vibration
# restore default values
November 3
# user interface logic
November 1
# fixed preference bugs
October 31
# manually set which temperature sensor to use for the cpu and gpu temperature
October 25
# hopefully fixed force close on start
October 23
# fix bug, window not showing on start
# custom cpu temperature trippoint in preferences
October 19
# used some icons instead of text
# option to show window in status bar
October 17
# started to make it work on other phones
# cpu and gpu temperature file info in preferences
October 14
# more layout options
# bugs and performance fixes
October 11
# no more StandOutWindow library
# no notification
# improved long press detection
October 4
# monitor up and download speed
# option to show the temperature in Fahrenheit
October 1
# warning in case the temperature reaches the throttle temperature of cpu or gpu
# tap app window to close
# long press app window for preferences
Preferences:
# choose horizontal / vertical layout
# choose what to monitor
September 27
# rewritten to make it easier to use on other phones
# new app icon
# smaller window
//TODO make preferences
Very nice app.
Thanks dude
That's a nice idea. The app is working without problems as far as I can tell. Great job man!
Sent from my OPO running Sultanxda's CM 12.1
Amazing app! Thanks man!
Nice app
Nice app - similar to the one developed by Chainfire (called Perfmon) but this one shows you the awake time and the temps.
Thank you for this
update:
# rewritten to make it easier to use on other phones
# new app icon
# smaller window
Nice app. Would be nice to have a widget like that.
Sent from my Oneplus One using XDA Free mobile app
Update
# warning in case the temperature reaches the throttle temperature of cpu or gpu
# tap app window to close
# long press app window for preferences
Preferences:
# choose horizontal / vertical layout
# choose what to monitor
Bugfix
Temperature warning not showing in horizontal layout
Thank you for this! Really helpful for monitoring governor and hotplug.
Update
Rewritten
Much smaller now
# no notification
# no more StandOutWindow library
# improved long press detection
Because of a change in package name,
please delete previous version, else you'll end up with 2
waterdaan said:
Update
Rewritten
Much smaller now
# no notification
# no more StandOutWindow library
# improved long press detection
Because of a change in package name,
please delete previous version, else you'll end up with 2
Click to expand...
Click to collapse
Very nice.
Thank you
arifqur said:
Very nice.
Thank you
Click to expand...
Click to collapse
Thanks for the positive reactions
Update
# more layout options
# bugs and performance fixes
Update
# started to make it work on other phones
# cpu and gpu temperature file info in preferences
Request
I'm trying to get the app to work on other phones, so if you have another phone, please test what's working.
If there's no cpu temperature, that probably means that the app can't find the temperature files. These are not the same on every phone.
If the phone is rooted, you can help me by copying and pasting below code in command line, with for example this app https://play.google.com/store/apps/details?id=jackpal.androidterm
And posting the outcome here, so I can add the missing file.
Code:
su
find /sys -type f -name *temp* -print0|while read -d $'\0' f;
do printf "$f= "&&cat "$f";done;
Thanks!
Gpu temperature is a bit more difficult, because you need to find out which temperature sensor is for the gpu, I found that information for the oneplus in
/etc/thermal-engine-8974.conf
Reported working on:
OnePlus fully working
Moto X gpu temperature not working
Samsung S4 gpu temperature not working
Thank you!!
Update
# used some icons instead of text
# option to show window in status bar
Edit
The app is fully working on the Sony Z3 Compact, it even uses the same files for cpu temperature and gpu temperature, maybe because it also has a snapdragon 801, but I'm not sure about that.
I must be missing something but how do I reopen the window after having tapped on it to close it?
Because opening the app from the drawer takes me to the preferences screen.
Killerkip said:
I must be missing something but how do i reopen the window after having tapped on it to close it?
because opening the app from the drawer takes me to the preferences screen.
Click to expand...
Click to collapse
You're right, that's not very clear, I'll see if I can change that.
For now just change something in the preference screen and a new window will open.
Thank you for your reaction
Update
# fix bug, window not showing on start @Killerkip
# custom cpu temperature trippoint in preferences
Now I haven't seen this anywhere while trying to find a fix so I may possibly be sharing a new idea.
I know that we already have Greenify and such apps to extend our phones battery life, but what I find is that in some way or another they reduce the overall performance of it.
My idea is to create a Tasker profile where the phone runs at normal performance during screen on but recognises when the display is locked and reduces the CPU speed to its minimum, because surely being at anything more is a waste of CPU energy?
I have created a profile that's activated by a display off event, followed by a System >> CPU task called "Lower CPU" that reduces the max frequency to the value of min frequency.
When activated it does lower the speed while the screen is off, but once I turn the screen back on it takes a reboot to get the cores speed to increase again even if I turn off the Tasker profile.
It won't allow me to create an exit task for an event context so do I need to create a new profile to raise the CPU speed in an event of a screen on? Or is there a way to use a plugin like Trickster Mod to lower and raise it instead?
Apologies for it being so long, I'm not sure if I'm making it more complicated? But help please!
Thank you!
P.s - the images are screenshots of CPU-Z 1. Before locking the screen. 2. Immediately after unlocking the phone 3. About 2 minutes after unlocking the phone and it just doesn't return to normal
AJHylton said:
Now I haven't seen this anywhere while trying to find a fix so I may possibly be sharing a new idea.
I know that we already have Greenify and such apps to extend our phones battery life, but what I find is that in some way or another they reduce the overall performance of it.
My idea is to create a Tasker profile where the phone runs at normal performance during screen on but recognises when the display is locked and reduces the CPU speed to its minimum, because surely being at anything more is a waste of CPU energy?
I have created a profile that's activated by a display off event, followed by a System >> CPU task called "Lower CPU" that reduces the max frequency to the value of min frequency.
When activated it does lower the speed while the screen is off, but once I turn the screen back on it takes a reboot to get the cores speed to increase again even if I turn off the Tasker profile.
It won't allow me to create an exit task for an event context so do I need to create a new profile to raise the CPU speed in an event of a screen on? Or is there a way to use a plugin like Trickster Mod to lower and raise it instead?
Apologies for it being so long, I'm not sure if I'm making it more complicated? But help please!
Thank you!
P.s - the images are screenshots of CPU-Z 1. Before locking the screen. 2. Immediately after unlocking the phone 3. About 2 minutes after unlocking the phone and it just doesn't return to normal
Click to expand...
Click to collapse
I understand what you're getting at, but it's really not necessary to do such a thing. CPU cores clock down and all cores except for core0 usually shut down when the phone goes into sleep mode, so the amount of battery you're saving is negligible doing this. If your phone is running hot while the screen is off, then you likely have wakelock issues and that's something separate you need to tackle.
MishaalRahman said:
I understand what you're getting at, but it's really not necessary to do such a thing. CPU cores clock down and all cores except for core0 usually shut down when the phone goes into sleep mode, so the amount of battery you're saving is negligible doing this. If your phone is running hot while the screen is off, then you likely have wakelock issues and that's something separate you need to tackle.
Click to expand...
Click to collapse
Ohh I see, thank you for explaining. I would have thought that this would be implemented somewhere as otherwise it would have been a clear battery drain but I thought I'd double check lol
Doze Mode
What version of Android are you running? If you're on Marshmallow, adjusting the CPU may not be necessary as it has Doze mode and using either Naptime or Doze Settings Editor and adjusting the settings can defintely increase battery life when the device is sleeping.
If not, I suggest using PowerNap with Xposed and Greenify.
In fact, Greenify has Tasker integration so you can set it to hibernate apps upon screen off situations.
Of course, all the apps I listed need root access...
Another helpful resource to help with power saving can be found at http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
You will have to adjust it based on your device and kernel of course, but I've experinced great power savings using a combination all I've mentioned
Ozonethegreat said:
What version of Android are you running? If you're on Marshmallow, adjusting the CPU may not be necessary as it has Doze mode and using either Naptime or Doze Settings Editor and adjusting the settings can defintely increase battery life when the device is sleeping.
If not, I suggest using PowerNap with Xposed and Greenify.
In fact, Greenify has Tasker integration so you can set it to hibernate apps upon screen off situations.
Of course, all the apps I listed need root access...
Another helpful resource to help with power saving can be found at http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
You will have to adjust it based on your device and kernel of course, but I've experinced great power savings using a combination all I've mentioned
Click to expand...
Click to collapse
Alright thank you for that, I'll take a look at those. I'm currently using a Oneplus Two on OxygenOS 2.2 which is based on KitKat. I have been looking at Xposed modules as that's what really made me root this phone but apparently I need to go through steps to make SeLinux permissive because at the moment nothing from Xposed works. And considering yesterday I spent hours unbricking this phone, I'm going to stop fiddling with it for a little while :laugh:
AJHylton said:
Alright thank you for that, I'll take a look at those. I'm currently using a Oneplus Two on OxygenOS 2.2 which is based on KitKat. I have been looking at Xposed modules as that's what really made me root this phone but apparently I need to go through steps to make SeLinux permissive because at the moment nothing from Xposed works. And considering yesterday I spent hours unbricking this phone, I'm going to stop fiddling with it for a little while :laugh:
Click to expand...
Click to collapse
You can set SeLinux to permissive using the code below in your terminal app or adb shell (found here):
Code:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "setenforce 0" > /system/su.d/permissive.sh
echo "0" > /sys/fs/selinux/enforce
chmod 755 /system/su.d/permissive.sh
Or if that's too much for ya, SeLinuxModeChanger works as well. Keep in mind that Google marks this as harmful but that's only because they don't want to changing SeLinux.
Ozonethegreat said:
You can set SeLinux to permissive using the code below in your terminal app or adb shell (found here):
Code:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "setenforce 0" > /system/su.d/permissive.sh
echo "0" > /sys/fs/selinux/enforce
chmod 755 /system/su.d/permissive.sh
Or if that's too much for ya, SeLinuxModeChanger works as well. Keep in mind that Google marks this as harmful but that's only because they don't want to changing SeLinux.
Click to expand...
Click to collapse
I have actually tried the SELinuxModeChanger to change it and when I run 'getenforce' in Terminal it says permissive but Xposed still doesn't work even then. The steps I was told to try are http://forum.xda-developers.com/oneplus-2/general/guide-disable-selinux-to-allow-xposed-t3331105 which seems a little more intense lol.
I'm going to try the code now and see if that works, if it doesn't is it likely that that's not what's stopping Xposed from working?
Update: I tried the code and running getenforce on the terminal says permissive but the Xposed modules still dont have any effect when activated
AJHylton said:
I have actually tried the SELinuxModeChanger to change it and when I run 'getenforce' in Terminal it says permissive but Xposed still doesn't work even then. The steps I was told to try are http://forum.xda-developers.com/oneplus-2/general/guide-disable-selinux-to-allow-xposed-t3331105 which seems a little more intense lol.
I'm going to try the code now and see if that works, if it doesn't is it likely that that's not what's stopping Xposed from working?
Update: I tried the code and running getenforce on the terminal says permissive but the Xposed modules still dont have any effect when activated
Click to expand...
Click to collapse
Strange. Both worked for me and I've had no problems. Might be the rom you're running. I'm not sure.
this entire thing could be achieved with a init.d script which I used to use back in 2012.
Screen off- powersave governor...
screenon- normal governor
Hey guys and girls,
I don´t have time to maintain 2 threads. Look in the Pixel XL forums.
Link is here: https://forum.xda-developers.com/pi...kernel-0-1-t3554330/post70974321#post70974321
So this post will be dedicated to information about EAS in general.
here is a good summary which also goes into detail regarding sched and schedutil.
Another amazing write up about alucardsched by a talented new dev @joshuous:
This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.
Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.
Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.
How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.
Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.
Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):
This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.
As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.
AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.
This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.
helix_schedutil explained by @Kyuubi10
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity
Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.
Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:
"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load
"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.
Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.
The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8
If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".
Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.
Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.
Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.
Update to the explanation:
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.
The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)
The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50
Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.
correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.
While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.
As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.
The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.
Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core
here is some Information about pwrutil governor:
This new governor is based on schedutil.
A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.
Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).
UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
how to gather logs:
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Freak07 said:
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Click to expand...
Click to collapse
It worked for me by following instructions in the OP
Followed the instructions from OP, works fine for me!
Thanks for your works, try it out now
ne0ns4l4m4nder said:
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Click to expand...
Click to collapse
Working fine here following OP, thanks for another Kernel brotha!!
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Make sure to use supersu and not the inbuilt lineage superuser.
On rr it should run without an issue. At least it was reported in the xl thread.
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
TheBurgh said:
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
Click to expand...
Click to collapse
yes. Make a backup just in case. And use the latest supersu zip.
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Running great on RR with latest SU ?
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
abunhyan said:
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
Click to expand...
Click to collapse
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Freak07 said:
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Click to expand...
Click to collapse
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
abunhyan said:
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
Click to expand...
Click to collapse
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
hey guys and girls,
I have a new kernel now in testing. If I have no Issues I will post it in a few hours.
I added the possibility to use sdcardfs. big thanks to @DespairFactor here, he provided some help.
you just have to add ro.sys.sdcardfs=true to your build.prop
I tested it for two days now and encountered no issue. Using it may improve I/O performance.
here is some reading, in case you are interested:
https://www.xda-developers.com/divi...les-fuse-replacement-will-reduce-io-overhead/
I also added two new governors developed by @alucard_24, called alucardsched and darknesssched.
They are both based of on EAS. You may use them as an alternative to sched and schedutil.
I think alucardsched is more battery friendly. But I had quite a few stutters with it. Maybe you guys can give feedback on this.
shindiggity said:
Running great on RR with latest SU ?
Click to expand...
Click to collapse
Do you have I/0 options in your kernel manager? And are you using supersu, or the SU baked into the ROM?
Freak07 said:
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
Click to expand...
Click to collapse
by dt2w, he means the stock android implementation where you double tap into the ambient display I think
Hi,
I have found that in my S8+ Oreo none of the apps work which would show me the temperature of my CPU. (maybe Google or Samsung disabled this call from third party apps to ask for this value in Oreo).
BUT I have found that the temperature of the CPU is get logged in at this file:/sys/devices/virtual/sec/sec-pa-thermistor/temperature
So my goal is to have this value permenently shown in the status bar refreshed in every seconds.
Is it possible with Tasker?
Thank you in advance
If you are rooted, yes.
Just use a shell action with use root enabled, cat the file and store the result to a variable then update a notification with the value.
The profile would be a time profile, likely during waking hours and run every x minutes.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers