IssueTracker

Please find the complete bugreport here:

https://drive.google.com/file/d/1r57hcnfHuoZuLCvkwH3mUYVIbeHRMH3Q/view?usp=sharing

Steps to reproduce:

1. Open Spotify app and start casting to another device (Google Home Mini in my example).
2. Click Home Button (Spotify app is backgrounded, system launcher is visible).
3. Click the Volume Button (up or down) - the system adjusts the local music stream volume and does not pass the information to the Spotify app (actually to its VolumeProviderCompat configured for MediaSessionCompat).
4. Turn off the screen.
5. Click the Volume Button (up or down) - the system skips the event and does not pass the information to the Spotify app.

So the issue happens both when the screen is on and off.

Following the same steps on Android 11 was resulting in a different behavior - the volume button click events were passed to the Spotify app. Please see the "Android_11_logcat.txt" attached to the previous comment.

Android 11:

D/MediaSessionService: Adjusting com.spotify.music/spotify-media-session (userId=0) by 0. flags=4116, suggestedStream=-2147483648, preferSuggestedStream=false

Android 12 beta 5:

D/MediaSessionService: Adjusting suggestedStream=-2147483648 by 0. flags=4116, preferSuggestedStream=false, session=null

I can also offer my help by creating a Github repo with a project that reproduces the issue. Please let me know if this is needed.

This is a very important feature for users of my app and since it is a regression in Android 12, it will be kind of inconvenient to explain them that it is the platform issue and not the app issue which I can fix.

Please let me know if there is anything else I can provide to help you solving the problem.

+1 to above questions. Is there any workaround for receiving volume key events on Android 12? (that we could use until the Android 12.1 with the fix is released)

Is it fixed in Android 12 final ?

Has it something to do with legal regulations regarding (high) volume levels somehow ?

In any case, it is an annoying issue since (among other things) it breaks on Android 12 the ability to perform Chromecast volume control when the casting app is not in the foreground, including when screen is off.

Would it be possible to increase the priority of this ticket? It seems like the amount of irritated users will be increasing rapidly as of now, since people have already started upgrading their devices to Android 12.

Also, please consider reopening the following issue: https://issuetracker.google.com/issues/196528545

It is related to the same thing.

Nothing can be done until it is eventually fixed in Android 12.1

What I fear the most here is they say we will mitigate in 12.1 and as always they will forget all the other use cases than their Chromecast. Some app cast to many other things setPlaybacktoremote is vital for those.If the legal issue is about Chromecast leave it for the others.

^^ Look at fancy pants up here with their "universal remote", self-righteously implying 118 Android developers and enthusiasts above off-kilter in their desire for the return of a method of device interaction that has existed for at least 7 years. Elementary usage scenarios as per aforementioned benefit least from the disconnected deactivated functionality described in this issue.

Changing the Surround sound mode from the default of Auto to Stereo has no effect from what I see. This setting looks like it only exists on Chromecast device settings, and not other cast devices such as Home speakers, or the Home Hub displays.

I have only found a few ways to control volume. None of which allow control with the screen off.

• Screen has to be on to control volume
• Volume control from casting app itself while active (eg: YouTube, Spotify)
• Two locations in the Google Home app
  • While Media tab page is active
  • Select device itself, while volume dial is Connected and only on that screen

Switching away from any screen listed above will detach control of the volume.

This is very annoying when one YouTube video is much louder than the previous. If it's late at night I want to be able to quickly turn down the volume. In the past I could quickly turn it down with the volume rockers on the side of the phone. Didn't have to wake or unlock.

Now I rush over to the main amplifier volume knob to turn it down! Either that, or I have to [quickly] get to one of the app locations listed above to gain control.

Somewhat of a workaround is to wipe the dust off that older phone. Then get it connected to the same cast session.

My main phone is a Pixel 4XL. My old phone is a Pixel 2XL. I keep it around because it still has a great camera. It also works great to control the cast volume when the screen is off.

What was the mistake is 0 communication to users and devs for something that was known with large UX impact.

