[APP][TOOL] TeMeFI comprehensive system Administration

[esszett]

Hi @DiamondJohn & all,

I have been trying to find the optimal Doze settings for my device for quite some time now. Although I am reasonably satisfied, but as we know: better is always possible!

Finding the right balance between Light and Deep Doze is somewhat complicated and unfortunately varies from day to day. On days when I'm walking a lot, I'd prefer to just let the phone stay in light doze mode, while on days when the phone is mostly lying around, I'd prefer to skip light mode altogether. So every setting always comes down to a compromise.

In Android, there is the energy-saving mode. I actually find it pretty good for my needs, because there is no light doze and the device goes directly into deep sleep and stays there until I actually wake it (however, there are hourly, but unnecessary wakelocks). The AnyMotion function seems to be completely ignored.

When I try to reproduce this behavior using "device_idle_constants" (all "light" settings set to 0), I get exactly the desired behavior - if I don't move the phone. However, as soon as I move the smartphone, it rains wakelocks like crazy (several hundred thousand in a few hours). And, of course, that drains the battery a lot.

Has anyone ever successfully tried to reproduce the Battery Saver with "device_idle_constants"?

Thanks!

 

[DiamondJohn]

Hi @DiamondJohn & all,

I have been trying to find the optimal Doze settings for my device for quite some time now. Although I am reasonably satisfied, but as we know: better is always possible!

Finding the right balance between Light and Deep Doze is somewhat complicated and unfortunately varies from day to day. On days when I'm walking a lot, I'd prefer to just let the phone stay in light doze mode, while on days when the phone is mostly lying around, I'd prefer to skip light mode altogether. So every setting always comes down to a compromise.

In Android, there is the energy-saving mode. I actually find it pretty good for my needs, because there is no light doze and the device goes directly into deep sleep and stays there until I actually wake it (however, there are hourly, but unnecessary wakelocks). The AnyMotion function seems to be completely ignored.

When I try to reproduce this behavior using "device_idle_constants" (all "light" settings set to 0), I get exactly the desired behavior - if I don't move the phone. However, as soon as I move the smartphone, it rains wakelocks like crazy (several hundred thousand in a few hours). And, of course, that drains the battery a lot.

Has anyone ever successfully tried to reproduce the Battery Saver with "device_idle_constants"?

Thanks!

Doze setting are generally working on IF statements about what is happening on your phone. There are 10+ different settings, and one of them is something like how long after moveent to allow doze;which wouldbe when you are walking. If that would suffice, that up to you to create your personal profile. I have include a description of each parameter to make that easier.

But, it sounds like you are not satisfied with that.

The other choice, which sounds more likely to satisfy your requirements is explicit switching.

I use a custom launcher which allows scripts to be run on secret hot-spots or specific gestures on an area (a hot-spot or a swipe on an existing icon). I use it to run a force-stop on a long list of apps and then shut my screen off. You could get some script to switch you doze profile on request. There are many ways to trigger a shell script. Only you would know the way you need your phone to run. I swipe up or down in my weather widget and that turns AIOD on or off. Wee all have slightly different ways we want out devices to react.

 

[esszett]

Doze setting are generally working on IF statements about what is happening on your phone. There are 10+ different settings, and one of them is something like how long after moveent to allow doze;which wouldbe when you are walking. If that would suffice, that up to you to create your personal profile. I have include a description of each parameter to make that easier.

But, it sounds like you are not satisfied with that.

