[video_player_android] Add video track selection support

[nateshmbhat]

Summary

Android breakout PR for #10688.

• Implements getVideoTracks() and selectVideoTrack() methods using ExoPlayer's TrackSelectionOverride
• Adds onVideoTrackChanged event callback for track change notifications
• Adds comprehensive Java and Dart unit tests

Dependency Chain

This PR is second in a series of breakout PRs:

1. video_player_platform_interface ([video_player_platform_interface] Add video track selection support #11474) - pending
2. video_player_android (this PR)
3. video_player_avfoundation (pending)
4. video_player + video_player_web (pending - original PR [video_player] : Add video track selection support for Android and iOS #10688 updated)

Note: This PR depends on video_player_platform_interface 6.7.0 being published first.

Test Plan

• Java unit tests for getVideoTracks() and selectVideoTrack() in VideoPlayerTest.java
• Java unit tests for onVideoTrackChanged callback in VideoPlayerEventCallbacksTest.java
• Dart unit tests for AndroidVideoPlayer overrides

[gemini-code-assist]

Code Review

This pull request introduces video track selection capabilities to the Android video player plugin. Key changes include adding getVideoTracks(), selectVideoTrack(), and enableAutoVideoQuality() methods to the VideoPlayerInstanceApi and their implementations in VideoPlayer.java and android_video_player.dart. A workaround is implemented in selectVideoTrack to handle video dimension changes by temporarily disabling and re-enabling the video track type to force a renderer reset. New Pigeon messages and data structures are introduced to support video track information exchange, and ExoPlayerEventListener is updated to notify about video track changes. Comprehensive unit tests for the new video track functionalities have also been added. The review comment points out a potential crash risk in the postDelayed workaround within VideoPlayer.java if the player is disposed during the 150ms delay, as the current trackSelector == null guard is ineffective. It recommends using a cancellable callback mechanism or an isDisposed flag for robust handling.

[gemini-code-assist]

The postDelayed workaround for dimension changes introduces a potential crash risk. If the VideoPlayer is disposed (and the ExoPlayer released) during the 150ms delay, the calls to exoPlayer.seekTo() and exoPlayer.play() inside the delayed callback will throw an IllegalStateException because the player has been released.

The current guard if (trackSelector == null) (line 414) is likely ineffective because trackSelector is a final field in this class and is not nullified during the dispose() call in the current implementation of this plugin.

Recommendation:
Use a mechanism to cancel the pending callback or a robust way to check if the player has been disposed. For example, you could use a member Handler and call handler.removeCallbacksAndMessages(null) in dispose(), or maintain an isDisposed boolean flag that is set to true in dispose() and checked at the beginning of the delayed callback.

[mboetger]

Please address this.

[nateshmbhat]

Addressed in 7bdc032. Switched to a member Handler plus an isDisposed flag; dispose() now calls removeCallbacksAndMessages(null) and sets the flag before releasing the player, so the 150 ms dimension-change callback cannot run on a released ExoPlayer. Added a Robolectric regression test (testSelectVideoTrack_disposeDuringDimensionChangeDelayDoesNotCrash) that uses ShadowLooper.idleFor(200ms) after dispose() and asserts no seekTo/play is invoked.

[stuartmorgan-g]

This PR requires #11474 to land and be published.

[nateshmbhat]

@stuartmorgan-g PR unblocked. good to merge ?

[gemini-code-assist]

Code Review

This pull request implements video track selection for the Android video player using ExoPlayer, including methods to retrieve available tracks, select a specific track, and enable auto-quality selection. The implementation includes a workaround for renderer resets when video dimensions change and updates the Pigeon-generated messaging layer. Feedback is provided regarding potential race conditions in the Dart selectVideoTrack implementation where concurrent calls could overwrite shared state, and concerns are raised about state inconsistency and potential crashes during the 150ms delay used for dimension-change renderer resets.

[gemini-code-assist]

The selectVideoTrack implementation is vulnerable to race conditions when multiple calls occur concurrently. Since _videoTrackSelectionCompleter and _expectedVideoTrackId are shared fields, a second call will overwrite the state of an ongoing first call. Additionally, the finally block of the first call to complete will clear these fields, which can cause subsequent calls to timeout or resolve prematurely with incorrect state. Using local variables to guard the cleanup ensures that each call only clears the fields if it is still the 'current' active request.

Future<void> selectVideoTrack(VideoTrack? track) async {
finalCompleter<void> completer =Completer<void>();
_videoTrackSelectionCompleter = completer;
finalString? expectedId = track?.id;
_expectedVideoTrackId = expectedId;
try {
if (track ==null) {
// Auto quality - use dedicated methodawait _api.enableAutoVideoQuality();
} else {
// Extract groupIndex and trackIndex from the track idfinalList<String> parts = track.id.split('_');
if (parts.length !=2) {
throwArgumentError(
'Invalid track id format: "${track.id}". Expected format: "groupIndex_trackIndex"',
);
}
finalint groupIndex =int.parse(parts[0]);
finalint trackIndex =int.parse(parts[1]);
await _api.selectVideoTrack(groupIndex, trackIndex);
}
// Wait for the onTracksChanged event from ExoPlayer with a timeoutawait completer.future.timeout(
constDuration(seconds:5),
onTimeout: () {
// If we timeout, just continue - the track may still have been selected
},
);
} finally {
if (_videoTrackSelectionCompleter == completer) {
_videoTrackSelectionCompleter =null;
}
if (_expectedVideoTrackId == expectedId) {
_expectedVideoTrackId =null;
}
}
}

[mboetger]

And this

[nateshmbhat]

Addressed in 7bdc032. Captured the completer and expected id in locals (completer, expectedId) and guarded the finally cleanup with identical(_videoTrackSelectionCompleter, completer) / _expectedVideoTrackId == expectedId, so an older overlapping selectVideoTrack call can no longer null out a newer call's state. Also merged the null/non-null track branches to remove the duplicated wait/cleanup logic. Added a regression test (concurrent selectVideoTrack calls do not clobber each other) that fails fast on call 1 and verifies call 2 still completes on its matching VideoTrackChangedEvent.

[stuartmorgan-g]

@stuartmorgan-g PR unblocked. good to merge ?

No PRs can me merged without review. This needs final re-review by the folks who looked at the original combination PR.

[tarrinneal]

Is it possible these could end up not being ints? int.parse will crash if so.

[nateshmbhat]

No not possible

[nateshmbhat]

Updated this path to parse Android track IDs with int.tryParse and throw ArgumentError if the numeric contract is violated, rather than letting a FormatException bubble out. Added a regression test for non-numeric track IDs as well.

[tarrinneal]

might be worth logging something for debugging purposes.

[nateshmbhat]

Added debug logging on the 5-second timeout path so we emit whether the stalled selection was for a specific track or auto quality selection. There is also a test that advances the timeout and asserts that the log is produced.

[nateshmbhat]

@mboetger have addressed your concern and pushed fix.

[mboetger]

My biggest concern with the PR is this delay. It seems to be device dependent too - so on lower end devices, this probably just won't work. That being said, I recognize this is new functionality and their is no exoplayer api to alleviate this. I'll give it approval, but not a big fan.

[nateshmbhat]

@tarrinneal good to merge?

[stuartmorgan-g]

@nateshmbhat The PR needs two approvals to land, so no. I'm not a reviewer for this PR, so I'm not sure why you are pinging me.

[tarrinneal]

lg two nits

[stuartmorgan-g]

@tarrinneal Anything missing for this to be autosubmitted?

[tarrinneal]

@tarrinneal Anything missing for this to be autosubmitted?

formatting mostly

[nateshmbhat]

formatting fixed @stuartmorgan-g@tarrinneal