How to prevent an app's notification from updating while the screen is off?

Question

I have a bootleggers ROM (Android 9 pie) installed on a Motorola Moto E 2015 phone. I have a setting, enabled in adaptive display settings, which makes the screen to turn on, when a new notification is received. It is a good feature, but my music player (AIMP) updates it's notification each time a new song starts playing, which makes the display to turn on (pulse) often and use additional battery. I could avoid that by turning off the notifications for AIMP completely, but I want to see the notification when the screen is on.

Is it possible to prevent the notification from updating while the screen is off?

Another way to solve this would be to turn off the notifications for AIMP, when the screen is turned off, and then turn them on again when the screen turns on (using tasker, for example). But the drawback of this approach is that once turned on, the notification does not appear until the next song, so it is not possible to see the current song in the notification this way.

Answer 1

The preferred way would be if your media player has an option in it's settings to disable notifications, do it that way.

The other method would be to use the embedded features of Android to disable the notifications, when a notification from your media player pops up, pull down the notification shade and long-press the notification tile, and select "Stop Notifications". This will disable the notifications by taking away the apps permissions to do so. To re-enable notifications, go to Settings - Apps and find the apps, and turn the notifications back on there.

Otherwise the device is working exactly as designed with the settings you have.

Answer 2

So, this may not be the most sophisticated solution, but I managed to do this by using the Automate app. This is not a universal solution for every app's notifications either, but it works for controlling a music player's notification (for AIMP at least), and that was what I wanted to do.

I used the "Display on" block to check when the screen is turned on or off. Also I added the condition to check if music is playing (using the "Media playing" block), so the notifications are only toggled on and off when the music is playing. And for the actual toggling of the AIMP's notifications I used the block "App notifications set state". Finally, to make the AIMP notification actually appear after it was enabled, I used the block "Audio player control" twice to pause and then immediately play the music again. This way the notification appears without waiting for the next song to start, and since the pause and play actions are executed in sequence without a delay, there is no audible pause in the music.

Currently, the only thing I would like to improve is to change the condition which checks if music is playing to a condition which checks if the music player app is started and would only then check when the screen is turned on and off. In hope that it would help save some battery. But I will have to see if there is a difference in battery consumption with my current Automate flow enabled and disabled. Maybe the constant check for screen on/off doesn't affect the standby battery consumption.

Also, I have to note, that I had achieved the same result using Tasker and Secure settings plugin. But it seemed this approach was not as responsive as Automate's way. This may be because my phone is quite low spec and there would be no difference on a more powerful device. But based on my short experience with Automate, it seems to be better optimized for my device and my typical usage. Probably because Tasker has to use an additional plugin and Automate has the functions I need built in. Though, if anybody's interested in the Tasker way, I may edit the answer to include it in more detail.

Answer 3

Nice question you have there. To solve that, I recommend you using Automate, which, apparently, you already do. You want to prevent your Music App from flashing the Ambient Screen every time it sends a notification, and you want to have that solved with Automate in a way as efficient as possible. First of all, it is important to have a Flow that only runs when your Media Player is running. As you cannot set "Media Player Running?" as a condition to start your flow (You could make another flow that waits for your Media Player to start, but any way, you always have one flow running all the time), you can do a little workaround: You can start flows just WITH your Media Player App by using Automate. Make a flow that starts your Media Player AND the flow that enables/disables notifications later on:

This flow, when launched will start the Media Player and another flow that I'll show later on. Now: On the default Android Home Screen, you can add Shortcuts. For that, you can go into the Flowchart Editor, click the Flow Beginning block and then "Install Home Screen Shortcut". When you choose the flow we just created, you can open the flow and the media player by clicking on your new home screen button.

Now, we still need to properly control the notifications to prevent them from appearing while the screen is off whilst considering your wishes. Automate CAN check whether an app is running or not. When using the flows the way I described in here, we know that the Media Player WILL be running. What we can do is to stop the flow when it detects that the Media Player has been closed.

We want to prevent the Media Player from posting notifications while the screen is off. So, what we can do is to prevent the player from showing notifcations at all. We have a condition: Player Update == true | AND | Screen == 'on' But, we are smart: We can simply wait for the player update, and THEN wait for the screen to turn on. This is most power efficient way. We have one programming step each time the track changes/is paused/is resumed/etc - We simply force a notification each time the track changes, or when the screen is turned on the next time after the last track change.

You are using the "Enable Notifications" block. In my example I chose "App OP mode set" which is because I use that block a lot for other things, but your block should be fine too. NOTE: Disabling notifications whilst the screen is on might cancel the notification. If that applies to you, and the flow immediately cancels the notification after the Media Player posted it, you have to add a block that waits until the screen is turned off again. ANOTHER NOTE: The first "Is Display On" is set to 'Immediately', whilst the second one is 'When changed'. This together makes a "Wait until: Screen On". You could also do that by using a "Is Display On" block set to immediately, where NO connects back into the input of the block, thus create a loop, but we don't want to have that.

Now, for battery efficiency we want to stop this flow when the Media Player is stopped. I thought it would be easy, but actually isn't. Automate has blocks to see which app is in foreground, but doesn't directly offer blocks for "Process running?". This has two obvious workarounds: Shell Commands. Linux offers the "ps" command to view running processes, and Automate can run Shell Commands, but there is a way much easier than that: Android Usage statistics. Android holds record of when which app has been used. We can make use from that and determine whether the app is being used right now. Because, when the last time it has been used is longer than 60 seconds ago, we can safely assume that it is closed right now. So, we check whether the app is running by comparing "App last time used" to "Current Time", and if these values are about the same, the app IS running.

With the "App Usage" block we can determine the moment an app has been used, and assign that value to a variable. I called it "Time". You get that block, and choose your Media Player as app package. The timestamp values can be ignored. With the "Expression True" block, you can now compare that value to current time:

I also added a 5 second buffer. Between the moment the app usage data is retrieved and the moment this block will be checked will pass some time, which might lead to the effect that it will always say that "Last Time Used" is smaller than "Now". NOTE: "Now" is a built-in variable. You do NOT need to replace that one.

Should the result be NO (App Running), it will wait 2 minutes until it asks again. I thought about a "Media Playing" set to "When Changed" block, but that would collide with the five seconds buffer. Should the result be YES (App not Running), it will proceed into a "Fiber Stop" block. With that block, you can stop specific fibers, even in other flows/scripts. All you need to do is to enter the URI the Notification Control flow has. You can find that one by going into the script of the Notification Control flow, clicking on the Flow Beginning block and scrolling to the bottom.

After all, you now have two flows: The first flow opens the Media Player and the Second Flow, then waits for the Media Player to stop and then cancels the Second Flow. The second flow controls the Media Players' notification by disabling them entirely, waiting for a track change, then forcing a notification, but only when the screen is on.

NOTE: My player is weird (I don't like to use it in general) and only reacts to Play/Pause. Usually, when you have an "When Media Playing" block set to "When Changed" it reacts to track changes. With my current player, it doesn't. Should you have the same problem, you can save music title into a variable and periodically compare that title to the title of the current track. I hope it doesn't have to come to such a thing. Good luck!

Answer 4

I have read through the comments of the other answer that has been posted and can come up with an answer: Yes! Just keep in mind that this solution DOES NOT feature Media Player control buttons.

What we want to do is two things:

1) Prevent the Media Player from posting Notifications while screen is turned off

2) Create a Notification when the screen turns back on, and only when the media player hasn't already created one. PLUS, delete our own notification as soon as soon as the Media Player posts one again.

The first thing is easy:

Utilizing the power of a "Display On?" block set to "When Changed", can precisely enable or disable notifications for your player app. When the screen state changes to off, the fiber will proceed through No. The AppOp block disables the permission to post notifications. You used the Allow Notifications block before, you can use that one either. After disabling them, the fiber returns into the "Display On?" block. Now, when the screen changes into "Turned On", it will proceed through Yes and execute the other AppOp block, enabling notifications again.

Now, this script is easy and will be running alongside our script that creates a notification as soon as the screen is turned back on. This will come in the second part:

The "Display On?" block at the very top is the first block we need. It is set to "When Changed" and only proceeds when the display is TURNED ON. As soon as that happens we want to know whether the Media Player has already posted a notification. To do that, we can use the "Notification Posted?" block (which, in the flow is labelled "Has notification"). It is set to Immediately and simply asks whether an app has posted a notification or not. Our app in this case is your Media Player. You need to write that into the block. If it already has, we don't need to create a notification, so the fiber returns to "Display On?". If it has NOT created a notification, we proceed to create our notification.

You want that notification to tell the Title and the Artist and or Album of the current running track. To find that info, we use the "Media Playing?" block set to "Immediately". You can assign a lot of values to variables, including Title, Album, Artist, Duration (in sec), Current Position (in sec) and more. Only Title, Album and Artist are relevant for us now.

Now, you need to listen up. We cannot simply tell Automate to cancel the notification after "Time X" (Timeout) or when "Media Player Changed". We need to do that manually. Automate does not feature a Timeout option for notifications (I'm not sure, but I think it did a long time ago..). So, we make one script that posts the notification and waits until it is clicked to open the Media Player, and make another one that CANCELS this notification as soon as the Media Player posted one by itself.

The script on the left creates a notification. It is set to "When clicked".

In this notification, you can set Title and Message. Instead of entering plain text, you can also use the content of variables, as known from java.println(). Be sure to go into Variable Enter mode, as it will otherwise process "Title" as text. You would then see "Title" in the message of your notification, not the content of the variable.

After that block, we can proceed. When you click the notification, the fiber will proceed through Yes and go into the "App start" block. In here, you can enter the package of your app. So, as soon as your notification is clicked, it will open the Media Player. PLUS: The notification already shows the title, album and artist of the currently running track. Now we just need to cancel the notification.

We cannot just wait until the Media Player has posted a new notification. That is important! We must wait until the TRACK HAS CHANGED.

In this part of the script, the fiber enters the "Media Playing?" block. This one is set to "When Changed" no further input arguments (other than the app package). It is just there to wait until the track has been changed or paused. As soon as that happens, we now want to remove our notification. To remove a notification using the "Notification Cancel" block, we need to specify the ID of the notification we want to remove. We don't have it, right now. BUT, the "Notification Posted?" block can help with that. We use the "Has Notification" block, and check whether the com.android.automate has posted a notification, and if yes, assign its ID to a variable. NOTE: Beware of the "Running..." notification! If you don't have it disabled already, you should do that now. Automate might return the ID of THAT notification, which is not the one we want to remove.

Now, the fiber continues into the Notification Cancel block, in which you need to enter the ID variable. As soon as the notification is cancelled, the Notification Show block will proceed through the NO-Path. This one leads back to "Display On?" at the beginning.

NOTE: We cannot wait for the Media Player to post a notfication instead for the track to change! Would we wait until the Media Player posts a new notification, we could have THIS scenario:

Screen On - Automate posts notification - Screen Off (Automate Notification persists) - Media Player track changes (but does not send a notification, because the screen is off) - Screen On - Automate still shows the notification from the track before (The notification is outdated).

The "When track changes" will delete Automates' notification. When the screen is on, the Media Player will post a new notification. But when the screen is off, our current notification will be deleted, and a new one created as soon as the screen is turned back on.

Here is the entire script with all of its parts. NOTE: Be aware of these Fork blocks. I haven't mentioned them in the answer.

I've uploaded this script to the community. You can find it HERE. You now simply need to change the values in the blocks and the names of the app packages.

I hope this helps you! Good luck!

EDIT: This script does not include features my other answer did. This script does not automatically stop as soon as the Media Player is closed. And so far, you also need to start this script manually. Both things could be included though.

Answer 5

I've finally found the ultime answer to your question. I didn't think it would be that simple. I was blinded by the thought that immediately pausing and resuming playback would create an audible interruption. But you said it doesn't, so here it is:

Simply disable notifications when the screen is off, re-enable them when it does back on and force the first notification. Done.

One thing I kept thinking about: What if there was no playback? Any way, every time you turn on your screen, this script would resume playback. Even if you just paused it for a minute. That problem would be easily solved by asking for Media Playback right after the "Screen On?" block. Should it return "No" by proceeding through that path, you would just go back into the Display On? block.