0

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.

0

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.

  • Yes, but I want to alter the way the device works with notifications. I don't want to disable the notification completely. I just don't want it to light up my screen when a song changes. Also I want it to keep lighting up the screen for other apps notifications. – mnd Jun 22 at 6:31
  • @mnd Sadly, I don't believe that is possible unless the app can do it within itself. However, since you have a custom rom and I assume rooted, there is a tool called Tasker which allows things to be set in a Trigger - Action method. You could set a Screen Off trigger and possible Action of disable notifications from the app, then the reverse when Screen On. Tasker is powerful, just not sure if it's granular enough for this task which is why I didn't include it in my answer. – acejavelin Jun 22 at 14:38
  • Yes, Tasker can do that, maybe secure settings plugin is needed for it to be able to disable notifications per app. The only issue is that once the notifications for AIMP are disabled, and afterwards enabled - it does not appear until the song changes (and the notification is updated). So maybe the question should be - how to request the app or android to recall the ongoing notification which had been disabled and reenabled for that app. – mnd Jun 23 at 6:28
  • @mnd Now you are really getting into tough spot... This could be done as apps can "see" if the display is on or off and I believe they can check if their notification is still active, but I think what you are asking for would have to implemented into the app itself. – acejavelin Jun 23 at 12:42
  • Probably. I agree that trying to use the original notification of the app, the way I described it, might not be possible (at least with 3rd party apps and not as a function of the ROM, or android in general). So I have come up with another idea - all I would need to do is create a temporary notification with tasker or something else, which would display the currently playing track information and open the music player, when clicked. If the screen is on long enough, this additional notification would be needed only until the next track starts. – mnd Jun 24 at 12:19
0

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.

Automate flow

0

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:

Start Flow

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.

Our Notification Flow

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.

Starter Flow, Update

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:

enter image description here

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!

  • Should these pictures be blurry to you (they are for me), you can click on the to get a full screen view. Should you have any problems or questions, ask me :) – ULTRACOMFY Jun 28 at 13:17
  • Once again, ULTRACOMFY, I can't thank you enough for your interest and such comprehensive help in my android challenges. Unfortunately I will not be able to try your solution for myself and provide feedback in the following couple of days. Looking forward to it, though, and I will post my experience as soon as I have the time to test it. After having a quick look, I can only add one thing - we can't assume that the player will always be started by the shortcut. For example, when the phone is connected to bluetooth, it opens up the player and that would not start the second flow, probably. – mnd Jun 28 at 14:10
  • Probably the bluetooth limitation could be easily solved by another flow which checks when the phone connects to a specific bluetooth device. But that makes it three flows for one task – mnd Jun 28 at 14:12
  • @mnd Sure! Your phone automatically starts the Media Player App when connecting to Bluetooth? That's cool! There is no built-in way that does "When user opens App X, automatically open Y". You always need an app for that. And such an app just continuously monitors running processes. You can do such a thing with automate. If you are okay with continuous process monitoring (consumes battery power), you can simply put "App foreground" with your Media Player as input argument. That way, you don't even need the first flow :) – ULTRACOMFY Jun 28 at 15:04
  • Yes, when connected to e.g. a car audio player through bluetooth, the music starts playing automatically, even if the music player app on the phone is turned off at the time. If monitoring the processes consumes more power than checking when the screen turns on and off, then this is not the preffered way. On the other hand, we could probably make a quick settings shortcut, which would turn on bluetooth and start the first flow. I hope having a quick settings tile, created and monitored by Automate consumes far less battery than monitoring processes or the screen state :) – mnd Jun 28 at 15:34
0

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:

Disable/Enable Notifications depending on Screen Activity State

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:

Notification

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.

Notification and Notification Cancel Script

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

NOTIFICATION

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.

Notification Cancel

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.

ENTIRE SCRIPT

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.

  • I'm sure I forgot to say something. There was something I wanted to tell you. Maybe it wasn't very important. For any questions, please ask :) – ULTRACOMFY Jun 30 at 0:10
0

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:

Automate Script

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.

  • Wow, ULTRACOMFY, you are on a roll :) really appreciate that. I hope I will be able to test all the solutions and compare which perform best and about the battery life. This will take some time, though. Because I don't get the chance to listen to music on the phone for an extended time, every day. But the most important thing is at first I thought that this type of customized notification handling is not even possible, and now you provided 3-4 different approaches. Which is spectacular and really demonstrates the flexibility of the app. – mnd Jul 1 at 7:34
  • I noticed that this approach is similar to yours in the answer. The only difference is, that you have "Media Playing?" and if no, do not pause/resume plackback already integrated into your flow. You don't need the other "Media Playing?" block when the screen is turned off though. This is the most energy saving method you can find. It might be a bit inconvenient to have to manually start this flow. In my other answer I told you how to Install Home Screen Shortcuts, this might be helpful. PLUS: Using Automate, you can disable a lot of power consuming features you would otherwise not be able to. – ULTRACOMFY Jul 1 at 8:48
  • I still haven't decided if I want to create a homescreen shortcut, or a quick settings tile to start and stop the flow. For now, I just keep the flow from my answer always running. I see a decrease in battery life, but it is not constant and I'm not sure it is because of Automate, unless Automate has something to do with com.google.android.location.ALARM_WAKEUP_ACTIVITY_DETECTION process. – mnd Jul 1 at 9:48
  • And about the "Media Playing?" block when the screen is turned off - I added it so that the notifications would not be turned off when the music is not playing. Because if I would leave the media playing check only with screen on - the next time I would start playing music, the notification would not appear at first, only after turning the screen off and then back on. – mnd Jul 1 at 9:55
  • @mnd What does this process have to do? By the way: Automate uses an intent to determine whether the screen gets turned off. Upon turning on/off the screen, the system broadcasts an Intent.ACTION_SCREEN_ON(/OFF)-Intent. Automate simply waits until this intent is received. I don't know which role your process/intent you stated up there has to do with that. To be honest, I'd prefer to find the reason WHY AIMP flashes the screen, while other notifications don't. – ULTRACOMFY Jul 1 at 13:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.