SoT / screen on time - why it is *not* a universal measurement for ROM / kernel battery management

SoT / screen on time - why it is *not* a universal measurement for ROM / kernel battery management

crok - crok.bic @XDA - crokbic @Telegram

Android SoT is not a universal measurement of a ROM's or a kernel's battery management.


It strongly depends on way too many factors, like:

- display brightness

- mobile connectivity (signal strength / signal to noise ratio, network type, scanning / looking for better coverage..)

- wifi connectivity (signal strength / signal to noise ratio, network type, number of neighboring devices (RF field busyness, etc..)

- frequency settings of SoC (CPU & GPU), governor behavor & "boosting" settings (too much/too high? Possibly too much drainage.. too less/too low? Possibly battery friendly but leading to too laggy UI behavior..)

- thermal throttling (reducing RIL capabilities will cause lower network speeds / reductions / restrictions - and thus the same amount of data traffic needs more time and since the user is waiting but the UI & display is active the drainage will be higher)

- background apps and their activities (syncing data, userspace wakelocks, alarms in apps triggering activities (refreshing data, etc..), lots of notifications via GMS, network location provider (NLP) wakelocks..)

- actual app + device usage pattern: 2D gaming // browsing the web // instant massaging // watching Youtube (strongly depending on the video quality!) // 3D gaming are resulting / needing _way different_ CPU & GPU load thus the same amount of "screen on time" made by different kind of activities are producing _way different_ drainage

- actual device usage pattern of the user: Impulsive usage of the device by the user costs more battery consumption - this is not news. A usage pattern with long idles and long actual usage is "producing a better overall SoT" than a usage pattern with short idles and whatever actual usage (so picking up the phone like a maniac whenever getting a notification.. or enabling "screen on when notification arrives" mode in settings - hope you get it) because while the phone idles for long time it has the opportunity to go deep doze instead of light doze and thus the idle drain become lower and thus your SoT can be higher since you save some jouce. Doze settings can be edited with root + Doze Editor, explanation for the variables are also available there @XDA and @GitHub and you can use TeMeFI's @XDA Doze settings' profiles, too! Doze settings are editable via ADB, too, but it's a bit more complicated.. you have to modify a lot of global settings via ADB from CLI.. feasible but way less convenient.


..and I hope this is trivial now for everyone ;)


If you want to measure a ROM's and/or kernel's battery management then create / know your baseline of usage and then you can compare the ROM's and/or kernels, like:

- open the same video player and play the same video on different ROMs and/or kernels

- disable almost everything and leave the phone totally idle for hours and check the battery drainage

- be creative and create your own usage baseline..

..and then you will know how good is the ROM and/or kernel in terms of battery management.


Please, whenever you publish a SoT value just let people know your usage pattern as well. Without that info the SoT value itself is completely useless. I know this needs a lot of work.. But many people are complaining out there and have no idea what's the background..



PS - just an advise: if you think about it..

finishing a task in less time and going back to idle is much better

than finish it in more time and go back to idle..

It will results a snappier UI and more energy efficient - in my opinion.

Check the voltage/frequency table of your SoC in the kernel source

and try to find the most efficient frequencies,

use interactive CPU governor and set an appropriate freq. for hi-speed,

increase if necessary but go back to idle shortly when load reduces.

So set your CPU/GPU governors accordingly.

And disable ZRAM is you have a lot of RAM anyway.. makes no sense to spend CPU cycles on compressing / decompressing app memory when you have a lot of free, usable memory anyway.. ( :


Have fun!



crok


Report Page