Improve NewPipe player notification

[absurdlylongusername]

Checklist

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I'm aware that this is a request for NewPipe itself and that requests for adding a new service need to be made at NewPipeExtractor.
• I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.

Feature description

Stemming from #12667 and #12565.

Android Auto default media buttons in the UI are those from the notifications. If you want to shuffle or other buttons to show up in the UI you have to change them in Settings > Notifications > Player notification.

Currently the player notification UI is very lacklustre.

There's only 3 buttons in the compact view, only 5 in the expanded view.
There is no seekbar, duration and current position of song, doesn't show next or previous song in the queue, and etc.
It's very limited and not very useful.

Below are two images comparing the player notification of Musicolet and NewPipe.

Expanded Musicolet vs Compact NewPipe player notification

Compact Musicolet vs Expanded NewPipe player notification

As you can see, Musicolet's compact notification has more buttons than NewPipe's expanded notification.

And Musicolet's expanded notification blows NewPipe's completely out of water with all the buttons and functionality it allows you to do without having to unlock your phone and go into NewPipe.

You can fast forward, rewind, shuffle, repeat/play once, previous/next song, see song duration and position, etc. all without opening NewPipe.

This is very convenient and a lot better than what NewPipe has at the moment.

---

Goal

The intended goal is to improve the player notification so it's a lot more useful and has better UX than it does now, similar to Musicolet's.

At the very least, whatever UI is available in the queue player UI should also be available in the player notification by default.

NewPipe queue player media controls UI

Android Auto

Although the limited UX of the player notification predates our Android Auto implementation (and it's something I've wanted to mention for a while), I was motivated to create this PR now due to Android Auto issues relating to media buttons not appearing in the UI.

If the primary goal above of improving the player notification is achieved, this would also fix the Android Auto issue by collateral, as it would have all the necessary media buttons in the UI by default.

However, I presume completing that feature would take a lot more time than adding some small modifications to the codebase to improve the player notification buttons for Android Auto only.

Given this, I would like to know which of the two approaches are better:

Solution 1

Improve the player notification system wide which would fix the media button problem with Android Auto collaterally.

Solution 2 (a lot quicker)

Make small modification to change the default notification buttons for Android Auto, as well as allow more buttons to be displayed.

Then implement solution 1 which will render solution 2 obsolete.

---

Which one of these solutions would be the best?

Why do you want this feature?

UX improvement to expose commonly used media playback functionality in the notification without having to unlock the phone and open NewPipe. Many popular media apps have this so we should have it too.

Additional information

No response

[Stypox]

NewPipe used to have a custom notification, but it was often very broken, and still didn't suit everyone. You can look through the 10s of issues closed by #3178 to understand why.

You seem to be on an Android version older than Android 10, that still did not support MediaStyle notifications. A compatibility RemoteViews notification is used there (and is built like that by NotificationCompat libraries which I believe do their best job given the limitations of RemoteViews). My notification on Android 15 has a seekable seekbar with duration and current position, like the notifications shown here: https://developer.android.com/media/implement/surfaces/mobile.

Even if we wanted to bring back the custom notification, we would encounter many roadblocks.

