[video_player_android] allow supplying a custom VideoAsset

[a1rwulf]

Adds VideoAssetProvider and VideoPlayerPlugin.setVideoAssetProvider, which is consulted before this plugin's own URI handling and may return null to fall through to it.

This is the extension point for playback the plugin cannot express itself: reading from a download or HTTP cache, applying a custom DataSource.Factory, or resolving a scheme the plugin does not know about. VideoAsset is already public and already exposes MediaItem and MediaSource.Factory, so this adds no new type surface; it only makes the existing one reachable.

Behavior is unchanged when no provider is registered, which the added tests cover alongside the override path.

This enables me to publish a companion package to allow downloading of HLS on Android and iOS.
Companion package source:
https://github.com/a1rwulf/video_player_offline

This is an attempt to upstream a fix for:
flutter/flutter#59759

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. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request introduces VideoAssetProvider and VideoPlayerPlugin.setVideoAssetProvider to the Android video player plugin, enabling custom video asset resolution for URIs. It also adds unit tests to verify this behavior and bumps the package version to 2.13.0. The reviewer recommended marking the static videoAssetProvider field as volatile to ensure thread visibility and prevent stale reads.

[gemini-code-assist]

Since videoAssetProvider is a static field that can be set from any thread (e.g., during background initialization or dependency injection) and read on the main thread, it should be marked as volatile to ensure thread visibility and prevent stale reads.

Suggested change

	private static @Nullable VideoAssetProvider videoAssetProvider;
	private static volatile @Nullable VideoAssetProvider videoAssetProvider;

[stuartmorgan-g]

Adding @mboetger to review for whether allowing modification of ExoPlayer internals like this is something we want to expose; generally we minimize native hook points as they can significantly reduce our ability to make non-breaking updates in the future.

VideoAsset is already public and already exposes MediaItem and MediaSource.Factory, so this adds no new type surface; it only makes the existing one reachable.

Adding @bparrishMines to guide the design here if this does move forward. We traditionally do not consider our native plugin code to be a public API surface, and instead consider it equivalent to lib/src/. When we deviate from that we do so in limited and clearly documented ways, and @bparrishMines can point to examples of what that would look like.