CommunityToolkit
[BUG] MediaElement throw a `MissingMethodException`
Is there an existing issue for this?
- [x] I have searched the existing issues
Did you read the "Reporting a bug" section on Contributing file?
- [x] 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 using CommunityToolkit.Maui.MediaElement (6.1.1), and referencing a version of Xamarin.AndroidX.Media3.ExoPlayer higher than 1.6.1.1, the application crashes at runtime with a System.MissingMethodException.
The error occurs when the binding attempts to access IExoPlayer.get_PlayerError(). This method is expected to return an ExoPlaybackException, but starting from Media3.ExoPlayer 1.6.1.2, it appears the method has either been removed, renamed, or its return type changed, breaking the generated binding.
📛 Exception thrown:
System.MissingMethodException: Method not found: AndroidX.Media3.ExoPlayer.ExoPlaybackException AndroidX.Media3.ExoPlayer.IExoPlayer.get_PlayerError()
This crash occurs even though the NuGet dependency allows (>= 1.5.0), which suggests newer versions are supported — but in practice, versions above 1.6.1.1 are not compatible.
Expected Behavior
Either:
- The toolkit should update its binding to support Media3.ExoPlayer versions 1.6.1.2 and above, OR
- The NuGet dependency should be pinned to <= 1.6.1.1 explicitly (e.g., "[1.5.0, 1.6.1.2)"), to prevent incompatible versions from being resolved.
Steps To Reproduce
-
Create a new .NET MAUI app
-
Add CommunityToolkit.Maui.MediaElement (version 6.1.1)
-
Add a PackageReference to Xamarin.AndroidX.Media3.ExoPlayer version 1.6.1.2 or 1.7.1
-
Use MediaElement to play any media
-
App crashes at runtime with:
System.MissingMethodException: Method not found: AndroidX.Media3.ExoPlayer.ExoPlaybackException AndroidX.Media3.ExoPlayer.IExoPlayer.get_PlayerError()
Link to public reproduction project repository
https://github.com/AntoninLolivier/MediaElementMissingMethodRepro.git
Environment
- .NET MAUI CommunityToolkit: 6.1.1
- OS: Windows 11
- .NET MAUI: 9
Anything else?
project.assets.jsonconfirms that the expected dependency is Media3.ExoPlayer 1.5.0- The NuGet dependency version range allows (>= 1.5.0), so NuGet may auto-resolve to newer, incompatible versions
- Method
getPlayerError()returned ExoPlaybackException in 1.5.0 → 1.6.1.1 - Breaking change observed in 1.6.1.2 and above: method no longer present with expected JNI signature
- ✅ Known working version: 1.6.1.1
- ❌ Known broken versions: 1.6.1.2, 1.7.1
- ❗️ Exception: System.MissingMethodException: Method not found: AndroidX.Media3.ExoPlayer.ExoPlaybackException AndroidX.Media3.ExoPlayer.IExoPlayer.get_PlayerError()
We update dependencies when needed. We don't upgrade them without a specific reason. Is there any reason you can't use 1.5.0? Is there a new method or class that you need access to? Is the upgraded version a bug fix for something that does not work for you?
I am curious as to why you are loading those nugets directly? Your sample does show the issue, which is an issue common with transient dependencies on android. We generally upgrade our nugets inline with Dotnet Maui to have the widest compatibility with developers.
Thanks for the quick response!
You're totally right — in my case, I'm not asking for the toolkit to upgrade to a newer version of Media3. I actually have no problem using version 1.5.0, and now that I know it's the maximum compatible version, I'm explicitly locking it.
However, the purpose of this issue is to clarify that the current dependency specification in NuGet allows (>= 1.5.0), which gives the false impression that higher versions (like 1.6.1.2, 1.7.1, etc.) are compatible. In practice, they are not — and referencing them results in a hard crash at runtime due to a missing method (get_PlayerError()).
This is especially important for developers who:
- Explicitly reference Media3 packages because they're doing advanced native interop (like I am),
- Or who rely on transitive dependency resolution and end up with a newer version unintentionally.
Since MAUI/Android projects can resolve newer versions via transitive dependencies, and because NuGet considers >= 1.5.0 valid, this can lead to hard-to-diagnose runtime errors that appear unrelated to the app code.
To be clear:
- I am totally fine using version
1.5.0. - I’m not asking for you to update to newer versions.
- This issue is simply to suggest that the version range be clarified or tightened (e.g.,
[1.5.0, 1.6.1.2)) to avoid unintentional breakage for other developers.
Thanks again 🙌
Thank you for the clear response! It does sound like we want to pin the version then
Pinning the version is only a stop gap solution. It will not be until dotnet 10 or maybe 11 that the android team might have a solution. I do know that it is being worked on but the timeline is not certain. An example of why specifically this is currently an issue is due to changes in class and method signatures between 1.5.0 and 1.6.1.2 which requires change to media element to fix this. This happens relatively frequently in Android and will require updates when Maui's transitive dependencies make Media Elements dependencies incompatible. This issue current requires a min version and has an upper limit.
We also need to consider our camera nugets and work with that limitation as their transitive dependencies are also complicated and can be incompatible with media elements. It is a complicated mess. My vote is if it is not required do not upgrade it.
Another consideration we need to look at is the transitive dependencies for media element and camera can be out of sync, which has happened a few times over the last year. That can be worked around by pinning specific package references which is considered to be actual magic that has over the last few years been refined to a long thread on Microsoft Android Support libs Github page.
We can update the docs to reflect pinned versions but anyone can look at nuget dependencies and see what is min or max version of each on nuget.org
Edit: I re-read the original issue and want to say I am sorry I missed the part where you provided an example of exactly what the issue is. I will work on updating the docs to address this.
If things have broken multiple times recently I would argue that pinning to a specific version range would be a solution and not a stop gap - it would prevent developers from being able to install incompatible versions whether transient or not. A developer might not realise they are installing an incompatible version if they install another library that depends on a newer version, pinning would protect them from that surely?
My experience with this issue:
I use Xamarin.AndroidX.Media3.ExoPlayer package explicitly because default 1.5.0 version has type issues and ProgressiveMediaSource type can't be used for media caching, I need to use higher version, but as this GitHub issue suggest max version that works is "1.6.1.1".
So it seams only reasonable solution could by to document specific package version range.
Hi team, thanks for tracking the MediaPlayerElement issue with Media3 alignment. Considering that starting November 1, 2025, all new apps and updates targeting Android 15+ must support 16 KB memory page sizes, I’m wondering: how do we plan to reconcile this requirement with MediaPlayerElement's current use of native libraries?
Will the MAUI and Toolkit teams ensure that MediaPlayerElement (and its ExoPlayer integration) is compiled or packaged in a way that's 16 KB page-size compatible?
Without that, apps using MediaPlayerElement could fail to run on 16 KB devices, even if the rest of the app targets that API level.
Can you clarify whether there's already work in progress on this front, or if there are guidelines for developers to follow—especially around packaging and alignment for native libs used by MediaPlayerElement?
