yashsingh1/xdaforums huggingface dataset:
[Android Apps and Games] 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.
[Android Apps and Games] DiamondJohn:
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!
[Android Apps and Games] HippoMan:
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.
[Android Apps and Games] HippoMan:
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?
[Android Apps and Games] DiamondJohn:
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.
[Android Apps and Games] 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.
[Android Apps and Games] HippoMan:
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.
[Android Apps and Games] 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?
[Android Apps and Games] 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?
[Android Apps and Games] DiamondJohn:
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.
[Android Apps and Games] DiamondJohn:
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.
[Android Apps and Games] DiamondJohn:
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.
[Android Apps and Games] Chairmansaab:
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.
[Android Apps and Games] DiamondJohn:
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.
[Android Apps and Games] varunpilankar:
@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.
[Android Apps and Games] DiamondJohn:
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?
[Android Apps and Games] 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.
[Android Apps and Games] varunpilankar:
Yes, I did try.. after each boot, it reverts back to default values.. so I was left with no other option but to put it in the boot script.

I totally agree with you.. and extend to your thought their implementation is always around Google Suite and its services which is why it doesn't fit for enthusiast users or focus users (like us) who don't want certain apps/services in their phone.. maybe DeGoogle users
[Android Apps and Games] Chairmansaab:
I just tried Diamond's comatosed settings and phone went into deep doze in 22 seconds and stayed there for 30 minutes until I turned the screen on. This is brilliant. Thank you!

Is there anyway to turn the WiFi off when phone enters deep doze or 20 seconds after the screen turns off? I tried changing WiFi_sleep_policy=2 (never stays on during sleep) but system doesn't honor the settings.

Currently using this code in tasker.

SVC WiFi disable
[Android Apps and Games] HippoMan:
... which successfully prevents push messages from a number of apps from being delivered in a timely fashion. I very much want those push messages to arrive on time, but all those Google people who are brighter than me know better about what's best for me. :)

I've tried a number of workarounds, and actually, the Tasker display-event-trigger method described above is what ended up fixing this for me. I have lower battery life, and I'm willing to live with that in return for receiving messages on time.

PS: To be clear, it's actually not the same display-event-trigger method, but just the same display-event trigger. What I do is listen for this event and use it to set a "last active time" variable to the current timestamp. I then periodically run a task to see how long ago my device was last "active" in this way. If it's longer than a certain period of time, I automatically start the apps that could receive push notifications, and then a few seconds later, I put each one into the background. This way, push messages show up in a relatively timely manner.
[Android Apps and Games] DiamondJohn:
A lot of things in this post that are just not accurate.

For starters, forcing doze using tasker is NOT going to improve your phones response to notifications. Its the selected doze profile's maintenance windows that will control it.

Do NOT confuse my aggressive doze profile with google's doze implementation. If anything, my extreme doze profile breaks notifications, explicitly, thats why I created it! for ME, who does not use these apps, but was suffering battery drain as android was trying to be polite. I use to get hundreds of maintenance windows an hour. But had no notifications for it to process.

It sounds to me like you are confusing my extreme profile, as compared to running your tasker script against a standard doze profile.

I have provided an explanation of the doze parameters, so you could create your own by either minimising the time-out after screen off etc OR taking my profile and lowering the time window between maintenance periods (and lowering the factor that increases the window). THATS how android has been designed and hence I say and will continue to assert that the tasker scipt is a hack working against android design.

Lowering your time-outs to drop into idle AND lower your time between maintenence windows will get your phone into doze, and allow push notifications to come through more often.
[Android Apps and Games] HippoMan:
Thank you very much. Well, I guess I indeed could have been confused about this. However, as far as I know, I did use TeMeFI facilities to try to fix this by lowering the time window between maintenance periods and lowering the associated window-increase factor.

And perhaps I somehow did one or more of these things incorrectly (which could indeed be the case), because I still kept missing push notifications.

But I will go back and repeat the process, in case I didn't do it properly the first time.

In any case, what I did in Tasker does fix the problem, so if this doze-parameter work still doesn't help, at least I have my Tasker solution to fall back on.
[Android Apps and Games] varunpilankar:
Quick update that I noticed.. Aggressive script applied through app or any other method gets reset on charge and also on boot.

Any way to have a permanent fix for this?
[Android Apps and Games] DiamondJohn:
oh,i forgot top point out, there are a number of doze profiles available within TeMeFI, not just my extremely aggressive one.

There is something strange going on with your device. I currently have a Pixel 4A, which I think we can assume is the way Google intended Android to operate, and my phone does not do this; or my previous LOS based ROMs. Are you sure it is reverting on charge? I know that during charge, the phone ignores doze and stays out of any idle. How to "permanently" fix it would be to fix the ROM.

This also reminds me that a tasker profile would also need to simulate going back into idle if the phone is unplugged, while the screen remains off. Hence Google spent a lot of time getting doze/idle to work.
[Android Apps and Games] varunpilankar:
I'm running OOS 10 stock with Ex Kernel.. I have debloated my phone with apps and services which I don't use..

I have seen the values change while charging.. But I'll keep an eye out for values after unplugged for few hours if it revert back to aggressive profile or not..

