The Deep Sleep Detective

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.

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:

sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

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:

245760   319834
384000   4651
576000   3736
768000   2271
998400   6983
1113600  24953

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 load of comparable percentages, converting a lot of milliseconds to hours and minutes to make it user-friendly for you.

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:

YouPorn Mobile and has been killing your battery - uninstall it by clicking here

That may be a few versions away, but we've all got to have a dream…

Simple Preparation

Before importing the profiles and tasks:

  • Download and install Locale execute plugin
  • Download and install the latest BETA Version of Tasker (Profiles use new functionality). This is NOT the latest market download or direct purchase, it contains more features that are required. Please follow the link.
  • Glossy Silver HD icons apk (Open any existing task, click on the icon selection button - Download More Icons)
  • Backup your profile data and tasks
  • Ensure Tasker has 'Accessibility' and 'Administrator' permission on your device.

IMPORTANT READ BEFORE FIRST RUN

Thanks to nobnut and his testing, I've been able to establish that the SuperUser requests initially cause issues by preventing the tasks from completing and therefore corrupting the data - which goes on to cause more errors. We need to get these all out of the way at once. Please follow these instructions:

1) Open the task DSDSuperUser - keep pressing 'test' until no more SuperUser requests are appearing. This will leave all the commands free to run in the tasks. Apply out of Tasker and then go back to this task and press 'test' once again to make sure no further SU permissions didn't prompt the first time. There may well (should) be 5 permission to accept.
2) Reboot your phone
3) Once booted, you will receive an error that the data was corrupted. This is as expected (as there isn't any). Ignore it.

Ad-hoc

I've added an ad-hoc task since V3, so you can check the statistics at any time. Easiest way to launch it is via an icon from your desktop using a Tasker 'run task' widget, available in the widget options on your launcher. DSDAdhoc should be triggered first, which in turn will trigger DSDAhMathsDST and DSDAhMathsUPS then information will appear on your display.

Planning Ahead

The profiles currently use the following triggers:

  • Display On
  • Display Off
  • In Call
  • Call End
  • USB Plugged Power
  • Device Boot
  • Device Shut-down

Depending on your current set up, you may already have most of these contexts, so assuming you wish to keep the profiles installed, you may wish to use Perform Task actions as opposed to doubling them up. YOU MUST make sure these profiles run with a higher priority than your others to avoid the loops catching one another…

SuperUser

There are commands that will require SuperUser permissions. YOU MUST follow the instructions above and make sure all of the commands have permission by running DSDSuperUser repeatedly until no more prompts appear. Once you have done this, I would suggest you then reboot to avoid data confusion.

Alternatively, download SuperUser Elite from the market for $1 (worth a donate for everything the app has done for us) which has automatic permissions…. so much easier…. (to get the hidden bacon/app, keep clicking on the 'get it' button!)

Files and Logs

The Deep Sleep Detective writes two files to your SDCard:

DeepSleepDetective.txt is triggered when your device has not been in DS for more than 80% of DSP. It provides a list of your running applications, historic wakelocks, running tasker profiles (in case you have a loop) and DS statistics - The information provided will become more specific as the versions go on.

DS-BootReport.txt is triggered when the device boots up. It writes DS statistics taken prior to the last shut-down.

You will get screen prompts when these files are ready to view. They are stored on the root of your storage card.

Note: A DSD-Shutdown text file is also written, but this should be created just prior to power off (hopefully it has time) and deleted in the boot task.

Key

When the tasks run, symbols will appear on the screen, this is what they mean:

'-'| No potential time for your device to deep sleep occurred in the screen-off state
'+' then '-' | Deep Sleep Potential time occurred, but insufficient data to provide a report
'+' then 'Zzzz…' | Deep Sleep Potential time occurred and a report is being processed


I'll add more to the above when I get time


Download

The latest download can be found here.

For version updates, bugs and related problems and questions, please visit this thread

Credits

waydownsouth - Terminal Command help that saved me hours…..
nobnut - HUGELY MASSIVE amount of testing
Pulser_g2 - Solving my toolbox woes

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License