You can't imagine the number of mails and bad rating received from users no more able to control their volume when casting from well casting apps (not all apps are about Chromecast).

1 line in Android 12 app behavior change was all that was necessary for devs to prepare for the wave and warn users.

To this day, there's still 0 note on Android 12 page changes and still devs loosing time after being assaulted by users to understand what is going on until they find out this issue.

To everyone who comes here just to write abusing comments: please stop it. I did NOT create this thread to abuse or blame anyone. This is not the way the community should act.

I am sure that all the people who subscribed to this thread don't want to read such comments. People prefer to receive valuable emails with status updates. If you are affected, please star the issue.

Regarding the issue itself: it is very serious to me, since it affects the core functionally of my app and I have to face hundreds (soon thousands) of irritated users.

To Google Team: is there any timeline on when you are planning to tackle the issue? I would like to know what should I communicate to users of my app. Thank you in advance.

According to Mishaal Rahman (Senior Editor on XDA) on Twitter, looks like there is a workaround included in the 12L beta release today. Can't control volume with the physical volume buttons, but the cast volume level is now included and enabled on the volume panel pop-up.

See his thread on Twitter

In response to #144: Unfortunately this is not a solution to this problem. Allowing apps to react for hardware button clicks is crucial in this case.

I have just tested this on S2B1.211112.006 build and the issue is still present. Volume button click events are still NOT provided to VolumeProviderCompat when a remote MediaSessionCompat is registered. Therefore, the behavior is still inconsistent with the documentation.

Repeating my previous question to the Google Team: is there any timeline on when you are planning to tackle the issue? I would like to know what should I communicate to users of my app, since they are becoming more and more irritated :(

I hope to be able to provide a more general update shortly. In the meantime, some specific notes for the attention of the original reporter:

I have just tested this on S2B1.211112.006 build and the issue is still present. Volume button click events are still NOT provided to VolumeProviderCompat when a remote MediaSessionCompat is registered. Therefore, the behavior is still inconsistent with the documentation.

Are you sure about this? I flashed the same build and tried the reproduction steps exactly as specified at the top of this thread. Volume adjustment with the hardware keys worked for me, with the app backgrounded and with the display both on and off.

According to Mishaal Rahman (Senior Editor on XDA) on Twitter, looks like there is a workaround included in the 12L beta release today. Can't control volume with the physical volume buttons, but the cast volume level is now included and enabled on the volume panel pop-up.

Mishaal appears to have been testing with YouTube Music. Confusingly, volume adjustment when backgrounded doesn't appear to be enabled for YouTube Music at all, on any device or Android version. The YouTube Music team are looking into this. For the purpose of testing the underlying platform behavior, please test with other apps that support Cast.

Replying to #148

Are you sure about this? I flashed the same build and tried the reproduction steps exactly as specified at the top of this thread. Volume adjustment with the hardware keys worked for me, with the app backgrounded and with the display both on and off.

I tested it again on S2B1.211112.006 and I observed that the behavior is inconsistent. Initially, when I started casting music, it was not working - after backgrounding the app I was pressing hardware buttons and the device was changing the volume of its local music stream (despite the fact that the music was playing on the remote device I was casting to).

Then I stopped casting, entered the app, started casting again, backgrounded the app and it was working (!) both when screen was on and off. When I was pressing volume buttons, the volume on Google Home Mini was adjusted (great!). The volume popup with the slider was not showing up after pressing the button (on Android 11 it was visible, with a casting icon). However it stopped working itself after a while (a few minutes) - the casting session was active all the time.

Then another restart of the casting session, but it didn't work. After multiple tries of starting and stopping casting, it worked again. And this time it was working until I stopped casting (around 5 - 8 minutes).

Then another restart of the casting session, but I didn't manage to make it working again.

I tried to find some pattern on when it starts/stops working, but I couldn't. It seems to happen randomly now. And I think that comment #150 confirms that.

I recorded a bug report, maybe it will help with finding the root cause. Here is the link: https://drive.google.com/file/d/1-GHq0EiUvkKc350yzovtyot9SOEQ1tR5/view?usp=sharing

Please let me know if there is anything else I can test.

Yet another reply to #148

I have created a Github repository with a very simple app which allows to reproduce the issue. The details are described in README file.

Basically VolumeProviderCompat still does not get information about volume button clicks. I have tested it on S2B1.211112.006 build (Android 12).

On Android 11 the example app works fine.

To Google Team - please have a look at the above example. Are you able to reproduce the problem now?

I think it's important to decouple:

1. Adjusting the volume when casting from many popular applications, which is what most of the posts on this issue are referring to.
2. The more technical question of volume button clicks being delivered to VolumeProviderCompat.

(1) should be enabled in Android 12L for the vast majority of use cases, although there are a couple of exceptions that are confusing things somewhat (e.g., YouTube Music, as discussed above). I am following up on these exceptions.

You are correct that for direct use of MediaSession as implemented in your demo app, (2) is not enabled, and I am able to reproduce this. The way we've enabled (1) is that when there's a media session using remote volume control functionality, we look at properties of the corresponding media routes that are selected by the process. Cast integrates with MediaRouteProvider/MediaRouter, and so the underlying framework is able to query the selected media routes. Your demo app does not do this, and therefore volume button clicks are still not routed as you'd expect. For Cast-like use cases (but using some other non-Cast protocol, for example DIAL), we would still expect apps to integrate with MediaRouteProvider/MediaRouter, which should be sufficient for volume button clicks to be delivered.

I appreciate that (2) is not as documented, and is something that we'll continue to look at resolving. I also wonder whether you have a use case that requires direct MediaSession integration but where integration with MediaRouteProvider/MediaRouter is not appropriate, or whether you've just done it this way in your demo to provide a minimal example. It's somewhat unclear what the initial motivation was for filing the issue, since the initial description contained both a description of (2) and reproduction steps that fall under (1). If you have such a use case, it would be interesting to understand it in more detail. Thanks!

Exactly what I feared when they said workaround :)

