"Mute" button does not resume playback on Android Auto

Support
1

Issue description:

While using Symfonium on Android Auto (latest stable 13.5), there is a problem with “Mute” button. If it pressed once - music is stopped (correct behaviour). If I attempt to resume music using the same “Mute” button on my wheel, music does not resume.

The issue does not occur on Spotify, Pulsar Pro, Musicolet - “Mute” button works there the same way as “Play/Pause”.

Logs:

Upload description: cookie_drummer

Additional information:

 

 

Reproduction steps:

 

  1. Start Android Auto.
  2. Play any local music on Symfonium player.
  3. Press “Mute” button on the wheel → music will be paused.
  4. Press “Mute” button on the wheel once again → music is not resumed.
  5. Keep pressing “Mute” button on the wheel x times → music is not resumed.
     

Media provider:

Local device

Screenshots:

     

2

The logs shows that it works the app receive pause and play commands and properly react to them.

2025-01-14 18:42:30.638 Verbose MediaSessionCallback  onPlay
2025-01-14 18:42:36.832 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13684860000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:36.833 Verbose MediaSessionCallback  onPause
2025-01-14 18:42:36.840 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13684861000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:48.669 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13696692000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:48.669 Verbose MediaSessionCallback  onPlay
2025-01-14 18:42:48.680 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13696693000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:52.420 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13700440000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:52.421 Verbose MediaSessionCallback  onPause
2025-01-14 18:42:52.422 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13700444000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:54.480 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13702502000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:54.481 Verbose MediaSessionCallback  onPlay
2025-01-14 18:42:54.485 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13702503000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:54.781 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13702809000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:54.782 Verbose MediaSessionCallback  onPause
2025-01-14 18:42:54.782 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13702810000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:56.548 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13704572000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:42:56.550 Verbose MediaSessionCallback  onPlay
2025-01-14 18:42:56.551 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PLAY, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13704572000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:43:07.245 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13715270000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
2025-01-14 18:43:07.249 Verbose MediaSessionCallback  onPause
2025-01-14 18:43:07.250 Verbose MediaSessionCallback  onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x4, repeatCount=0, eventTime=13715271000000, downTime=0, deviceId=0, source=0x0, displayId=-1 }
3

I see. So what might be causing the issue (in fact audio was not resumed)?

4

Audio not resumed or no sound ?

In the logs exoplayer says it’s playing. Maybe some device issue with background services see don’t killmyapp and exclude from battery optimization.

5

Not resumed - in AA GUI it was still “play” symbol displayed, meaning the player is not playing any music.

I’ve excluded it from everywhere and did basically everything what’s possible in OxygenOS 15, allowed it to not optimize battery and run in background, even locked it in recents.

6

Can you provide new logs with more delay between button press and documenting the exact timing things happens ?

7

cookie_drummer_slow - with more delay as you requested.

cookie_drummer_fast - here I discovered something new. If I press MUTE button very fast (every 1 second), music is played and resumed correctly. Hope it helps somehow.

8

You missed the important part

In those logs I see the app receiving a play command

2025-01-14 22:40:26.915 Verbose MediaSessionCallback  onPlay

That correctly start playback.

Then a pause command

2025-01-14 22:40:36.165 Verbose MediaSessionCallback  onPause

That correctly pause playback.

If you actually sent another command later it never reached the app and so usually is the OS pausing the app in background.

9

Yes, sorry for that but let me explain how I’ve tested it:

  • if you see that play command has been sent at 22:40:26.915, then the next pressing on “MUTE” button happened in the next minute (in this case at 22:41:xx:xxx),

I think OS pausing the app might not be the case. I also tested it having Symfonium displayed on my smartphone (having screen turned on of course).

10 
2025-01-14 22:40:51.198 Verbose StateManager  New state (true): true-false-true 
2025-01-14 22:40:51.200 Verbose PlayerService  Stopped foreground (false)
2025-01-14 22:40:53.865 Verbose StateManager  New state (true): false-false-true 
2025-01-14 22:41:07.599 Verbose StateManager  New state (true): true-false-true 
2025-01-14 22:41:34.540 Verbose QueryBuilder  Query: COUNT on download_items, count=0 | (download_items.status=0) - '' [1.61ms]

The app does not receive any commands after stopping being in foreground, so there’s something happening outside of the app.

11

I will try to retest it on three different phones and will let you know.

12

I’ve managed to retest it on two phones - Motorola on Android 8 and OnePlus on Android 14. On both the result is the same, as the issue description says.

Logs:
cookie_phone_1 - Motorola, Android 8
cookie_phone_2 - OnePlus, Android 14

Additionaly, I’ve tested another two music players I haven’t used before. Both does not have this issue.

13

The logs are the same, Symfonium receive a pause command an audio focus loss event then absolutely nothing.

Without events reaching the app there’s nothing I can do.

All I can see is that the events seems to reach the app as long as it’s in foreground, but the media session and services are still working after that and there’s no reason for the events to not be sent to the app.

You can try to provide a bug report Capture and read bug reports  |  Android Studio  |  Android Developers just after pressing the button to play and it does not work a couple of times in case the OS logs why it block the commands.

14

Alright, will provide such logs later in the evening (it’s morning here in Poland).

15

@Tolriq I’ve managed to capture the logs earlier. :slight_smile:

I’ve DMed you logs bugreport-CPH2581EEA-AP3A.240617.008-2025-01-16-14-37-39.zip

Steps were as follows:

  1. Started AA.
  2. Resumed music via on screen PLAY button.
  3. Paused music using MUTE button placed on steering wheel.
  4. Waited ~5 seconds.
  5. Pressed button MUTE on steering wheel couple of times.
  6. Music was not resumed.

Everything from the above took place between 14:35 - 14:37.

Hope these logs will help you.

16

Unfortunately the logcat in the dump starts later, seems the device takes a long time to generate the dump and include the logcat :frowning:
If you are motivated try again and really directly start the dump after 2 or 3 quick mute click not working.

17

New logs delivered via DM. :slight_smile:

18

Same dump only contain a very very short logcat that start late :frowning:

No more idea to try to get the issue.

19

I’ve tried two more times - logs sent via DM.

20

Still nothing relevant.

I have no other ideas, in all cases to prepare for targeting Android 15 and their bugs, next release will keep foreground status for a longer time so hopefully this will be long enough for the majority of your need.