[TUT] Tasker CPU Control V5|Frequency/Governor Customisable Profiles|SetCPU with OCD
INSTALLATION INSTRUCTIONS ADDED TO POST #2
For those of you not familiar with Tasker, it’s a pretty damn amazing application that works toward fully automating your Android phone.
You can pick up a free trial version from here
This thread is to show, assist and learn (from your input) how to fully utilise the newly introduced CPU controls, with the ultimate goal of preserving battery life without using additional applications such as SetCPU or other power saving scripts. This may look like a beast of a tutorial, but it really doesn't take that long to set up. Honest...
Tasker can be a little daunting at first, but a quick read through the manual
, some tweaking of the profiles and step-throughs on the Tasker wiki
and you’ll be up to speed in no time.
In order to control the CPU, you’ll need a rooted device
and a compatible kernel
. A quick acronym lesson can be found here.
In brief, you require the following Governors (or as many of them as you can get!):
(keeps the CPU frequency always at the maximum. Most power-hungry, most responsive)
(when the CPU is needed, immediately sets it to maximum frequency. Slowly reduces the frequency back down to the minimum as time passes. Responsive, reasonable power usage).
(like Ondemand, but more responsive with slightly more battery usage)
(when the CPU load is needed, slowly increases the frequency to maximum. When the CPU is no longer needed, immediately drops back to the minimum. Less power-usage than Ondemand or Interactive, less responsive).
If there isn’t such a kernel for your device, then I can only suggest you beg and plead with a Dev in your device’s forum!
You can check the following in a file explorer
to see your available frequencies and governors of your current/updated Kernel:
I have a Desire and am running an Oxygen AOSP ROM. I’m therefore using vorkKernel detailed here
. There’s a detailed breakdown in the first post of that thread showing the kind of kernel you’re looking for.
WARNING! DO NOT ENABLE THE PROFILES UNTIL YOU HAVE DOUBLE CHECKED THEY DO NOT EXCEED YOUR PHONE’S CAPABILITIES!! I TAKE NO RESPONIBILITY IF IT SETS ON FIRE! BE CAUTIOUS TO BEGIN WITH. IF THE AVAILABLE FREQUENCIES I DETAIL ARE NOT IN YOUR KERNEL, USE YOUR COMMON SENSE AND APPLY SIMILAR ONES!
Ok? Right, ready to blow your phone up…? Just kidding….! Maybe….
Before you import the profiles, make sure you disable/archive/uninstall SetCPU or any other similar applications or scripts that could take precedent over the CPU control.
You’ll also need a couple of tools to see/hear your progress at a glance/listen:
A widget that shows CPU frequency, with regular refresh intervals would be handy. (If you don’t have one, I suggest you use Process Monitor available for free on the market here . The widget refreshes every 5 seconds from the home-screen).
As they’ll be some ‘screen-off’ states, it's very useful to have a speech engine so you can be told what’s happening without having to turn the screen on and therefore changing the state! (I use Pico TTS)
The application CPU Spy
can be helpful to show you how these profiles combined with the Data Sync profiles will increase the amount of time your device will be spending in 'deep-sleep' and at lower frequencies. Thanks leftAlone
for pointing this app out.
In Tasker, the main triggers for the CPU controls are as follows:
In call (added in V2)
End Call (added in V2)
Initial Boot (added in V2)
Application Launched (added in V2)
In my set-up, these triggers become intertwined as there is often more than one active state to consider. Here we go....
READ THE REST OF THIS POST, BUT INSTALL WITH INSTRUCTIONS FROM POST TWO!
The speech profile (CPU-SayState
) is the first one to download – it’s set up to tell you every 5 minutes (in very clear English), your frequency and governor. Not only will this confirm that your screen-off state is working correctly by just listening, but when you are performing other routine tasks, it will alert you if for some reason you find yourself overclocking/underclocking when you don’t want to be and you'll know something is wrong (the alternative to this is good old fashioned log files).
. It's stand alone. You’ll see that the ‘Event’ is simply ‘Battery Overheating
’. If this event occurs, then the governor is set to conservative and the frequencies to 245 and 422,400. Let’s be honest, if you do have an overheating battery, you’re more likely to panic and put the phone in the fridge rather than rely on this profile to resolve it, but it’s a simple start and provides a useful notification should this ever occur.
. This is a good chance to save some battery life. The event is ‘screen off
’ and the task sets a tiny vibrate notification so you’ll know it’s applied whilst the screen is off. An icon will be present in the status bar when you turn the screen back on. Conservative governor and frequency of 245 and 384. You of course should tweak these to whatever you wish - that's the point of this! The other tasks within the profile are removing the notification of other CPU profiles that may have been active prior to the screen turning off.
Next, let’s set up CPU-BatteryLow
. It’s relatively stand alone again, triggered by an event of the ‘battery level
’ being less than 25%. Conservative governor, with frequencies of 245 and 499,200 with an added IF statement at the bottom confirming the battery level. A popup on the screen will tell you the battery is low, which will go away on its own or can be pressed to dismiss. All other notifications of previous states are cancelled and finally a ‘stop
’ is applied IF
the battery goes above 35%. At this point a task is performed that matches the governor and frequency of what will be your ‘regular ***
’ CPU settings (again, these should be whatever you wish). This will end once the screen is turned off so the profile returns to CPU-DisplayOff
. Triggered by the 'power
' state, the first task checks the battery level being above 50%. If it isn’t, an interactive governor is applied (to concentrate on charging), if it is, a performance governor is applied pushing the frequency up to 1075200. A status bar notification/icon and a vibrate pattern alert you that you are overclocking. Other notifications are killed.
Now we have to look at cancelling the overclocking once the phone is no longer charging/on external power. This isn’t totally straight forward, as the preferable states (inverted
) of ‘no usb connected’ or ‘battery not charging’ relate to most of the time you use your phone.
The answer is to use an ‘exit task
’, which will activate once the current state no longer applies e.g. the charge is removed. At this point, we need to check the current state of the phone, by applying tasks in order of their priority. The first task checks if the screen is off (therefore assuming the phone is no longer being used). If it is, it applies the DisplayOff
profile. Secondly, if the battery level is now greater than 25%, it applies the DisplayOn
profile (shown below). Finally (assuming the other two tasks states were not true), it applies the BatteryLow
profile. The current task is instructed to ‘stop
’ once a true state is found.
. The event is of course ‘display on
’ and it applies the governor and frequencies that you would consider your ‘regular profile***
’ for your normal phone usage. For me this is interactive with frequencies of 245 and 998,400. It of course first checks that the battery is not less than 25%, otherwise the BatteryLow
profile would have already been activated and should be left to do so. A status notification and the killing of existing notifications is included at the end.
You’ll need to create a manual ‘regular profile
’ (mine is called CPU-InteractiveManual in the .zip folder) that you can leave unchecked. This is named to match the ***
above. It’s also there in case circumstances require you deactivate all of the other profiles and just run your regular profile (because you want to).
Very finally (!), I have a manual MaxOverclock
profile, which I activate when I’m going to be using certain applications – A ROM Emulator for example.
Added in Version 2
. I noticed that the Kernel I'm using boots as standard using a conservative governor (this surprised me a little) and overclocking to max frequency (I assume to help boot speed). This profile waits 30 seconds on initial boot and then checks the phone state before applying the correct profile from above.
. During a call, my proximity sensor turns the screen on and off. When inputting numbers on a call (Voicemail for example), this caused the CPU-DisplayOff
profiles to be constantly flicking on and off unnecessarily. This profile deactivates all CPU profiles until the call is finished.
. Once the call is finished, the profiles are activated once again.
An obvious way (so obvious I previously didn't include it) to preserve battery life is to set individual CPU profiles for individual applications. Tweaking of these if you suffer lag, will help you find the minimal settings for each application.