• In newer Android versions in order to play stuff you are basically forced to post a MediaStyle notification. Otherwise the system won't recognize your app as a player, and that will trigger a whole lot of other issues: https://developer.android.com/media/implement/surfaces/mobile. For example the actions available on Android Auto are sourced through the actions configured through the MediaStyle notification
• Custom notifications can be implemented only through RemoteViews, which is a very old API with many limitations over normal Views (https://developer.android.com/develop/ui/views/notifications/custom-notification). Given the limitations and given the wild amount of ways notifications get displayed in different shapes and sizes by different Android ROMs, it's hard to get the UI right on every device. There are also many bugs related to RemoteViews on older Android versions, e.g. icons may be badly rendered, text wraps wrongly, ...
• Updating the seekbar every second using RemoteViews basically means reconstructing the whole notification from scratch every second, which iirc used to cause lag spikes and/or the system killing NewPipe.
• I personally think Musicolet's notification is very cluttered and not very user friendly. NewPipe is meant to be an app usable out of the box, you shouldn't need to spend hours learning about and remembering the tons of icons available in the notification, and then having to aim correctly in order not to press the wrong button. Just do one more click and do whatever you want through the queue, which has labels next to the main buttons.

I also don't like how Android reduced the customizability of media notifications. They should at least have allowed users to have as many notification actions as they wanted. But not using MediaStyle is not an option unfortunately, given my points above, so we have to stick with it :-/. What we could do is to show a popup or a notification the first time Android Auto is connected, suggesting the user they can customize Android Auto actions from notification settings.

[absurdlylongusername]

You seem to be on an Android version older than Android 10, that still did not support MediaStyle notifications.

Correct.

I personally think Musicolet's notification is very cluttered and not very user friendly

Musicolet is a very widely used app with high ratings on the Play store, and vast majority of people would disagree with you.

Musicolet allows you to customize the buttons in expanded and compact notification. You can even choose stock Android notifications with max 5 buttons instead of using Musicolet's custom notifications.
Mine only has all those buttons and stuff because I explicitly chose it to be that way: that is not the default. Regardless, the default has more buttons than NewPipe and does not have a seekbar.

I personally have never used a notification seekbar nor do I care for it: I just want to see the song duration.

NewPipe is meant to be an app usable out of the box, you shouldn't need to spend hours learning about and remembering the tons of icons available in the notification, and then having to aim correctly in order not to press the wrong button.

This is just a false exaggeration. Musicolet is very usable out of the box, and nobody has ever spent hours understanding Musicolet's UI, (or any media player UI for that matter) and more than that you only need to care about the buttons you use. Nothing is ever that complicated, and I don't think you actually believe Musicolet's notification or any other media player UI requires that much effort to understand. The average human is nowhere near that stupid.

You can feel free to go look at the several reviews of Musicolet and see what they say (this one for example)

Moreover, most people don't use (or even need to use) the expanded notification for the simple fact that most of the necessary buttons are in the compact notification. All the icons in the player notifications have the same icon as they do in the app, so it's not like you are being presented with new information and you have to figure it out: if you already know how to use the app you already know what buttons to press.

I've rarely ever missed a button press, and it's pretty hard to do so unless you have Parkinson's or similar. Especially since most modern phones are basically phablets now, and I am using a Galaxy S8 which is significantly smaller than most phones nowadays; most users have a lot more screen real estate than I do, so the icons are bigger for them (and you) than they are for me; so the scenario you're talking about is extremely rare.

Musicolet is heavily acclaimed specifically for usability, customisability and being packed with several useful features in many of the reviews. Almost anything you don't like in that app can be changed, so saying any part of it is not user friendly is an objectively false statement in my opinion.

---

I don't think we should just outright NEVER plan to improve this just because it's complicated: it is not like it cannot be implemented (Musicolet literally already has it), it is just something that's hard to do. We have MANY other open issues for features that are not anywhere near as complicated (and also exist in many other apps) and even those still haven't been implemented; why close this one?

If a solution was proposed that works, is well coded, reliable, well tested, and consistent across all Android ROMs, it shouldn't be rejected.

I think you would agree with me when I say that most of NewPipe has not been worked on by the best of the best Android Engineers; this is just stuff that enthusiasts have worked on in their spare time (which is why development has been so slow).

It doesn't make sense in my mind to close the door on people offering to create solutions to problems many users of your app have, just because you yourself consider it to be too complex, considering other apps have already solved this problem.

It's not like you're going to be forced to fix it either: anyone can do it if they want to.

And from a UX perspective, any bugs or whatever are easily avoided by a toggle. The new notification not working as intended on your device? Just turn it off and go back to the stock Android one. This is basic UX which Musicolet also has.

---

Just to be clear: this issue is to improve the player notification. It is not to copy and paste Musicolet's notification into NewPipe. Even simply just adding more buttons to the notification would be an improvement. It should not be rejected entirely, because that's saying that we refuse to improve the notification despite there being obvious ways to improve it.

Closing this issue means that we are not even allowed to have an open issue that captures the fact that there are users that have a problem with the current player notification and want it to be improved.

It doesn't need to be done all at once: it can be done in stages with gradual improvements.

My primary principle for this is the simple fact that other apps already have this, so we know it can be done. Given this, it's simply a skill issue on the part of the developers, not something that cannot be done.

Also, nothing's stopping me or anyone else from just reaching out to the devs of other apps with better player notifications and asking how they implemented it.

[Stypox]

Ok so I just tested out Musicolet. They also seem to advertise against using the custom notification, although they don't explain why. See the warning sign and the strikethrough text.

Also, on Android 15 the seekbar in the custom notification is not seekable, and the notification is not visibile from the lock screen. And I'm pretty sure there are various other system limitations, if they put a warning sign on it.

Sorry for my rant about cluttered UIs, I'm very sensitive about this topic. But while that's just my opinion, the rest of the points I made are technical limitations.

I suppose one thing we could do is to post a MediaStyle notification, and post a separate notification just with additional controls, and get the best of both worlds (?). Let's keep this open, but I think we should accept any PR about readding a custom notification only if the code is perfect and well tested under many scenarios, and with proper user-facing explanations of the limitations.

In any case, I don't believe this would solve Android Auto issues in any way, because the Android Auto actions are sourced from the actions available in the MediaSession, which are only as customizable as they are already now in NewPipe.

And from a UX perspective, any bugs or whatever are easily avoided by a toggle.

Mmmh, I strongly disagree with this. Users might forget that some feature can be disabled, and then remain stuck with bugged functionality. And in any case having a bugged implementation is worse than not having an implementation at all. We need to keep a good equilibrium between satisfying power users and making the app straightforward to use for beginners (even beginners that accidentally toggled some setting at some point).

[absurdlylongusername]

Thank you for reopening the issue.

I don't have a strikethrough on mine, and I presume that's because you are using Android 15 and I am using Android 9. I guess since all the functionality in the custom notification can be done through stock Android on Android 15, using the custom one is not recommended or necessary.

Sorry for my rant about cluttered UIs, I'm very sensitive about this topic. But while that's just my opinion, the rest of the points I made are technical limitations.

That is fine, I can understand as I'm also a bit sensitive about it. The technical limitations are valid points.

In any case, I don't believe this would solve Android Auto issues in any way, because the Android Auto actions are sourced from the actions available in the MediaSession, which are only as customizable as they are already now in NewPipe.

Not sure I understand this. Can you elaborate? Are you saying that adding more buttons to the default NewPipe notifications wouldn't mean they would appear in Android Auto?

Users might forget that some feature can be disabled, and then remain stuck with bugged functionality.

I can admit to experiencing stuff like this myself (mostly in IDEs), but within the context of what we're talking about I don't think this is a likely occurrence, since media notification settings are not very niche, and the average user would be able to put 2+2 together, unless the bug in question is esoteric and affecting unrelated components of the application.

And in any case having a bugged implementation is worse than not having an implementation at all.

This of course depends on the severity, frequency and reproductive steps of the bug. If it's only happening on specific niche OSes or only in rare hard to reproduce scenarios, then it wouldn't warrant reverting the implementation and having a toggle would suffice.

If it largely works as intended and doesn't work for a small minority of people, the toggle would still be a good enough middle ground for the people it doesn't work for and allow other users to enjoy the functionality while we would work on fixing issues for those where it doesn't work properly yet.

---

Correct me if I'm wrong, but I consider this to be 3 separate categories.

1. Android 7-9
2. Android 10+
3. Android Auto

For the sake of being organised, would it make more sense to have a separate issue specifically for the Android Auto part of this?

[lovegaoshi]

from what i remember to make buttons appear in android auto you'd need CustomActionReceiver for exoplayer2 or mediaSession.setCustomLayout for media3 if opted to media3's default notification management. the android system notification UI is a complete mess with android <10 and android > 12. Android auto also supports many more buttons than the system UI max 2 custom + 3 stock (play/pause, next, prev) - they will show up as a little drop down arrow.

im very interested in yoinking the notification codes if you ended up implementing a non-stock android UI notification + android auto. I think its more straightforward for media3 but i never got around how to make custom media3 notifications to begin with.