Users report my app isn't working on Samsung Galaxy S21+

[androidx]

Users report my app isn't working on Samsung Galaxy S21+

[christosts]

Everything seems to work fine for most devices, but we've received 2 reports from users of Samsung Galaxy S21+ devices who are unable to play any of the media.

It will be difficult to support what's happening on the Samsung devices without any further information. As you may have seen when you opened this issue, we request bugreports to inspect what may have gone wrong. A copy of the logs and/or stack trace would at least be more helpful than nothing.

Another thing: enableAudioOffload causes things not to work properly on Pixel 6 Pro and perhaps more devices

Can you please explain in more detail what's happening? Also consider attaching a bureport when issues occur.

@krocard can you offer some assistance on the audio off-load issues?

[rhummelmose]

@christosts I can appreciate and understand that. Unfortunately I don't have access to the particular device and haven't been able to get the users to create a bugreport. Perhaps I can bake something into the app that will allow me to generate that remotely, but I am not super experienced with Android so I'll have to investigate.

[krocard]

Another thing: enableAudioOffload causes things not to work properly on Pixel 6 Pro and perhaps more devices

I'll test on Pixel 6 Pro, but can I am wondering why you choose to enable this option. It is designed for power savings during long audio only playback with the screen off. Additionally only AAC and MP3 are supported and there are severe limitations on offload scheduling (you can't interact with the Player).
Offload playback is useless if you don't also enable offload scheduling with all its limitations. I could not find any usage of offload scheduling in your app.
Note that offload scheduling is still experimental.

[rhummelmose]

I'll test on Pixel 6 Pro, but can I am wondering why you choose to enable this option. It is designed for power savings during long audio only playback with the screen off. Additionally only AAC and MP3 are supported and there are severe limitations on offload scheduling (you can't interact with the Player).

Because it says in the docs that this feature should be used to minimize battery consumption, in cases where audio should play with the screen off for longer durations. I linked to my app (both source and play store) in the original issue description and it is a radio/podcast app. I cannot think of a better match for the feature described. Additionally the streams, that I also linked in the original issue description, are pure AAC streams.

Offload playback is useless if you don't also enable offload scheduling with all its limitations. I could not find any usage of offload scheduling in your app.

Okay, I wasn't aware. The documentation on the matter is scarce at best. I wasn't able to find a sample, though the fact that audio playback behaved slightly differently with offloading enabled, led me to believe it was in fact working (playback was a few seconds delayed when being started for example).

Note that offload scheduling is still experimental.

I don't mind that :) love to be on the edge

[krocard]

Because it says in the docs that this feature should be used to minimize battery consumption, in cases where audio should play with the screen off for longer durations.

To clarify, it says: "Audio offload disables ExoPlayer audio processing, but significantly reduces the energy consumption of the playback when offload scheduling is enabled" [emphasis added]. Please refer to the linked offload scheduling doc that lists many restriction on how the player can be controlled when offload scheduling is enabled:

media/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/ExoPlayer.java

Lines 1564 to 1601 in 341bb57

	/**
	* Sets whether audio offload scheduling is enabled. If enabled, ExoPlayer's main loop will run as
	* rarely as possible when playing an audio stream using audio offload.
	*
	* <p>Only use this scheduling mode if the player is not displaying anything to the user. For
	* example when the application is in the background, or the screen is off. The player state
	* (including position) is rarely updated (roughly between every 10 seconds and 1 minute).
	*
	* <p>While offload scheduling is enabled, player events may be delivered severely delayed and
	* apps should not interact with the player. When returning to the foreground, disable offload
	* scheduling and wait for {@link
	* AudioOffloadListener#onExperimentalOffloadSchedulingEnabledChanged(boolean)} to be called with
	* {@code offloadSchedulingEnabled = false} before interacting with the player.
	*
	* <p>This mode should save significant power when the phone is playing offload audio with the
	* screen off.
	*
	* <p>This mode only has an effect when playing an audio track in offload mode, which requires all
	* the following:
	*
	* <ul>
	* <li>Audio offload rendering is enabled in {@link
	* DefaultRenderersFactory#setEnableAudioOffload} or the equivalent option passed to {@link
	* DefaultAudioSink.Builder#setOffloadMode}.
	* <li>An audio track is playing in a format that the device supports offloading (for example,
	* MP3 or AAC).
	* <li>The {@link AudioSink} is playing with an offload {@link AudioTrack}.
	* </ul>
	*
	* <p>The state where ExoPlayer main loop has been paused to save power during offload playback
	* can be queried with {@link #experimentalIsSleepingForOffload()}.
	*
	* <p>This method is experimental, and will be renamed or removed in a future release.
	*
	* @param offloadSchedulingEnabled Whether to enable offload scheduling.
	*/
	@UnstableApi
	void experimentalSetOffloadSchedulingEnabled(boolean offloadSchedulingEnabled);