Exactly
I did several "experiments" with different doze settings (BatteryGuru's doze settings, system's battery saver, OS's Aggressive Idle settings, your comatoes settings, and, of course, many own settings). After a battery cycle I analyze the battery dump with BatteryHistorian.

As far as I can see and understand, the "motion_inactive_timeout" causes the device not to switch back to deep doze mode for this period after a movement, but to stay in light doze which ignores AnyMotion. During deep doze, the system always expects feedback from AnyMotion - as soon as motion is detected or if you deactivate the AnyMotion function/sensor, the system exits deep doze or never even reaches deep doze respectively. However, I've not yet tested how the system behaves when I set the light Idle values to 0 and this motion timeout parameter to e.g. 43200000 (12h). Maybe this will bring me closer to "recreating" the system energy saving mode with more aggressive timeouts, which more or less completely ignores AnyMotion and only wakes up the device for maintenance task.

I hoped someone already tried & tested that

The other choice, which sounds more likely to satisfy your requirements is explicit switching.

That would be my non-prefered option that I would use as a real last resort because that would be too inconvenient for me on a day to day basis. Thanks anyway!


Thank you for taking time to deal with my "problem" and answer me!

 

[HippoMan]

This current discussion about doze got me thinking about a long-standing, tangential issue that I have been facing, and now I'm wondering whether perhaps TeMeFI could possibly help.

I'm running Android 10 on my OnePlus 7Pro. This OS version and several earlier versions are trying to be helpful with regard to battery life, but in the process, they seem to have made my everyday mobile-device life to be worse.

There are some apps that I regularly run which respond to push messages. Because of Android's battery-life-conservation conventions, these apps often do not receive their push messages in a timely manner, because Android has apparently killed them after a period of non-use, or at least somehow made them dormant and not responsive to these push messages.

This occurs even though I have set battery optimization to "Don't optimize" for each of these apps.

These delayed push messages sometimes cause major headaches for me when someone or some service that I want to hear from do not reach me in a timely fashion.

Is there any way that TeMeFI might be able to help me keep these apps always alive on my device, so that I do not miss these push messages? I understand that this would lower my battery life, but I am gladly willing to live with this, at least with regard to these particular apps.

This is sort of the opposite of "doze". Perhaps I could call this feature "insomnia".

If this is out of the realm of TeMeFI capabilities, can anyone offer any other suggestions?

Thank you in advance.

PS: The following article discusses the problem in a little more detail. It apparently has been an issue since at least as far back as Marshmallow:
https://androidforums.com/threads/m...x-is-preventing-doze-with-macrodroid.1058445/

The author of that article talks about how this was solved for a specific email app. However, that is not a general solution. I posted this article simply to illustrate how this has been a known problem in Android for a while.

 

[DiamondJohn]

This current discussion about doze got me thinking about a long-standing, tangential issue that I have been facing, and now I'm wondering whether perhaps TeMeFI could possibly help.

I'm running Android 10 on my OnePlus 7Pro. This OS version and several earlier versions are trying to be helpful with regard to battery life, but in the process, they seem to have made my everyday mobile-device life to be worse.

There are some apps that I regularly run which respond to push messages. Because of Android's battery-life-conservation conventions, these apps often do not receive their push messages in a timely manner, because Android has apparently killed them after a period of non-use, or at least somehow made them dormant and not responsive to these push messages.

This occurs even though I have set battery optimization to "Don't optimize" for each of these apps.

These delayed push messages sometimes cause major headaches for me when someone or some service that I want to hear from do not reach me in a timely fashion.

Is there any way that TeMeFI might be able to help me keep these apps always alive on my device, so that I do not miss these push messages? I understand that this would lower my battery life, but I am gladly willing to live with this, at least with regard to these particular apps.

This is sort of the opposite of "doze". Perhaps I could call this feature "insomnia".

If this is out of the realm of TeMeFI capabilities, can anyone offer any other suggestions?

Thank you in advance.

PS: The following article discusses the problem in a little more detail. It apparently has been an issue since at least as far back as Marshmallow:
https://androidforums.com/threads/m...x-is-preventing-doze-with-macrodroid.1058445/

The author of that article talks about how this was solved for a specific email app. However, that is not a general solution. I posted this article simply to illustrate how this has been a known problem in Android for a while.

Sorry, too much to read as it is, so I did not follow the link. And to be honest, I skim read what you posted here.

When I have had issues with apps being killed by the system, against my will. I use (and hence created) the OOM and LMK (Low Memory Killer NB LMK is not there in A12, it was in A8, not sure when it stopped being a part of android) methods in TeMeFI.
OOM can be found at:
Application Info / Manage>State>OOM>OOM an app to Superman [-17]>*
I also use to set the thread priority (the "Nice")to high, just for good measure on my problematic app.
Application Info / Manage>State>Nice>Nice an app to Highest [-20]>*

There is also a file to lock specific apps out from doze, but from memory, its a little more work for the user (but TeMeFI gives you an inroad), and I never had to use it. For example, the playstore is excluded from Doze by inclusion in this XML file, so seeing where this is stored, gives you an inroad of what needs to be changed to add your own app, and exclude it from doze.

As I said, i didnt read the article.But if the app is not killed (see OOMabove) then in doze, you need more maintenance periods for apps to raise their notifications. My Comatozed profile explicitly limits these to very very long windows, so its not good for these types of apps. I have even noticed that the time on my AOD stops changing! it freezes time!

 

[HippoMan]

[ ... etc. ... ]

There is also a file to lock specific apps out from doze, but from memory, its a little more work for the user (but TeMeFI gives you an inroad), and I never had to use it. For example, the playstore is excluded from Doze by inclusion in this XML file, so seeing where this is stored, gives you an inroad of what needs to be changed to add your own app, and exclude it from doze.

[ ... etc. ... ]

Thank you very much!

Even though I only quoted part of your response, I did indeed read all of it ... and I did not skim.

I reset the OOM and Nice values for one of the apps in question, as you described. So far, so good, but let's see if that indeed keeps the app alive enough to no longer miss any subsequent push messages that will be sent to it.

Regarding the portion of your message that I quoted, how can I find out more infomation about that XML file for locking apps out from doze? ... i.e., where that file might be stored and perhaps some info about how it is used?

Thank you again.

 

[HippoMan]

I think I found the info about that XML file ...

Create a *.xml file with any name and add following content:

<?xml version="1.0" encoding="UTF-8"?>
<config>
  <allow-in-power-save package="com.your.package.name" />
  <allow-in-power-save-except-idle package="com.your.package.name" />
</config>

Remount your system partition mount -o remount,rw /system and copy the file to your /system/etc/sysconfig/ folder. You may also remove the preinstalled *.xml files to disable the forced system services.

In case anyone is interested, I found that info on the following web page:
https://android.stackexchange.com/questions/129074/is-there-a-way-to-exclude-an-app-from-doze

Is this the XML file that you were referring to?

 

[DiamondJohn]

I think I found the info about that XML file ...


In case anyone is interested, I found that info on the following web page:
https://android.stackexchange.com/questions/129074/is-there-a-way-to-exclude-an-app-from-doze

Is this the XML file that you were referring to?

I just scrolled past it quickly. I did see the dumpsys device idle whitelist, which from memory is also in TeMeFI. (phone flat right now, just got back from being out all day with screen on)

The file I saw is a small XML file, that would currently have the playstore in it, and maybe one or two other google apps. It is visibleeither explicitly as an item (try a menu search) or is easy to get to (when you know which one that is) using the dynamic lists enable file browsing.

The other thing to mention,even after you stop it being killed, but haven't excluded it from doze, you can shorten the doze maintenance windows to allow it to raise its notifications.

 

[DiamondJohn]

@HippoMan Another thing to ensure is that the app is not being killed because your device is simply running out of memory (touches on LMK). Also try adding a large swap file. Which of course can be done with TeMeFI. NB: Disappears on boot if you dont run a boot scipt.

 

[HippoMan]

@HippoMan Another thing to ensure is that the app is not being killed because your device is simply running out of memory (touches on LMK). Also try adding a large swap file. Which of course can be done with TeMeFI. NB: Disappears on boot if you dont run a boot scipt.

Thank you.

I have checked, and I have plenty of swap space. I'm thinking that perhaps my problem is not necessarily due to those apps being killed, but rather, something to do with push messages not being forwarded to these apps when they have been idle for too long, even though the apps are still running. I remember reading something about this on line a few days ago, but I can't find the article at the moment.

Anyway, thank you again for all your help. I'll keep investigating this.

 

[varunpilankar]

I'm using @DiamondJohn aggressive profile and so far it's running great.

I'm just concerned about too many Wakelock - Alarms by Android System which are mainly *job.deadline and *job.delay

Not able to trace back which jobs are getting delayed or hits deadlines trouble.. But I think it does drain some battery as they number are large enough - like 900 or 1000+ sometimes.


Any fixes for this?

 

[rodken]

@DiamondJohn From a Doze aspect, in order to keep an app working in the background, do I select from the 'Ignore App Wakelock' feature before or after I select from one of the built-in profiles?

Can you also point me to where I can backup my current profile?

 

[DiamondJohn]

I'm using @DiamondJohn aggressive profile and so far it's running great.

I'm just concerned about too many Wakelock - Alarms by Android System which are mainly *job.deadline and *job.delay

Not able to trace back which jobs are getting delayed or hits deadlines trouble.. But I think it does drain some battery as they number are large enough - like 900 or 1000+ sometimes.


Any fixes for this?

Job delay & deadline will be caused by apps requesting the system for that service. You will need to find out which/what is causing them. In TeMeFI, there are numerous wake-lock reports. The first that comes to mind is in the battery History extras, under textural events, there is wake-lock, Wake reason and even wake-up app

Also, if you take a log as per the better battery stats thread requires, there are people there who will help you delve deeper.

 

[DiamondJohn]

Can you also point me to where I can backup my current profile?

Your currenrt profile is kind of stored in two ways. Your ROM will boot with a fixed preset profile, but your settings (which is how I change it) can override these.

So, for the second, the script to set / preview (from memory) explicitly provides the script to roll back any changes that would be made.

As for the ROM based ones, if you have not modified it or clear the settings, the actual values are available in the textural report Currently Running>Doze>Device Idle History



I think, setting to the "CURRENT"will give you the backup script, and set it to what it is currently.

 

[DiamondJohn]

@DiamondJohn From a Doze aspect, in order to keep an app working in the background, do I select from the 'Ignore App Wakelock' feature before or after I select from one of the built-in profiles?

There are over 500+ methods. I have not had to test every method "in anger". I have based a lot of the default android items as documented (as opposed to things like the battery history graph which is mostly my dev) I personally have not had to use "Ignore Wake Lock", so I can only go off the doco, which is available to you also.

Now, you ask would "Ignore Wake Lock" "keep an app running in the background", I would say it would do the EXACT OPPOSITE. Its the wake-locks that allow an app to run. Ignoring a wake lock would keep the app inactive, as it wont be allowed to wake up the device to do its work.

 

[Chairmansaab]

I'm using @DiamondJohn aggressive profile and so far it's running great.

I'm just concerned about too many Wakelock - Alarms by Android System which are mainly *job.deadline and *job.delay

Not able to trace back which jobs are getting delayed or hits deadlines trouble.. But I think it does drain some battery as they number are large enough - like 900 or 1000+ sometimes.


Any fixes for this?

dumpsys deviceidle force-idle deep
dumpsys deviceidle unforce

I read your previous message where you used Tasker to execute shell commands on display on and off, I'm doing the same thing and stumbled on this thread via Google search. Is there any downside to forcing it via shell command (tasker) vs an Aggressive profile? Which one is better? I'd like an opinion of DiamondJohn on this as well. I'm using Tasker for other stuff, either way it'll keep running in the background.

My usage: I've factory reset the phone and only have about 6 apps, none of them require notifications, I'm not a heavy user.

 

[DiamondJohn]

dumpsys deviceidle force-idle deep
dumpsys deviceidle unforce

I read your previous message where you used Tasker to execute shell commands on display on and off, I'm doing the same thing and stumbled on this thread via Google search. Is there any downside to forcing it via shell command (tasker) vs an Aggressive profile? Which one is better? I'd like an opinion of DiamondJohn on this as well. I'm using Tasker for other stuff, either way it'll keep running in the background.

My usage: I've factory reset the phone and only have about 6 apps, none of them require notifications, I'm not a heavy user.

I dont use tasker.

The reason I use an aggressive doze is for battery saving. Tasker adds to battery consumption, whereas a doze profile is using the already running system. Another benefit of using a doze profile, is that it allows a timeout when switching the screen off for apps to prepare for doze. Also, if you have an app that manages to wake your phone out of deep-idle and into light-idle without switching your screen on, then tasker is not going to catch it, and hence your phone is out of deep-idle until the profile says so.

 

[varunpilankar]

dumpsys deviceidle force-idle deep
dumpsys deviceidle unforce

I read your previous message where you used Tasker to execute shell commands on display on and off, I'm doing the same thing and stumbled on this thread via Google search. Is there any downside to forcing it via shell command (tasker) vs an Aggressive profile? Which one is better? I'd like an opinion of DiamondJohn on this as well. I'm using Tasker for other stuff, either way it'll keep running in the background.

My usage: I've factory reset the phone and only have about 6 apps, none of them require notifications, I'm not a heavy user.

@DiamondJohn is right... I tried using tasker on display event trigger, it does trigger too many wakelock alarms (monitored using BBS). You can still try it yourself to see if you get some different results - keep us posted.

I finally settle on using @DiamondJohn aggressive profile on the boot script from his app and did some modifications to my taste. now it is running great.

 

[DiamondJohn]

...snip...

I finally settle on using @DiamondJohn aggressive profile on the boot script from his app and did some modifications to my taste. now it is running great.

On my kast two devices, I only had to set it once, and it stuck through a reboot. I gave the bootscript as that was one of the first things I built, and I ponly had the one device, so couldnt check if it was only my device that it stuck.

Our of interest (and for others) Did you check before you made it a boot script if it already stuck between boots?

 

[DiamondJohn]

another thing that occurred to me after I posted, it would of been trivial for Google to mimic your tasker effect, of forcing doze immediately on screen off, but instead they engaged many people brighter than you & I spend hours and hours and thus $$$ & $$$ on developing the automated doze mechanism.