My app can play and cast media to Upnp devices, Roku devices, Fire TV devices, Kodi and a few more, my users expect volume control when screen off to work in all those cases and not just when casting to Chromecast (that I support too).

VolumeProviderCompat was the only proper way to achieve that properly, including proper description if the devices supported discrete volume values or only +/- commands.

How are we supposed to do that with MediaRouteProvider/MediaRouter? (Considering too that MediaRouter currently force embedding AppCompat/Recyclerview/ ... and is unwanted in a pure compose world see https://issuetracker.google.com/issues/210099272)

Re #157, I think your use case falls exactly under:

For Cast-like use cases (but using some other non-Cast protocol, for example DIAL), we would still expect apps to integrate with MediaRouteProvider/MediaRouter, which should be sufficient for volume button clicks to be delivered.

If the underlying framework can query the selected media routes for your process, then I think volume button clicks will be delivered to your VolumeProviderCompat as you expect. For Cast-like use cases such as the ones you describe, we generally expect apps (or the SDKs that they're using) to integrate with MediaRouteProvider/MediaRouter, like the Cast SDK does, which is sufficient to allow the underlying framework to do this and therefore for volume button clicks to be delivered. My understanding is that some other apps that use DIAL also do things this way, which is again similar to your use case.

How are we supposed to do that with MediaRouteProvider/MediaRouter? (Considering too that MediaRouter currently force embedding AppCompat/Recyclerview/ ... and is unwanted in a pure compose world see https://issuetracker.google.com/issues/210099272)

I think you should be able to do the same thing that the Cast SDK does. Implement a MediaRouteProvider to inform the platform about available non-Cast routes, and integrate with MediaRouter so that the platform knows which route is selected.

The issue you link to seems to be at best tangentially related. I'd also note that if you support Cast then you're probably depending on play-services-cast-framework, in which case I think you'll already be pulling in androidx.mediarouter:mediarouter as a transitive dependency as per the POM file. If that's the case then I don't think also depending on it directly would make any difference to your apk size.

Replying to #156

Thanks for the detailed explanation. Answering to your question:

I also wonder whether you have a use case that requires direct MediaSession integration but where integration with MediaRouteProvider/MediaRouter is not appropriate, or whether you've just done it this way in your demo to provide a minimal example.

The use case of my app is that it needs to receive events about button clicks (also when the screen is off) in order to interpret them and execute some actions if needed. By actions I mean e.g. integration with other apps via MediaController objects queried from MediaSessionManager in order to e.g. control the playback.

So technically my app doesn't need to use MediaRouteProvider/MediaRouter, it just needs to be notified when a volume button is clicked (both when pressed and released).

In the ticket description the reproduction steps I described were referring to (1), as I believed that it be easier to understand that way. Right now I think that we can treat the example app and the "Steps to reproduce" from its README file as a reference.

I disable transitive, have my own copy of media router and the gain is more than 1 MB in total so nearly 40% gain ... Same reason I don't update to cast 20.x+ as it add 350Kb and there's nowhere to report that. So if we are now forced to use that lib to control volume it's kinda related even if only by side effect. Even if easy maintaining a copy of media router is evitable pain is it's splitted.

About mediarouterprovider those routes should not be selectable by other apps at all. I don't think that it's possible to have them private to the app or media session, or it's not documented.

Re #160:

Same reason I don't update to cast 20.x+ as it add 350Kb and there's nowhere to report that

It looks like you can report issues with the Cast SDK here: https://issuetracker.google.com/u/0/issues/new?component=190205&template=814901

About mediarouterprovider those routes should not be selectable by other apps at all. I don't think that it's possible to have them private to the app or media session, or it's not documented.

According to the MediaRouteProvider documentation:

A media route provider may be used privately within the scope of a single application process by calling MediaRouter.addProvider to add it to the local MediaRouter. A media route provider may also be made available globally to all applications by registering a MediaRouteProviderService in the provider's manifest. When the media route provider is registered as a service, all applications that use the media router API will be able to discover and used the provider's routes without having to install anything else.

I'm not sure, but it may also be possible to use MediaRouteProviderService with android:exported="false".

Nice to see Cast is now on the tracker, will report the size issue.

And thanks for the doc pointer, I always stopped at https://developer.android.com/guide/topics/media/mediarouteprovider that fully emphasis on the discovery by other apps and the service.

Since migrating to that still wont solve Android 12 issue and it's quite some work, can you confirm the meaning of "I appreciate that (2) is not as documented, and is something that we'll continue to look at resolving." Does it means the docs will be updated to explains it won't work in the future, or that there's still hope something is done for 12L or for a future later release?

On Android 11 (not sure about 12L, since I did not test), it is very well possible to receive VolumeProviderCompat events (hardware volume buttons changes when app is playing in the background, with screen eventually off) outside of any route management with:

mediaSession.setPlaybackToRemote(volumeProvider); mediaRouter.setMediaSessionCompat(null); // for volume control by VolumeProviderCompat rather than a route

I hope this functionality will still work on 12L.

On Android 11 (not sure about 12L, since I did not test), it is very well possible to receive VolumeProviderCompat events (hardware volume buttons changes when app is playing in the background, with screen eventually off)

Unfortunately it still doesn't work that way on 12L (at least yet).

This example app allows to reproduce the issue - it uses only the MediaSessionCompat and VolumeProviderCompat, without the need to implement MediaRouteProvider/MediaRouter.

I also hope that we will get this functionality back, otherwise my app will be useless (reacting for volume button clicks is part of its core feature).

Yup confirming it's not working (using MediaSessionCompat + VolumeProviderCompat) on 12L with my app. Though Chromecast volume backed by a Route is working. I also hope that it will be fixed to work like it did prior to Android 12, so a Route is not required. My app handle playback (and volume control) to external devices without the complexity of using a Route. I also notice that in 12L, the media notification always mention "Other device" in the top-right corner, even when a Chromecast is made active by setting its route current.

A bit of news regarding the legal side of it: https://www.androidpolice.com/google-pixel-chromecast-and-smart-speakers-may-be-banned-from-us-sale-following-sonos-lawsuit-loss/