One of the main current limitation of offload scheduling is that it is not compatible with the demo or the media-3/ExoPlayer current UI module as it accesses the player state without leaving offload scheduling.

Unfortunately, one can't simply enabling offload playback to gain battery power (though it is a state where we would like to be on the long term). The main issue is that because ExoPlayer internal thread doesn't run very often (to save battery), the shared state visible by the UI thread is only updated every ~1min. In theory it could be avoided by updating the state in the UI thread, but we are waiting to get more data on the power savings across the ecosystem before considering such architectural change.

[rhummelmose]

Right, but from the user guide:

For long playbacks with the screen off, ExoPlayer’s audio offload mode needs to be used or ExoPlayer may consume significantly more power than MediaPlayer. Audio offload allows audio processing to be offloaded from the CPU to a dedicated signal processor.

Anyways I understand and I've also turned it off now as it seemed to break on Pixel 6 Pro. I don't use the ExoPlayer provided UI elements. Instead I've built player layout using compose and interact with the player through media3.

All of this is however not super important as users do not seem to be concerned about battery usage without offloading. It is however quite a big issue for us that it doesn't seem to work at all on Samsung Galaxy S21+. Unfortunately I don't have a device at hand. There is no chance the media3 team has one?

[google-oss-bot]

Hey @rhummelmose. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[rhummelmose]

@google-oss-bot Thanks but I did provide information. I cannot provide more information without a device.

[krocard]

We are going to improve support for audio offload, but for now it is still experimental. We have known issues currently with offload, especially on track transition.

[rhummelmose]

@krocard Totally understand. Main issue is that it doesn't work at all on S21+ (I am not using offload).

[umangsaini]

I checked with the app you mentioned on S21+ (Exynos). I can confirm that audio does not play reliably on S21+ (it is able to play rarely).
However, both the "demo" and "demo-session" apps are able to play both streams reliably on S21+.

I observed that your app goes to IDLE state instead of receiving timeline change event with correct duration, and remains stuck in this state. Your app works as expected on Pixel 3.

Since reference demo applications work reliably with your content on S21+, the issue appears to be in how your application has implemented its custom listener and state manager in Player.kt. This issue is not at all reproducible in reference demo app. I would recommend you to review the demo-session reference app again to try and identify the root-cause in your app.

@Krovad may recommend things to try, however following the reference as closely as possible would be the way to proceed to resolve this.

Thanks.

[rhummelmose]

@umangsaini Okay, thanks. However quite hard for me to understand how it can be implemented incorrectly. It's super simple.

[krocard]

Thanks @umangsaini for carring the test!

@rhummelmose Given that the the demo app has no issue, it is highly likely that the problem comes from your app. Unfortunatly, we do not have the time to help you debug your app. Nevertheless, would you have any ExoPlayer specific question, feel free to open a new issue.

[rhummelmose]

To anybody who might be coming here facing the same issue:
The problem was that I used flags 0 when I created the pending intent for the MediaLibrarySession.Builder. For reasons I cannot comprehend this causes a subset of newer Samsung devices to crash. Changing to PendingIntent.FLAG_IMMUTABLE instead of 0 fixed the issue.
See these changes for ref: https://github.com/denuafhaengige/duah-android/commit/535b67ec1d01b9dbf9bce48a9defd136e9402fc6#diff-646df2a2921af05d16df70df494cd94a6deb6af5cef4ee040dc8914c93aed41eR120-R125