Android's audio focus management is a "collaborative" one. This means it expects that Apps behave "nice" to Android (and therefore other Apps) and follow the Android documentation for "Manage audio focus":
https://developer.android.com/guide/topics/media-apps/audio-focus
Expected behavior Ducking:
DAB-Z playing audio, other app starts a short-lasting audio output, DAB-Z ducks to the level configured in settings (default 50%), then other app stops audio, DAB-Z unducks.
Precondition: Some device specific system apps from MTC, FYT, etc. allow this behavior. Means: above applies only to a "near standard" Android device.
If DAB-Z previously got the pause command, it remains in paused.
Expected behavior Play/Pause:
DAB-Z playing audio, User pauses DAB-Z via a media control widget, launcher, from DAB-Z notification, etc. , then DAB-Z stops audio, other audio app can now output audio as long as it wants (ex. Youtube, Spotify, etc.). When User(!) brings DAB-Z to front and presses the big Play symbol shown "above" the logo, or is using media control widgets, launcher, etc. to command DAB-Z to play, then DAB-Z will continue to output the live DAB audio (no timeshift recording in the meantime). Other media player is expected to stop its audio output and decide by itself what to do now.
If during DAB-Z paused, another app does a short-lasting audio output (ex. Navi guidance), DAB-Z remains in pause (
@IG_Vasilich : sic!).
If the above is not working as expected, it is likely an MTC, FYT, ... system app interfering with this standard Android behavior.
Expected behavior Mute:
DAB-Z playing, system wide Mute is triggered ex. via SWC, or volume control from status bar, etc., no audio output from any(!) app. Since Android 10, Android in parallel sends a pause command to the currently active audio source. Then User unmutes, (Android 10 sends play command) and DAB-Z is audible again.
If during Mute state, the User switches the audio source to any other app, then DAB-Z is not coming back of course when User unmutes.