If not I need to figure out how to apply them again through Tasker.. And that will be event based. As its a stock rom I though the doze settings applied would be permanent and for some reason they're not.. Any other way to modify the system for doze settings to stick?
[Android Apps and Games] DiamondJohn:
You dont need to wait and see the reults of doze after unplugging. If you run the doze text report / data source, it has the doze parameter reported at the top. Run the report, changing the profile, run the report, plug it in, then unplug it, re-run the report and then compare the parameters.(save the out on each step). The parameters should not change (at least not on a pixel or LOS) See this post:

https://xdaforums.com/t/app-tool-temefi-comprehensive-system-administration.3806260/post-86022295

And there is actually a compare output built into TeMeFI ;)

I dont know your ROM. Ask the question on a ROM specific thread. Its possible the kernel is also changing the doze settings :unsure:
[Android Apps and Games] varunpilankar:
Noted.. Let me try your suggestion first! I'll report back over.
[Android Apps and Games] HippoMan:
Thank you very much. I will check them out when I have the time to go back and retry this.
[Android Apps and Games] HippoMan:
By the way, here's how I handle this in Tasker, and it does indeed work ...

I use Tasker to calculate and store the last time my device was "active" in a global Tasker variable. By "active", I mean that some sort of user interaction with the device has taken place. This global value is periodically checked, and if enough time has passed since I last interacted with the device, a task gets invoked to force-kill the apps from which I can get push notifications, to restart them, and then a few seconds later, put them into the background, while resetting that "active" timestamp, as well. This force-killing/restarting only takes place for any of those apps which are not currently in the foreground.

This consumes battery, but not enough to bother me. And now, I always receive my push notifications soon after they have been sent.

As I mentioned, I'll eventually go back and retry the doze-profile configuration in TeMeFI, in case I did something incorrectly the first time I tried it. If that works, then I'll switch to the appropriate doze profile and disable this Tasker stuff.
[Android Apps and Games] DiamondJohn:
What I would not be surprised is that Tasker itself will also be subject to the doze maintenance windows. So anything you have built and run will be dependent on maintenance windows. I dont use it, but it would be very impolite if it is causing wake-locks outside of maintenance windows.

I will repeat, the tasker job is not what is enabling the messages to come through. Its the doze profile maintenance windows.

Otherwise, if it could operate outside of maintenance windows, then my extreme profile with very far apart maintenance windows would not affect your tasker job, but what you have implied is that it does.
[Android Apps and Games] HippoMan:
Tasker is always alive. It is configured to be foreground-like, and it always has an icon in the notification bar.

I ran tests with Tasker where it appended a short, timestamped message to a file every two minutes, and it did so on precise schedule, 24 hours a day, over a 2-day period, without missing a cycle ... irrespective of whatever else was happening (or not happening) with my device during those days. And I was busy with the device then, as well as also there being periods of no device use.

I utilize its ability to stay awake in this way in order for it to function as a scheduler for the procedure that I outlined above.

Yes, this consumes battery, but as I have mentioned, it doesn't eat enough battery to be a problem for me, and now I am not missing my push messages any more.

I don't know enough about the inner workings of Tasker to understand how it is able to function in this manner. But it does so.
[Android Apps and Games] Extreme_Ninja2099:
Is there a way to use this app to detach google play services from the playstore? It keeps updating google play services when I don't want it to.

I just can't find com.google.android.gms package to detach the app
[Android Apps and Games] DiamondJohn:
The whole point of doze is to stop apps running in the background.

Just because an app has a notification is mostl;y irrelevant to how it behaves under doze. The notification stays either way. The play store breaks through doze without a notification.

Hove you actually run a doze graph while your logging script is running to check if it is really in doze?

Running an OLD method to SIMULATE doze is not the same as the device entering full idle doze. There are MANY documented methods in the shell that dont work, and do not raise errors when you call them. They just dont work as you think they do, no matter how obviously named they are. If you can force deep-idle while the screen is off, that makes it abundantly clear it is not deep-idle.

I have recently switched from my Comatosed doze profile to the one "Havoc-OS-Oreo-Aggressive". I made the switch because my profile made the AOD not change the time! I am guessing if you try this one, it would also allow yur message/notifications from your app also come through. Without having a additional work-around (ie read as dirty) scheduled task, but have android work the way its designed to run. Below is the doze cycle graph using this profile. As can be seen, it locks down to deep idle pretty quick after a screen off, and the AOD works as expected. The big block in the center is when I was navigating/driving around.
[Android Apps and Games] DiamondJohn:
This is something that has changed.

As I have said many times before, you can only detach something that is attached. When I first built it, the gms app was in the list of attached apps. I just checked and it no longer is; as you have found. They have changed it. However, I had never tested it anyway, so wouldn't know if it would of actually worked.

Now, there is a little dodgy trick I can do to detach apps that are not attached, but if it isnt attached, then only method 1 may be fully implemented (and method 1 is not good for google apps). Although, one could still try method 2 or 3 using my workaround, it will report failures as the attachment is not there. Google appear to now be checking for updates to the playstore using a different method to the apps in the playstore itself.

The following is a workaround, so if it doesnt work, thats the way it is. try unzipping the following and drop them into the folder /sdcard/TeMeFI/.favourites They should now be available in the Favourites menu (refresh the menu if you already have temefi open, long press the "home" toolbar item).
[Android Apps and Games] Extreme_Ninja2099:
Thanks for your reply. I've now tried using just method 3 as your feedback on method 1 is not good for google apps put me off. I do have some important google apps I need working. We'll see if method 3 works... This is really to fix the weird google UI element bug in OOS 11 settings btw. uninstalling google play services fixes it and google play store keeps updating it which brings back the UI element bug