yashsingh1/xdaforums huggingface dataset:
[Android Apps and Games] HippoMan:
Thank you very much for all of this.

I haven't run a doze graph lately, but think I understand in general how doze works in this regard (thanks in part to your explanation). I'll check the graph a little later.

Concerning my specific issue, however, it's mostly irrelevant how my OS causes certain apps to behave under doze, or in the background, or in the foreground, or whatever. My goal is for that subset of apps to not miss their push notifications, and the Tasker-based fix that I put in place allows these apps to indeed get their push notifications in a timely manner.

To summarize: I use Tasker to "tick" in a precise, timely manner (which it always does reliably, irrespective of any doze state; as I mentioned above, I proved that with a two-day test in the past). Every time such a "tick" takes place, a Tasker "task" fires off which decides whether any of these apps which are not currently in the foreground should be restarted (using various OS criteria and app-specific criteria). If so, it kills each of those apps (if running), restarts each of them, and then puts each of them into the background.

I now get my push notifications in a timely manner and with no problem ... finally! This procedure indeed eats a bit of battery, but not enough to bother me.

PS: Ideally, I'd prefer to totally avoid such a procedure and just have all my push notifications arrive reliably for all apps which make use of such notifications. Sadly, there doesn't seem to be anything I can do regarding Android OS parameters, doze parameters, or anything else which could make this happen. Until Android comes out with a better way to manage push notifications and doze, I will continue to make use of this Tasker-based procedure.
[Android Apps and Games] DiamondJohn:
The playstore you want is a system app, so by "uninstalling" you are really "uninstalling updates", and as such reverting to the system installed version. You could also add a boot script to uninstall any updates that occurred in the background. Not a perfect soln, but a help. A better solution would be a specific Java app to monitor and change/repair.

@HippoMan you may be proud and content with your tasker script, but I would really suggest test changing your doze profile to the Havoc one, as it appears to avert similar background issues on my device. You will not convert / convince me that tasker is the soln.
[Android Apps and Games] HippoMan:
To be clear, I never claimed that Tasker is the only solution. It's just one particular solution which definitely works for me.

I'll try the Havoc profile a little later, and I'll report back here with my findings. If it works, then so much the better, as I made clear in the "PS" to my previous post.

Thank you very much.
[Android Apps and Games] Extreme_Ninja2099:
Idk what ur on about with the play store not being a system app and this boot script. On all skins of android where gapps are installed, the Google play store will always be a system app. Anyways, it seems to have worked, and google play services no longer updates even without a boot script. Tbh I don't even know how to make a boot script anyways
[Android Apps and Games] DiamondJohn:
Read my post again.I said it WAS a system app.

As soon as you get an update, the update resides in the same place as non system apps; ie your data partition. By removing that component you revert to the one installed in your system partition.

What worked?

If you are talking about the favourites I uploaded, then it may only be a matter of time for it to fail; ie dont speak too soon ;). As I said, google have removed it from where they track app updates/versions, so I cant totally block when they try to do an update.

The boot script would not do any update blocking, but just automate the revert of any updates that do occur.
[Android Apps and Games] Extreme_Ninja2099:
Well your favourites .zip file method 3 is good enough. We'll see how long it lasts, but it's definitely working and Google play store isn't updating Google play services in the background. Hopefully, it'll carry on working even when a new version of Google play services comes out. Only time will tell and I'll let u know 🫡
[Android Apps and Games] DiamondJohn:
If you are running an older version of google play, then it has already been updated as far as your device is concerned, and will be attempting to sync the newer version. You don't need to "wait", its all happening now. And to be clear, this is all happening contrary to the way the detach has been designed to work. Its a hack, and hence I had to manually create the favourite(s).

For interest sake, run the detach check on GMS. Application Info / Manage>Detach Package From PlayStore>CHECK: The detach of a single package>com.google.android.gms
[Android Apps and Games] DiamondJohn:
And to be clear, I never said I thought that you believed it to be the only solution.
[Android Apps and Games] HippoMan:
I'm glad that we've expressed mutual levels of clarity.

So far, I am having tentatively optimistic results with that Havoc profile. Some push messages are indeed coming through in a timely manner.

However, I'm still not sure about some others because of being away from my device when those particular messages were actually sent and only seeing them much later.

I'll have more meaningful results to report here in a day or two.
[Android Apps and Games] HippoMan:
Further results: well, I'm sad to report that I have still been missing some push notifications when using the Havoc-OS-Oreo-Aggressive doze profile. The fravolt profile also looked promising to me, and I tried it as well ... and I also missed some push notifications.

WIth each of those profiles, I receive most of those notifications in a timely fashion, but approximately 20 percent of them do not show up until much later, only when I explicitly query for them in the given apps.

With both of these profiles, I am mostly in Normal and Light Idle mode, with an occasional drop into Light Maintenance mode. I never went into Deep Idle nor Deep Maintenance mode with either of these profiles. I got this info from the TeMeFI Doze Cycle Graph.

Some of these push notifications are related to my work, and I cannot afford to overlook them. I therefore have reinstated my Tasker methodology for the time being ... until a hopefully better solution might present itself.

In the past, I experimented with running the following every time my device boots:

/system/bin/dumpsys deviceidle unforce

That permanently kept me out of any kind of idle mode, and I received all push notifications in a timely manner. And I could manage with the increased battery drain.

But that's more like the "nuclear option", and I'd prefer to avoid it if at all possible.
[Android Apps and Games] HippoMan:
I have a question which is related to doze and maybe only tangentially related to TeMeFI, so let me know if it might be considered to be off-topic for this thread.

I understand that Android uses quite a few parameters to determine its doze behavior. Those are all the attributes of the various doze profiles that are available in TeMeFI.

But those attributes are limits. In other words, if the various doze-related parameter values exceed or fall below these limits, that affects the doze behavior accordingly.

My question is this: are the actual values of all of these parameters themselves at any given moment available to Android users? For one example out of many, one profile limit is "light_pre_idle_to". Is there any way that we users can query the value of that timer (i.e., not the limit, but the timer value itself) at any given moment? ... and all the other doze-related measures and timer values?

Or are these actual doze-related timer values, measures, etc. only available internally to the OS and invisible to us users?

If we could query these actual measures and timer values in real time, we could adjust our own doze behavior on the fly.

Do you know if anything like this is possible?
[Android Apps and Games] DiamondJohn:
Have you tested a standard Doze profile? 2 reasons

1. if it does not work, then it sounds like a bug/shortcomming in the app raising the notifications.

2 I started my "Doze Journey" because my device manage to get to deep-idle, BUT it had hundreds of wakes into light-idle. The switch was obviously draining battery. Your force wake negates any savings attained through doze.

If stock doze works, understanding why, could solve your issue. Just as I built comatosed to fix mine. My first knee jerk reaction is that you need to enter a light maintenance period on a regular period. That should simulate your script.

My understanding of what you need/are asking

You are interested about what is available in the shell, through a script, not Java.

You are talking the "LIVE" / currently running value

Then, using TeMeFI scripts, the answer YES.

To simulate (get you started) using TeMeFI

Get all the params using Currently Running>Doze>Dumpsys Device Idle History (dumpsys command)

Click the menu button to show the toolbar

Long Press the Magnifying glass, and type in "light_pre_idle_to=", and click OK (a grep command)

From there you can do a shell cut command to get the value after the "=" (not a method in TeMeFI, but examples throughout)

You can source the scripts to get the code of each step

EDIT: There is more than "limits" there are also factors that...well...factor the "limits"
[Android Apps and Games] HippoMan:
Yes. I originally was using the standard doze profile and was missing some push notifications. That's what prompted me to get started on this investigation in the first place.

Could be. However, I'm stuck with one of the apps which exhibits this problem. My client is a Japanese company who use LINE Messenger for messaging within the company. I have to use that same app in order to communicate with them, and it's one of the apps with which I have this push-notification problem. If they have an issue or a bug to report, I need to get those push messages in a timely fashion ... and I'm sure I can't get them to change their company-wide messaging app simply because using Tasker on my device to facilitate the receipt of push messages is less elegant than using doze profiles. :)

Indeed. Which is why I consider it to be a last resort.

Thank you very much. I need to figure out how to enter such a maintenance period. I assume that this involves one or more doze-parameter settings. I will investigate.

Yes to those points, and I'm glad for the affirmative answer. Thank you! I prefer shell scripts to writing an app ... although if it turns out that an app will do what I want more effectively, I might end up writing one.

Given that dumpsys deviceidle can give me all those doze-related live values, I will start from there.

By the way, Tasker is a very good tool for managing the use of these proposed shell scripts. :) It can respond to events and changes on my device, it can query the current live doze parameter values via dumpsys calls or scripts which make dumpsys or other system-utility calls, and it can then make programmatic choices in real time about how to alter doze parameters (via other dumpsys invocations), based upon my device's current state and behavior.

"factors" ... "limits" ... "constraints" ... "parameters" ... "settings" ... "algorithms" ... whatever :)

Thank you again.
[Android Apps and Games] HippoMan:
Yes. That app and many others have been excluded from the Battery Optimizer. That is one of the first things I do when installing or upgrading my OS.

Oh ... I missed that TeMeFI feature. Thank you. I'll check it out.

Of course. And anyway, I didn't have the problem with this and other apps before upgrading to Android 10. I have already reported this the app developers long ago. Furthermore, a number of other users do not have this problem with that LINE app. This is something related to my own set-up, I think, which is why I am spending so much time trying to figure out what is causing it on my device, so I can correct the problem.

Thank you for this.

Oh, so it's not worth trying to write this in Java, then. As I already mentioned, I prefer shell scripts, anyway.

I use the word "managing" simply to mean managing the entire state of my device by responding to events and to various states that the device gets into, and then taking whatever actions are appropriate. Of course in this case, that means triggering calls to dumpsys and perhaps other executables and scripts which would do the actual doze-related work.

Anyway, this is mostly semantics.

Good name. I use Tasker to fire off certain actions in response to intents. Some of these actions are full-blown invocations of executables, and some are just system-behavior modifications that Tasker itself can perform. In any case, I can't see any need for hundreds of these. But the five or six that I use are indeed useful to me.

One example: I have a script which I start on boot-up of my Android device which periodically checks to see if my device's external IP address has changed. T-Mobile causes those changes once in a while at seemingly random times. When that occurs, the script broadcasts a custom intent. When Tasker responds to this intent, it makes a REST call to a service that I have set up on my DNS server (I run my own DNS) which tells my DNS server to assign a specific domain name to that IP address. In other words, it's my own implementation of dynamic DNS for my Android device.

On my local machine at home, the firewall is configured to allow SSH connections from that one specific domain name and none others. This allows me to make SSH connections to my local machine at home via my Android device while blocking all SSH connections to my local machine from all other domains and IP addresses.

I know that I could accomplish this in other ways, but since I'm using Tasker already, anyway, getting it to respond to the intent and make the REST call is a simple procedure.

I'm not trying to "sell" the use of Tasker. I'm just explaining that there are certain things I like to do which are easy for me to accomplish using that utility's ability to respond to intents.

Of course, your mileage may vary.
[Android Apps and Games] HippoMan:
PS: I have now whitelisted one of those apps (the LINE app) using the Whitelist an App TeMeFI feature, and I turned off my Tasker-based procedure for the moment in order to test whether I am still missing some push notifications after whitelisting.

The app indeed now shows up in the TeMeFI list of whitelisted apps, so I will optimistically assume that this whitelisting procedure is functioning properly.

I'll report my results after running this way for a while.
[Android Apps and Games] DiamondJohn:
As I said, I have not tested the script in anger. I did note that

1. There is "USER" or "SYSTEM" whitelisting. Maybe either or both would make it work, IDK

2. I just tested putting TeMeFI in the whitelist, and the "Listing of whitelisted aps" did not report the change, so either my scripting is either lacking / doing something wrong, OR the method is no longer implemented or working (not uncommon in the android shell) or the reporting is just incorrect.

Another (probably the best way) to whitelist an app is modifying through magisk the whitelisted XML Config file. Last I saw it was full of PlayStore type things and maybe phone and sms components. The following search should get you started in the right direction:

android xml whitelisted apps at DuckDuckGo

DuckDuckGo. Privacy, Simplified.

duckduckgo.com

Actually, I had another idea to test. Systemizing it! which is a feature of TeMeFI ;) (priv-app probably) may give this app the privileges/behavior to break through doze.
[Android Apps and Games] DiamondJohn:
I am on a loooooong hold call, so I looked at the search, and found the following post which looks interesting . I actually did my first search on startpage (a google private proxy) and the results were better there

Doze whitelist and deviceidle.xml

I'm trying to add my package in doze whitelist. With ($ adb shell dumpsys deviceidle whitelist +PACKAGE), I can add my package in whitelist, and this command makes change in the file /data/system/

stackoverflow.com

Maybe the TeMeFI commands would appear here.
[Android Apps and Games] HippoMan:
Well, as I mentioned above, when I whitelisted the LINE app, it does indeed now show up in the TeMeFI listing of whitelisted apps. Maybe what you experienced is just an artifact of trying to whitelist TeMeFI itself with a TeMeFI-based procedure ... perhaps some sort of error related to self-reference ... ???

I only originally performed User whitelisting, but now I might as well try System whitelisting, as well.

Next I'll try systemizing the app, if I still am experiencing push notification delays after this whitelisting exercise. I need more time to test this before I take that subsequent step, however.

Also, I'm confused about what you said about not testing the script "in anger". You used that phrase in two separate posts, so I'm guessing that it isn't just a typo. But the meaning is lost on me.
[Android Apps and Games] DiamondJohn:
That phrase "in anger" simply means testing thoroughly in real world situations, to its full extent.

I think it originated in the military vernacular, as in "shots fired in anger" which are hoped to cause maximum damage, while its now common in the colloquial (AUS, US and ENG) and used to mean thoroughly / to its full extent. Like in shots fired to cause as much harm as possible, and thereby tests/usage engaged to elucidate the most effect; and in my usage in the real world.
[Android Apps and Games] HippoMan:
Thank you for explaining "in anger". I never heard that use of the expression, and I always like learning something new.

And I hereby announce that I am giving up on doze tweaking for the purpose of getting timely push notifications.

First of all, even when converting to system apps (both priv and non-priv), and even when whitelisting (both User and System), i miss some push notifications.

The TeMeFI doze cycle graphs show long doze periods with very tiny maintenance windows that occur extremely infrequently.

Furthermore, upon investigation, I learned that my device, the OnePlus 7Pro, is one of the absolute worst regarding the killing of background apps and regarding maintenance windows. The OnePlus company touts their devices and software as being excellent concerning battery life, and I'm now sure that they achieve this by means of these doze, maintenance-window, and app-killing procedures of theirs.

https://dontkillmyapp.com/problem

... and

https://dontkillmyapp.com/

... and I have already taken all the suggestions here, to no avail:

https://dontkillmyapp.com/oneplus

Because of all this, it seems like I am stuck with having to periodically force some apps into the foreground in order for them to receive push notifications in a timely manner on my device and my OS (stock Android 10 for the OnePlus 7Pro).

Although there is more than one way to do this, my Tasker-driven procedures are the easiest and offer the most ways to manage this in conjunction with everything else that is going on with my device.

Solving the problem in this manner is not ideal, but it seems to be the lesser of all the evils.

TeMeFI has provided very useful and helpful tools for diagnosing and analyzing this situation, and my thanks go out to you for having created this excellent app, and also for all your help and suggestions concerning this problem.
[Android Apps and Games] HippoMan:
Follow-up:

After more investigation, I have learned that this push-notification delay problem is a known issue that affects lots of users. It apparently started with Android 9 or perhaps even earlier. It even involves notification delays from the Google app Gmail!

I also learned that app whitelisting is nothing more than the way that the OS implements the turning off of battery optimization, and that this has no effect, whatsoever, on push-notification delays.

Furthermore, I learned that Android now utilizes something called "App Standby Buckets" which might provide a solution:

https://developer.android.com/about/versions/pie/power#buckets

As you can see, there are five of these which assign an activity priority to each app. This priority increases all the way up to "active", which means that the app is essentially in "foreground" mode with no network restrictions. Bucket assignments are performed automatically by the OS, but they can also be manually set as follows:

(or other levels lower than "active")

Assigning apps to the "active" bucket is supposedly tantamount to my current forcing of apps into the foreground, and I will see if this fixes my push-notification problem.

Perhaps the ability to assign apps to standby buckets could be added to TeMeFI.
[Android Apps and Games] HippoMan:
Never mind. It turns out that on my OnePlus device and OS, the standby buckets seem to be totally ignored. Every installed app is put into the "active" bucket, and this cannot be changed. And this has no apparent effect on any app's behavior.

Correction: every installed app is no longer being put into the "active" bucket. That was due to an error I caused myself, and I fixed it. Now, the standby buckets do show valid values which can be changed, but even if the apps in question are set as "active" or even "exempted", the missed push-notification behavior is continuing unabated.

Back to my original Tasker methodology.

I'm now done with this doze-related wild goose chase. Thank you to Google and OnePlus for hobbling my Android user experience and for giving me no way to correct this short of inefficient hacks.

And I thank you again (sincerely and non-sarcastically) for TeMeFI and for all your patience and help.
[Android Apps and Games] DiamondJohn:
@HipppoMan Waaaaaaaaiit a sec. Somewhere above you wrote how your specific device is known for killing off apps. Thats a completely different and new to me issue .

If the app is being killed by the system (as opposed to being set to a doze mode), then what you should really be looking at is setting the OOM value to "Superman".. And while your there I would also set the Nice value to the highest, and the IONice to the highest in addition to adding it in the Whitelist. You may also wish to test adding a swap file to ensure enough free RAM is available. All of these are available within TeMeFI. Another thing to check is the developer settings, I have seen there is a setting for the number of apps to keep in memory. I *think* it defaults to 4 in my ROMs, but can be set to 1.

I'm in a bit of a rush right now, so cant really read / respond much more, except.
[Android Apps and Games] HippoMan:
I did mention "killing apps", because that was itself mentioned in one or more places in the web articles that I referenced above, and I just repeated that. However, I know that the apps in question are not actually being killed. I have already performed a long-term test of my system in which one of the things I did was to periodically check the pids of those apps. And the apps never died over a several-hour period, even though some push-notifications were indeed missed during that time window.

Also, I previously had set the nice and priority and OOM values of those apps as you have specified, and this had no effect regarding the missed push-notification problem.

Anyway, this whole exercise has gotten to the point that it's as much of a headache for me as trying to keep up with all the convoluted issues that are being discussed lately in the Magisk thread.

I have a hack which functions as a workaround without draining too much battery, and that's good enough for me, at this point.