[video_player_android] Enable ExoPlayer decoder fallback

[remyturpin-veesion]

Enables setEnableDecoderFallback on the DefaultRenderersFactory backing the ExoPlayer instance, so playback falls back to a lower-priority decoder when the preferred one fails to initialize, instead of surfacing an ExoPlaybackException.

On some devices MediaCodecUtil reports a format as supported, the hardware decoder is selected, and initialization fails anyway. Playback then aborts even though a working software decoder is present on the device.

Reproduced on a Lenovo Tab M10 FHD Plus (MediaTek mt6765, Android 10). ExoPlayer selects OMX.MTK.VIDEO.DECODER.AVC, and ACodec cannot raise the output buffer count past the value the decoder declares:

[OUTPUT] nBufferCountActual(7)
setParameter(ParamPortDefinition) ERROR: BadParameter(0x80001005)
setting nBufferCountActual to 14 failed: -22
setting nBufferCountActual to 13 failed: -22
setting nBufferCountActual to 12 failed: -22
setting nBufferCountActual to 11 failed: -22
E/ACodec: Failed to allocate buffers after transitioning to IDLE state (0xffffffea)
E/MediaCodec: Codec reported err 0xffffffea, actionCode 0, while in state 5

The failure is in buffer negotiation rather than codec capability, which is why the error carries format_supported=YES and reproduces at any resolution or profile — verified from 480p Main@3.1 to 1080p High@4.0. With the flag enabled, playback proceeds on c2.android.avc.decoder.

Verified by building the same application twice, differing only in this flag: playback fails every time without it and succeeds every time with it, on the same device and the same videos.

Fallback only engages after the preferred decoder has already failed to initialize, so the trade-off is a possibly slower decoder rather than no playback at all.

Related to flutter/flutter#185674 — same error signature, reported there on Huawei hardware. The device used here is a MediaTek tablet, so the underlying vendor failure may differ, but the fallback path is the same.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request enables ExoPlayer's decoder fallback in both PlatformViewVideoPlayer and TextureVideoPlayer by configuring DefaultRenderersFactory with setEnableDecoderFallback(true). It also adds a corresponding unit test in TextureVideoPlayerTest to verify this behavior, and bumps the package version to 2.12.3 in pubspec.yaml and CHANGELOG.md. There are no review comments, so no additional feedback is provided.