[video_player] Improve seek performance on Android

[sailendrabathi]

Adds backBufferDurationMs to VideoPlayerOptions and configures ExoPlayer's DefaultLoadControl to retain the back buffer from keyframes. This significantly improves seek performance and responsiveness during video playback on Android.

iOS already has some kind of back buffering implemented in AVPlayer because the replays and seeks are instantaneous for small videos.

Before:
Replays and seeks on Android for network based video assets involve a network call to fetch the video content. This significantly hampers the user experience.

After:
Replays and seeks on Android (within the back buffer duration) are instant just like in iOS. Improving user experience

This PR partly addresses flutter/flutter#97428. Not enabling back buffering by default and instead allowing the app to configure as per need. The default behavior will be same as the existing implementation to avoid any regressions.

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[^1].
• 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[^1].
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request adds the backBufferDurationMs option to VideoPlayerOptions to configure the ExoPlayer back buffer duration on Android, updating the platform interface, Android implementation, and adding no-op stubs for AVFoundation and Web. Feedback on the changes highlights that passing backBufferDurationMs via a global setter on Android can cause state persistence and race conditions during concurrent player initialization, and recommends passing this option directly through CreationOptions instead.

[gemini-code-assist]

Code Review

This pull request adds support for configuring ExoPlayer's back buffer duration on Android by introducing backBufferDurationMs to VideoPlayerOptions and forwarding it through the platform interface to the Android implementation. The Android plugin updates PlatformViewVideoPlayer and TextureVideoPlayer to configure ExoPlayer's DefaultLoadControl using this value, supported by new unit tests. Feedback suggests correcting an inaccurate comment regarding how backBufferDurationMs is passed and adding an assertion to ensure the duration is positive if provided.

[mboetger]

There's multiple formatting issues with this PR.

[mboetger]

Why a long? Seems like it's an int everywhere else.

[sailendrabathi]

This is to handle the conversion from dart to java.

We keep as a Long in VideoPlayerOptions.java to maintain alignment with Pigeon's generated CreationOptions object.

We then safely clamp the Long into a int at PlatformViewVideoPlayer.java and TextureVideoPlayer.java to match DefaultLoadControl's expected int parameter.

[mboetger]

You have a bunch of test failures - both formatting and issues stemming from the versioning. You need to follow the instructions here: https://github.com/flutter/flutter/blob/master/docs/ecosystem/contributing/README.md#changing-federated-plugins if you want the tests to pass and get a proper review

[stuartmorgan-g]

@mboetger Please make sure a PR has all the necessary approvals before requesting that it be split up, as the goal is for the sub-PRs to be trivially approved due to already having all the necessary reviews. This still needs an ecosystem-team-level review for the general API changes.

[tarrinneal]

Looks solid to me, feel free to re-break out the sub pr's

[sailendrabathi]

@stuartmorgan-g @mboetger created another sub PR for android changes: #12124. PTAL

[sailendrabathi]

I synced to main, dropped the dependency override commits and pushed the commits.

[tarrinneal]

versioning says this will need to be 3.12.0 to merge, I'm not sure that's what we want though @stuartmorgan-g can you weigh in on that?

[stuartmorgan-g]

Yes, this is expected, and is a common case for our federated plugins. The way it generally plays out is:

• One of the platform implementations has a platform-specific reason to drop N-1/2, often related to some OS or platform tooling change (in this case it looks like it was supporting AGP 9, which required some functionality that's only in current stable). Our policy is that support for stable is required, but support for N-1/2 is entirely discretionary; packages authors are free to drop them when there's any reason to do so.
• That doesn't immediately affect the app-facing package, because the app-facing package is still compatible with older versions of the platform implementation package, and the resolver will do the right thing for people on N-1/2.
• Some later PR that adds a new feature needs to update the min version of the platform implementation to ensure that feature support is present when people try to use it (e.g., this PR). Because there's no longer a compatible platform implementation that supports N-1/2, the app-facing package needs to drop N-1/2 as well.

As a general rule of thumb: if the only thing failing is analyze_legacy, the right thing to do is raise the min SDK version unless the package owner has a compelling reason that they want to support N-1/2.

[stuartmorgan-g]

(We'll see if this picks up any new analyzer or formatter behavior that requires other minor changes.)