Profile Aim
Tasker will use a number of triggers to detect, log, monitor and report when your device has been in a deep-sleep state, and more importantly; when it hasn’t. The profiles identify both potential and actual deep-sleep-behaviour, providing statistics and real-time alerts should your device fail to enter deep-sleep in the absence of any common preventing factors. The alerts will enable you to identify the troublesome processes and applications that love to kill your battery.
Pushing Tasker to its Limits?
Composing this after just uploading V13, I can confidently say that I'm pretty sure I've now pushed Tasker to its limits when it comes to using its functionality and to build as close as I believe you can get to a fully fledged application:
* Installation tasks to inject binary and set permissions
* Tasks dynamically compose and execute shell scripts
* Automated and ad hoc error logging
* 'Self-checking' error loops
* Tasker/shell generated reporting
* Media and interactive notifications
* 28 intertwining tasks totalling 500+ actions triggered by 11 contexts
Theory
Finding out when your device has entered deep-sleep, is rather like asking someone to drop you a quick text as soon as they’ve died. As impossible as that sounds, you can of course always get them to let you know they aren’t dead; establish they are doing something else so currently can’t be dead; or discover they are indeed still alive and therefore conclude they weren’t dead in the first place…
I’ll stop talking in riddles and start where I started, which is when your device has the potential to enter deep-sleep:
* When the display is off
Yes, I know that was a pretty obvious one to start with, but if we just record potential deep-sleep-time as ‘screen off time’ we will be left with major inaccuracies such as:
* Media Playing
* During Call
And more importantly:
* Device charging
Those example factors already start to narrow down the times of when your device enters the zone of deep-sleep-potential (DSP).
Practice
We can retrospectively establish the amount of time the device has spent in deep-sleep, by looking at the file:
Next to each available scaling frequency is the amount of time in milliseconds the device has spent at that frequency since last boot. This is my example file:
The up-time of the device, less the sum of the individual frequency times, provides us with the amount of time that the CPU was not active = Total-Deep-Sleep-Time. We can compare this proportionally to the up-time and simply report deep-sleep as a percentage of the current usage (since last boot).
That is all well and good, but if the percentage is very low, it immediately suggests poor device performance and that may not be a true reflection. To make this figure more accurate (and perhaps less alarming) we first need to establish the DSP your device had and base our statistics on that.
Overview
Dealing with the obvious first, we know that DSP occurs only when the screen is off and ends when it turns back on. At the point the display goes off, we can take a log of the current up-time and compare it to the total time in frequency state. Subtracting one from the other gives us a constant we can refer to.
If the device does not enter deep-sleep prior to the screen turning back on, then performing the same calculations at the display on trigger should provide the same constant.
Any difference between the display off/on constants will notify us not only that the device has been in deep-sleep, but also for how long. This information can be immediately relayed and/or totalled up to be used against DSP times to build a more accurate, real-time and ongoing reflection of your device’s deep-sleep-behaviour (DSB).
Already starting to narrow down DSP times, and we can further exclude the events that were listed above (such as charging) from our DSP calculations.
Profiles and Tasks
I think I may have permanently damaged my brain making these profiles work, report and intertwine correctly… I have many further plans which I’ll list below – albeit theoretically….
Unlike my other Tasker posts, I’m not going to make this a tutorial (*group sigh?*), as in brief terms (which does not reflect the extent of my hair-loss), it keeps checking the time-in-state files against constants whilst making sure no DSP excluding factors or events are active. It performs a sh*t load of comparable percentages, converting a lot of milliseconds to hours and minutes to make it user-friendly for you. Yes, that was my hint to you to hit the thanks meter
Honestly, the thought of writing this one out in detail makes me feel bored, so I doubt it would make very exciting reading… The logic in the profiles is there to follow of course and I’ll be happy to answer any of your questions, but for once this really is just a ‘plug and go’ – there’s nothing for you to edit, other than perhaps choosing to align triggers with your existing set-up.
Future Development
It's my understanding that power management and wakelock debugging can only be implemented when Android is compiled and therefore we have no specific "I'm about to fall asleep, quick take a log" trigger to work with (I'd love you to tell me otherwise) for analysis, so as the profiles develop, more deep-sleep preventative 'events', such as receiving an SMS will be included in order to build a greater picture of what is happening before and after deep-sleep.
The ultimate goal would be to gather comparison logs to flag up the likely suspects for the device not entering deep-sleep in the first place or waking up from it too often. You can almost see the UI notification now:
What? You didn't think I was doing this all for the love of the community did you?!
Tasker will use a number of triggers to detect, log, monitor and report when your device has been in a deep-sleep state, and more importantly; when it hasn’t. The profiles identify both potential and actual deep-sleep-behaviour, providing statistics and real-time alerts should your device fail to enter deep-sleep in the absence of any common preventing factors. The alerts will enable you to identify the troublesome processes and applications that love to kill your battery.
Pushing Tasker to its Limits?
Composing this after just uploading V13, I can confidently say that I'm pretty sure I've now pushed Tasker to its limits when it comes to using its functionality and to build as close as I believe you can get to a fully fledged application:
* Installation tasks to inject binary and set permissions
* Tasks dynamically compose and execute shell scripts
* Automated and ad hoc error logging
* 'Self-checking' error loops
* Tasker/shell generated reporting
* Media and interactive notifications
* 28 intertwining tasks totalling 500+ actions triggered by 11 contexts
Theory
Finding out when your device has entered deep-sleep, is rather like asking someone to drop you a quick text as soon as they’ve died. As impossible as that sounds, you can of course always get them to let you know they aren’t dead; establish they are doing something else so currently can’t be dead; or discover they are indeed still alive and therefore conclude they weren’t dead in the first place…
I’ll stop talking in riddles and start where I started, which is when your device has the potential to enter deep-sleep:
* When the display is off
Yes, I know that was a pretty obvious one to start with, but if we just record potential deep-sleep-time as ‘screen off time’ we will be left with major inaccuracies such as:
* Media Playing
* During Call
And more importantly:
* Device charging
Those example factors already start to narrow down the times of when your device enters the zone of deep-sleep-potential (DSP).
Practice
We can retrospectively establish the amount of time the device has spent in deep-sleep, by looking at the file:
Code:
sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
Code:
245760 319834
384000 4651
576000 3736
768000 2271
998400 6983
1113600 24953That is all well and good, but if the percentage is very low, it immediately suggests poor device performance and that may not be a true reflection. To make this figure more accurate (and perhaps less alarming) we first need to establish the DSP your device had and base our statistics on that.
Overview
Dealing with the obvious first, we know that DSP occurs only when the screen is off and ends when it turns back on. At the point the display goes off, we can take a log of the current up-time and compare it to the total time in frequency state. Subtracting one from the other gives us a constant we can refer to.
If the device does not enter deep-sleep prior to the screen turning back on, then performing the same calculations at the display on trigger should provide the same constant.
Any difference between the display off/on constants will notify us not only that the device has been in deep-sleep, but also for how long. This information can be immediately relayed and/or totalled up to be used against DSP times to build a more accurate, real-time and ongoing reflection of your device’s deep-sleep-behaviour (DSB).
Already starting to narrow down DSP times, and we can further exclude the events that were listed above (such as charging) from our DSP calculations.
Profiles and Tasks
I think I may have permanently damaged my brain making these profiles work, report and intertwine correctly… I have many further plans which I’ll list below – albeit theoretically….
Unlike my other Tasker posts, I’m not going to make this a tutorial (*group sigh?*), as in brief terms (which does not reflect the extent of my hair-loss), it keeps checking the time-in-state files against constants whilst making sure no DSP excluding factors or events are active. It performs a sh*t load of comparable percentages, converting a lot of milliseconds to hours and minutes to make it user-friendly for you. Yes, that was my hint to you to hit the thanks meter
Honestly, the thought of writing this one out in detail makes me feel bored, so I doubt it would make very exciting reading… The logic in the profiles is there to follow of course and I’ll be happy to answer any of your questions, but for once this really is just a ‘plug and go’ – there’s nothing for you to edit, other than perhaps choosing to align triggers with your existing set-up.
Future Development
It's my understanding that power management and wakelock debugging can only be implemented when Android is compiled and therefore we have no specific "I'm about to fall asleep, quick take a log" trigger to work with (I'd love you to tell me otherwise) for analysis, so as the profiles develop, more deep-sleep preventative 'events', such as receiving an SMS will be included in order to build a greater picture of what is happening before and after deep-sleep.
The ultimate goal would be to gather comparison logs to flag up the likely suspects for the device not entering deep-sleep in the first place or waking up from it too often. You can almost see the UI notification now:
That may be a few versions away, but we've all got to have a dream... and preferably one that involves every noob with battery issues downloading my application for a dollar from the market
What?
You didn't think I was doing this all for the love of the community did you?!
Last edited:
