Add support to make AndroidForegroundService optional to MediaElement

[ne0rrmatrix]

• Feature/Proposal

Description of Change

Updated MediaElement to include AndroidForegroundServiceEnabled property for better control over media playback on Android. Adjusted related methods and classes to handle this new property, ensuring the foreground service is utilized appropriately during media playback. Removed unnecessary properties and streamlined the popup media element configuration.

Linked Issues

• Fixes Enable/Disable MediaElement foreground service. #2225
• Fixes [Proposal] Add MediaElement Foreground Service to Media Options #2657

PR Checklist

• Has a linked Issue, and the Issue has been approved(bug) or Championed (feature/proposal)
• Has tests (if omitted, state reason in description)
• Has samples (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Documentation created or updated: https://github.com/MicrosoftDocs/CommunityToolkit/pulls

Additional information

This PR is for the community to see how making android service optional could be implemented.

MediaElement.shared.cs

/// <summary>
/// Read the MediaElementOptions set in on construction, cannot be changed after construction
/// </summary>
public AndroidViewType AndroidViewType { get; init; } = MediaElementOptions.DefaultAndroidViewType;

MediaElementOptions

/// <summary>
/// Set Android Foreground Service for MediaElement on construction
/// </summary>
internal static bool AndroidForeServiceEnabled { get; private set; } = true;

/// <summary>
/// Set Android Foreground Service for MediaElement on construction
/// </summary>
/// <param name="androidForegroundServiceEnabled"></param>
public void SetDefaultAndroidForegroundService(bool androidForegroundServiceEnabled) => AndroidForeServiceEnabled = androidForegroundServiceEnabled;

[bijington]

I think the general approach looks good. I am surprised it takes such little code change.

I think we should add an Is prefix to the property to follow typical Boolean naming conventions (e.g. IsAndroidForegroundServiceEnabled)

I understand that you wanted to have Android as the initial prefix here. Why did we do this for the AndroidViewType property in stead of making it a property that only exists for Android? Was it to simplify the code that needs to be written?

[ne0rrmatrix]

I understand that you wanted to have Android as the initial prefix here. Why did we do this for the AndroidViewType property in stead of making it a property that only exists for Android? Was it to simplify the code that needs to be written?

I honestly have no idea how or when we came up with that. I am simply using the same convention used in texture view as it is has already been established and keeping it the same made sense to me.

edit: I think it was so that we can use it in xaml.

[mrucker]

Do these code changes also remove the foreground service permission from the Android manifest file? That is the real problem, because that is what Google checks when you submit to the app store.

[Elinares-82]

Hi all, we just got rejected out app since the MediaElement control added this permission. We only use this control to display a video in the Splash screen. When can we get this new CommunityToolkit nuget version? In the meantime, we will appeal the rejection, however, this is just to see if they understand the situation. I would appreciate it if we could move a little faster. Thanks

[mrucker]

@Elinares-82 there's an easy work around for this in the meantime. You just need to remove like 3 lines of code from the MAUI project, build it, and then include the package you just built in your app instead of the Nuget package. It took me like an hour to get a version in my app without the foreground permission requirement.

[Elinares-82]

@Elinares-82 there's an easy work around for this in the meantime. You just need to remove like 3 lines of code from the MAUI project, build it, and then include the package you just built in your app instead of the Nuget package. It took me like an hour to get a version in my app without the foreground permission requirement.

Thanks!, I will give it a try.

[bijington]

Hi all, we just got rejected out app since the MediaElement control added this permission. We only use this control to display a video in the Splash screen. When can we get this new CommunityToolkit nuget version? In the meantime, we will appeal the rejection, however, this is just to see if they understand the situation. I would appreciate it if we could move a little faster. Thanks

I think a PR opened within a few hours is moving pretty quickly. If you would like things to move more quickly please free to get involved and help out

[Elinares-82]

Hi all, we just got rejected out app since the MediaElement control added this permission. We only use this control to display a video in the Splash screen. When can we get this new CommunityToolkit nuget version? In the meantime, we will appeal the rejection, however, this is just to see if they understand the situation. I would appreciate it if we could move a little faster. Thanks

I think a PR opened within a few hours is moving pretty quickly. If you would like things to move more quickly please free to get involved and help out

Sure, give me the permissions and I click on Approve button. The Play Store is rejecting our apps since you decided to add permissions by default, why? Let the developers add or not the permissions.

[pictos]

I see that you added the property inside the MediaElement, how is the behavior if I have two media elements in different pages, one setting foreground to true and other to false, what will be the behavior? I didn't see code to tear down the ForegroundService if it changes to false in fly.

But I think it should only be something that you set on AppBuilder and only once

[Elinares-82]

That I could see is prevent to start the service here

I'm taking the @ne0rrmatrix branch a create an assembly in the meantime, since we need our app get approved ASAP.

[ne0rrmatrix]

I see that you added the property inside the MediaElement, how is the behavior if I have two media elements in different pages, one setting foreground to true and other to false, what will be the behavior? I didn't see code to tear down the ForegroundService if it changes to false in fly.

But I think it should only be something that you set on AppBuilder and only once

The behavior if one media element is using the service and the other is not is that one will have access to the service and the other will not. This PR was meant to allow input and let ppl see how it could be done. It is marked as draft and I explicitly created it so I could gather feedback and make changes. I was hoping for this exact sort of input.

Do we want to have it as init only and apply to any media elements that launch? Or do we want to allow each media element the option at runtime to decide?

If one media element is already using the service and the second one is not using it it will not tear down the service. I do not believe that is possible without tearing down the media element using the service. The service is tightly integrated with media session and is as close to default implementation as I could create based on platform limitations. The only thing I could do to make it more like the google example is to move the Exoplayer Builder into the service itself. That was the original goal but do to various factors in the original media2 to media3 PR it never happened.

I would prefer to keep this as simple as possible for maintainability while allowing developers the choice to do what they want. My goal here is to add the option to opt out of the service at runtime. Do you want it set in builder only? Or does anyone have any better suggestions? I am not looking at adding anything complex or doing something new. I simply want to add developer choice.

Anyone who has an opinion please speak up. I still think of this as being in design phase. This PR was purely to allow ppl to see the idea I had for design.

[Elinares-82]

Do we want to have it as init only and apply to any media elements that launch? Or do we want to allow each media element the option at runtime to decide?

What if we can have both?, We can have an initial flag to disable it for all the media elements, and force with the new IsAndroidForegroundServiceEnabled to start individually? I do not know if this make sense.

I the other hand, I know that each team have processes, I don't like to sound rude at all. I'd just like to know when this version might be coming out.

Thanks,

[mrucker]

I was reading back through old discussions because I've been confused. I think there are two different issues being discussed. I'm going to call them issue 1 and issue 2 here.

Issue 1 -- MediaElement should only turn on a foreground service if it is requested
Issue 2 -- MediaElement should only add foreground permissions to the Android Manifest if requested

I think this PR will likely fix what I call issue 1, but it won't fix what I call issue 2.

@ne0rrmatrix Is this PR intended to fix both issue 1 and 2? Or are you only trying to fix issue 1?

@Elinares-82 I think you have an issue 2 problem (which is what I had when I joined these threads several months ago). Unless ne0rrmatrix says otherwise, I don't think this PR is going to fix your issue.

[ne0rrmatrix]

@mrucker ty for the clarification. I will update the PR to address both issues. I appreciate all the help and input.

[mrucker]

(Also, I seem to be the one to blame for the confusion. Looking back through the discussion history, I hijacked discussion #2225, which was initially about issue 1, and started talking about issue 2 because I didn't understand the difference at the time. Sorry everyone.)

[Elinares-82]

MediaElementOptions

You are totally right; I think this will not fix my issue. Google rejected our app since in the Manifest are several permissions like FOREGROUND_SERVICE_MEDIA_PLAYBACK and FOREGROUND_SERVICE, but we just display a promo video in the splash screen. We are stuck at this point. The only way that I can see is use an old version or use an alternative like Blazor component.

[ne0rrmatrix]

Updating the service to address both issues will require the developer to add permissions manually to manifest and will only allow the service to run if permissions and foreground service are turned on. My questions is how do we want to deal with that. The reason we set the permissions ourselves was to fix the issue with constant bug reports where the solution was to simply add the service and intent filter to the manifest.

[mrucker]

Updating the service to address both issues will require the developer to add permissions manually to manifest and will only allow the service to run if permissions and foreground service are turned on. My questions is how do we want to deal with that. The reason we set the permissions ourselves was to fix the issue with constant bug reports where the solution was to simply add the service and intent filter to the manifest.

Yes... That's kind of the problem we never solved in an old discussion about it... Which is why I've never offered my own PR... There didn't seem to be a great solution.

[Elinares-82]

Updating the service to address both issues will require the developer to add permissions manually to manifest and will only allow the service to run if permissions and foreground service are turned on. My questions is how do we want to deal with that. The reason we set the permissions ourselves was to fix the issue with constant bug reports where the solution was to simply add the service and intent filter to the manifest.

I think, if this is documented all of us have to read and follow the guidance. For me is normal to add the permissions that the controls need. But, is there a possibility to disabled to add the permissions to the Manifest if the new Flag is turn it on? In a complex scenario use a project property to disable this in the source generator (I'm assuming that these permissions are being added using a source generator)

[mrucker]

@Elinares-82

You are totally right; I think this will not fix my issue. Google rejected our app since in the Manifest are several permissions like FOREGROUND_SERVICE_MEDIA_PLAYBACK and FOREGROUND_SERVICE, but we just display a promo video in the splash screen. We are stuck at this point. The only way that I can see is use an old version or use an alternative like Blazor component.

It is easy to remove the permission requirements if you are able to build the MediaElement yourself and create your own Nuget Package. It's not ideal, but if you're really up against a wall it will allow you to release your app. I'd send you my team's custom Nuget package we've been using to remove this permission, but handing out code to strangers on the internet doesn't seem like a best practice 😄.

[pictos]

MediaElementOptions

You are totally right; I think this will not fix my issue. Google rejected our app since in the Manifest are several permissions like FOREGROUND_SERVICE_MEDIA_PLAYBACK and FOREGROUND_SERVICE, but we just display a promo video in the splash screen. We are stuck at this point. The only way that I can see is use an old version or use an alternative like Blazor component.

@Elinares-82 there are tools that you allow you to edit the manifest on android app, so when you build your project and it generates the apk or aab you can unzip it, remove the permissions that you don't want and zip it again to ship into stores. I already did that for many apps that I worked and never had issues with that, and since are tools for it, I would say, isn't something unusual

[Elinares-82]

@Elinares-82

You are totally right; I think this will not fix my issue. Google rejected our app since in the Manifest are several permissions like FOREGROUND_SERVICE_MEDIA_PLAYBACK and FOREGROUND_SERVICE, but we just display a promo video in the splash screen. We are stuck at this point. The only way that I can see is use an old version or use an alternative like Blazor component.

It is easy to remove the permission requirements if you are able to build the MediaElement yourself and create your own Nuget Package. It's not ideal, but if you're really up against it will allow you to release your app. I'd send you my team's custom Nuget package we've been using to remove this permission, but handing out code to strangers on the internet doesn't seem like a best practice 😄.

I think these are the lines that I have to comment out. I'm trying to use the generated "custom" DLL but I'm getting several compiler errors so I will try the @pictos suggestion.

Thanks to all for your help and recommendations.

[ne0rrmatrix]

Give me an hour or two and I will update this PR to address issues brought up. I have an idea of how we can do this and have everyone get what they want.

[mrucker]

@Elinares-82 Those two and I think you'd also need to get these two (it's been a while since I made the change)

[ne0rrmatrix]

@Elinares-82 Those two and I think you'd also need to get these two (it's been a while since I made the change)

I was unable to remove those two items. It simply will not work without them. If you can test the latest PR in your project and see if not adding anything in manifest and then disabling the service using builder works for you I would appreciate it.

[Elinares-82]

@Elinares-82 Those two and I think you'd also need to get these two (it's been a while since I made the change)

I was unable to remove those two items. It simply will not work without them. If you can test the latest PR in your project and see if not adding anything in manifest and then disabling the service using builder works for you I would appreciate it.

Thanks, I'm trying to compile and use the assembly, however, in my app several compilation errors come up and this is because I just need the Android part. I'm using the conditional references as well like

[Elinares-82]

MediaElementOptions

You are totally right; I think this will not fix my issue. Google rejected our app since in the Manifest are several permissions like FOREGROUND_SERVICE_MEDIA_PLAYBACK and FOREGROUND_SERVICE, but we just display a promo video in the splash screen. We are stuck at this point. The only way that I can see is use an old version or use an alternative like Blazor component.

@Elinares-82 there are tools that you allow you to edit the manifest on android app, so when you build your project and it generates the apk or aab you can unzip it, remove the permissions that you don't want and zip it again to ship into stores. I already did that for many apps that I worked and never had issues with that, and since are tools for it, I would say, isn't something unusual

I tried this, but, the installer is not be able to run.

[ne0rrmatrix]

I created a blank Maui app targeting dotnet 9. I then added the package after building and creating a nuget. I did not add anything to android manifest. I did add this to builder:

.UseMauiCommunityToolkitMediaElement(options => options.SetDefaultAndroidForegroundService(false));

It works as expected and service is disabled. Note that the rich media notifications do not work without the service. This is one of the tradeoffs.

[Elinares-82]

I then added the package after building and creating a nuget.

Thanks a lot @ne0rrmatrix , I was trying to create the nuget like yours, however, I do not know how, then I was researching about it.

[mrucker]

I will test out this PR as well tomorrow. Thank you for your work @ne0rrmatrix!

[bijington]

I think we should make this property opt-in rather than opt-out. That way developers only need to add the permissions if they want to use the foreground service, they don't want to have to add them by default. This should hopefully help to see fewer bug reports come in related to permissions.

[bijington]

Plus this should also include the Is prefix to the name

[ne0rrmatrix]

As for the Is prefix I will update to fix that.

If we choose to make the service opt in that would create a situation where on Mac, iOS, and windows behavior would be different than android. It would create confusion and core behavior to be differentiated per platform. If we do this on android we should have an opt in for all devices? As for other device types there has been no requests for this on anything but android.

The service is tightly tied to rich media notifications. Untying and removing the service might be technically possible but it would be against best practices for for media 3 API. We would have to decide if we want to either have platform specific behavior that is different on each platform as a default or add this to every device type when it is only really relevant for a single platform.

If anyone sees this from a different angle or can suggest an alternative idea or way of thinking about his I would appreciate input.

