[BUG] MediaElement stops after running in background after few minutes on Android

[efhayati]

Is there an existing issue for this?

• I have searched the existing issues

Did you read the "Reporting a bug" section on Contributing file?

• I have read the "Reporting a bug" section on Contributing file: https://github.com/CommunityToolkit/Maui/blob/main/CONTRIBUTING.md#reporting-a-bug

Current Behavior

When an Android physical device is playing a stream URL and the app goes into the background, the audio stops after about 2-3 minutes. However, when the device is connected to a power source, the audio continues to play for hours without interruption.

Expected Behavior

Audio is expected to continue playing in the background, regardless of whether the device is charging or not.

Steps To Reproduce

1. Use a stream URL in MediaElement
2. Deploy it to an Android physical device
3. Disconnect the cable and run the app
4. When the screen is locked, the audio will stop playing after a few minutes

Link to public reproduction project repository

https://github.com/efhayati/MauiMediaElementAndroidIssue

Environment

- .NET MAUI CommunityToolkit: 5.3.0
- .NET MAUI MediaElement: 2.0.0
- OS: Android 13
- Device: SAMSUNG GALAXY S23+
- .NET MAUI: .NET 7.0

Anything else?

No response

[ArchangelWTF]

This is due to MediaElement not requesting various things such as a foreground service with a notification on Android and requesting a wake / wifi lock (If streaming)

I'm not sure if it's left out by design or if it was meant to be added as a feature later, though it would be nice if it eventually makes it's way into mediaElement.

[bijington]

This is due to MediaElement not requesting various things such as a foreground service with a notification on Android and requesting a wake / wifi lock (If streaming)

I'm not sure if it's left out by design or if it was meant to be added as a feature later, though it would be nice if it eventually makes it's way into mediaElement.

I wonder if these things should be customisable by the developer as there might be a whole set of different use cases?

[ArchangelWTF]

I wonder if these things should be customisable by the developer as there might be a whole set of different use cases?

it could work, although I'm not sure how well it could be exposed to developers to use.. As from personal experience having integrated such a player on Xamarin Forms (And later ported to MAUI) Android's system in having audio / video in the background is pretty all or none.

[IcemarkUK]

Having the same issue. Was able to work around it in iOS, but can't find a solution for Android within Maui. Would rather not just take a WakeLock and I'm not sure if Wifi lock is a solution for streaming when not on wifi.

[sps014]

Facing same issue in android, please add it in roadmap, it's really hard to get around it in android.

[brminnick]

Do you happen to know the fix for Android?

@IcemarkUK Could you share your workaround in iOS?

[IcemarkUK]

Do you happen to know the fix for Android?

@IcemarkUK Could you share your workaround in iOS?

In Android I created a background service that is instructed to take the wakelock for power and wifi, when the audio is playing, and release it when stopped. But it is not perfect because sometimes it doesn't get an instruction to stop playing if the app is killed.

for iOS I'm pretty sure it was just adding the following to info.plist

	<key>UIBackgroundModes</key>
	<array>
		<string>audio</string>
	</array>

And this maybe in

            .ConfigureLifecycleEvents(events =>
            {
#if IOS
                events.AddiOS(ios =>
                    ios.FinishedLaunching((app, options) =>
                    {
                        AVFoundation.AVAudioSession session = AVFoundation.AVAudioSession.SharedInstance();
                        session.SetCategory(AVFoundation.AVAudioSessionCategory.Playback);
                        session.SetActive(true);
                        return true;
                    })
                );
#endif
            });

In the maui app create builder.

[brminnick]

@jfversluis @bijington I'd to get your thoughts on this!

Since we're dealing with Background Services on Android and Entitlements on iOS, it feels like the "fix" is to share how to do it in our Docs rather than modifying our code/library since the devs will have to manually add these things in their project.

As the resident MediaElement / Docs experts, what do you guys think?

[bijington]

Yes I would agree that it should be in docs if it's something the developer needs to implement.

I'm not entirely sure on the Android implementation but if someone does I'll be happy to write it up into a docs article

[IcemarkUK]

@jfversluis @bijington I'd to get your thoughts on this!

Since we're dealing with Background Services on Android and Entitlements on iOS, it feels like the "fix" is to share how to do it in our Docs rather than modifying our code/library since the devs will have to manually add these things in their project.

For Android I think it better to have the low level Media Element tied better with the background services. I implemented a quick hack because I didn't feel like I could get close enough to the low level player. And it's definitely not ideal. It is possible to kill the app completely and still leave audio running... I could never catch that situation with the services. (Probably my implementation details) - If every developer is forced to wrap/create interface to the MediaElement just to have background services - it seems counter intuitive.
I'd have to reassess the suggested Native Android solution again to see why I couldn't implement it...

[ArchangelWTF]

Once Media3 is released MediaSessionService can be used to deal with a lot of the necessary requirements to spawn a background service that plays audio in Android, it will most likely require some code changes on the CommunityToolkit side to accomodate it though, as for the current way to do it in ExoPlayer it would require a lot of work and an eventual refactor to support Media3

[ne0rrmatrix]

Can you test against current main repo? Media element has been updated to support lock screen controls and this update should address this issue. There is now a foreground service that is active while you play media. This was done to handle the media player notifications for the controls.

[ne0rrmatrix]

Should be fixed with latest release 4.0 :) @vhugogarcia @efhayati

[vhugogarcia]

Thanks @ne0rrmatrix for checking in. I'm closing this issue because when the issue was reported the background playing was not enabled until we enabled it recently on version 4.