[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

[sailendrabathi]

Only 3 CI tests were failing in the earlier run

1. Linux_android_legacy android_platform_tests_legacy_api_shard_5 master: Unrelated failure

2. Linux_android android_platform_tests_shard_5 master: Added a commit to fix the lint error, 4th commit in the chain.

3. Linux repo_checks:
   a. format: Fixed this. Caused due to incorrect dart sdk version used by format tool.
   b. license validation: Fixed this.
   c. repository standards validation: Fixed this. Caused due to incorrect formatting of unrelated package.
   d. federated change: expected due to platform interface change.
   e. publishability: expected due to version bumps in the PR.

[gemini-code-assist]

Code Review

This pull request adds support for configuring ExoPlayer's back buffer duration on Android by introducing backBufferDurationMs to VideoPlayerOptions. The option is passed from the video_player package through the platform interface to the Android implementation, where it configures the DefaultLoadControl of the ExoPlayer instance. The changes include updated Pigeon-generated files, tests, and example configurations. Feedback on the pull request identifies redundant manual mock initializations in PlatformViewVideoPlayerTest.java that are already handled by the Mockito rule.

[sailendrabathi]

@mboetger, only one test failing, with expected failures.

Linux repo_checks

1. Repository standards validation: Fails complaining about missing version bumps in packages like video_player_web and video_player_avfoundation . These packages were only modified by make-deps-path-based` to add temporary overrides;
2. federated safety check: Fails because pubspec.yaml contains DO NOT MERGE. As mandated by Flutter's changing federated plugins contributing guide
3. publishability: Fails because video_player and video_player_android have active dependency_overrides

[mboetger]

LGTM - please proceed with the next PR per the federated PR guidlines: https://github.com/flutter/flutter/blob/master/docs/ecosystem/contributing/README.md#changing-federated-plugins

[sailendrabathi]

@mboetger, created a PR for platform interface changes: #11932. Please 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