[ne0rrmatrix]

Do we want core behavior to be different on a per platform basis? Or am I over thinking this?

[bijington]

Is there such a thing as a foreground service on the other platforms?

[ne0rrmatrix]

Unfortunately we are also using an bound android service in conjunction with a c# service. It is very complicated and took a while to figure out. I can add that service to the builder. I in fact missed it and had forgotten about it. It is required for it to work. I will modify code so that is not run when we are not using it. Good catch!

As for what you were saying I see no way to do this that does not have the user set the permissions. I do believe there is a way to do this without users/devs having to do anything. It has been mentioned specifically as to how we can do that before in the discussion about this. But to do that would require a complete rewrite of android implementation. My solution is simple and deals with all existing complaints about developers either not needing service or it actually causing it to rejected by play store because they don't want or need notifications at all.

My solution using builder means that if developer adds no permissions and sets service disabled it is not include at all in app and will pass certification by play store. One dev has already done this and is actively using it. Just scroll up and you will see that. I don't recommend anyone use a PR in production but it looks like they did do that.

Currently in main we set all services and permissions ourselves. If you can figure out how we might use a builder to set [assemby] and/or [intent], [service] then it would be trivial for us to do everything and no developer action would be required. That would be best case. Unfortunately I don't know how to do that. Do you have any ideas?

[pictos]

Currently in main we set all services and permissions ourselves. If you can figure out how we might use a builder to set [assemby] and/or [intent], [service] then it would be trivial for us to do everything and no developer action would be required. That would be best case. Unfortunately I don't know how to do that. Do you have any ideas?

Here I can see that you're trying to protect devs from themselves, and that (in 99% of the cases) are very unproductive. The best way is to let devs add permissions themselves. You may argue that causes them to open a lot of issues because they don't read the docs, but at the end this isn't our fault. Devs should read docs before using something.
But if still you want to protect devs from themselves, you can have a SG that will read the changes on the MauiAppBuilder code and add the attributes when it sees the dev option to use the Foreground service. That will make it trimmable and will add the lines on manifest for them.

[ne0rrmatrix]

@pictos this PR adds back the need for devs to set permissions themselves. At the moment in main we do everything ourselves. This was a mistake I think. I was happy with it for a while because it drastically cut down bug reports. But it limits our options in the long run. I agree with what you are saying.

In this PR we created a builder option to add dev choice as to whether they want the android service. This was all discussed previously in our monthly meeting and in multiple discussions. It was just brought up again. I am going to add it to our monthly meeting schedule as I would like a final resolution as to what way we want to go.

I have multiple reviews where the suggestions are essentially polar opposite ideas. I am hoping to gain some clarity when we all get together at the beginning of the month.

The idea I have and want to go with is have devs set the permissions and point them at the docs when we need to. It adds a choice in builder that defaults to ON as that unifies cross platform behavior and minimizes code changes. The main thing we are doing here is allowing developer choice as I have found out there are many use cases where rich media notifications are not wanted or needed. This was a much requested feature. This is all fully implemented and just needs one more fix before It is done.

I am hoping we can decide this soon. Since I joined the team this is so far the most upvoted and requested item I have come across relating to media element.

[Elinares-82]

SG

Totally agree. We as a developers have to read the documentation. Add an exclamation or important note in the docs saying, "Permissions Required!"

[pictos]

@ne0rrmatrix I'm sorry if I wasn't clear, english isn't my primary language.

I wasn't talking about the PR as a hole, but of what I understand from the quoted paragraph. Any path that you choose I'll be happy with, just wanted to add my 2 cents

[Elinares-82]

I created a blank Maui app targeting dotnet 9. I then added the package after building and creating a nuget. I did not add anything to android manifest. I did add this to builder:

.UseMauiCommunityToolkitMediaElement(options => options.SetDefaultAndroidForegroundService(false));

It works as expected and service is disabled. Note that the rich media notifications do not work without the service. This is one of the tradeoffs.

@ne0rrmatrix I just tested the PR, I was able to create the nuget and load it to my DevOps Artifacts. The only additional thing that I had to do was downgrade the Microsoft.Maui.Controls to 9.0.40, since the 9.0.50 and 9.0.60 has and issue with the Keyboard and the Scroll, when the Keyboard appear the scroll of the view does not work as expected and the user is not able to scroll the view to see other controls. We are currently loading the aab file to the Google Store, I let you know if the app is approved. Thanks so much.

[Elinares-82]

I created a blank Maui app targeting dotnet 9. I then added the package after building and creating a nuget. I did not add anything to android manifest. I did add this to builder:

.UseMauiCommunityToolkitMediaElement(options => options.SetDefaultAndroidForegroundService(false));

It works as expected and service is disabled. Note that the rich media notifications do not work without the service. This is one of the tradeoffs.

@ne0rrmatrix I just tested the PR, I was able to create the nuget and load it to my DevOps Artifacts. The only additional thing that I had to do was downgrade the Microsoft.Maui.Controls to 9.0.40, since the 9.0.50 and 9.0.60 has and issue with the Keyboard and the Scroll, when the Keyboard appear the scroll of the view does not work as expected and the user is not able to scroll the view to see other controls. We are currently loading the aab file to the Google Store, I let you know if the app is approved. Thanks so much.

Hi, our app was rejected. The permission android.permission.FOREGROUND_SERVICE is added to our AndroidManifest, we are reviewing why since, we actually did not add it. I think is because of the Service definition (image below), the other permission was not added, I mean the ForegroundServiceMediaPlayback.

[pictos]

@Elinares-82 this issue with scroll view and keyboard is reported on Maui repo? If don't, do you mind to it?

[Elinares-82]

I created a blank Maui app targeting dotnet 9. I then added the package after building and creating a nuget. I did not add anything to android manifest. I did add this to builder:

.UseMauiCommunityToolkitMediaElement(options => options.SetDefaultAndroidForegroundService(false));

It works as expected and service is disabled. Note that the rich media notifications do not work without the service. This is one of the tradeoffs.

@ne0rrmatrix I just tested the PR, I was able to create the nuget and load it to my DevOps Artifacts. The only additional thing that I had to do was downgrade the Microsoft.Maui.Controls to 9.0.40, since the 9.0.50 and 9.0.60 has and issue with the Keyboard and the Scroll, when the Keyboard appear the scroll of the view does not work as expected and the user is not able to scroll the view to see other controls. We are currently loading the aab file to the Google Store, I let you know if the app is approved. Thanks so much.

Hi, our app was rejected. The permission android.permission.FOREGROUND_SERVICE is added to our AndroidManifest, we are reviewing why since, we actually did not add it. I think is because of the Service definition (image below), the other permission was not added, I mean the ForegroundServiceMediaPlayback.

Apparently is a rejected error was for a previous version of the app. We do not know why Google is rejecting the app for previous versions that have those permissions. We send an update that override the old versions (This was made in the Play Console)

[Elinares-82]

@Elinares-82 this issue with scroll view and keyboard is reported on Maui repo? If don't, do you mind to it?

@pictos sure, I'll check is this issue was already reported, in case not, I'll do it!

[Elinares-82]

Finally, our apps were approved by Google. Thanks. Now I'm reviewing the issue regarding the Scroll and Microsoft.Maui.Controls 9.0.50 and 60. and log it into the repo.

[Elinares-82]

Finally, our apps were approved by Google. Thanks. Now I'm reviewing the issue regarding the Scroll and Microsoft.Maui.Controls 9.0.50 and 60. and log it into the repo.

The issue is already logged

dotnet/maui#19014

2023 almost 2 years ago.