[Bug]: onTextTracks/onAudioTracks report selected:false on Android when controls are enabled (regression in 6.16.0)

[janpe]

What happened?

With controls enabled, onTextTracks and onAudioTracks report every track with
selected: false, even while a track is active (native picker or selectedTextTrack /
selectedAudioTrack). There is then no way for JS to know which track is selected: the native
picker doesn't update the controlled props, onTextTrackDataChanged only carries cue text, and
the ref exposes no getter. onLoad reports the initial selection but not later changes.

Expected: report the real selected state regardless of controls, consistent with the
controls-off path and iOS.

Root cause
In v6.15.0 onTracksChanged had no controls branch - it always used the selection-aware
getTextTrackInfo() / getAudioTrackInfo(). PR #4581 (media3 PlayerView migration, 6.16.0)
added an if (controls) branch that instead calls getBasicTextTrackInfo() /
getBasicAudioTrackInfo(), both of which hard-code setSelected(false) // ... let PlayerView handle it. onTracksChanged is the only emitter of these events, so selection is lost entirely
in that mode.

Fix
Have the basic methods compute selected via
isTrackSelected(player.getCurrentTrackSelections()...), as the controls-off methods already do.

Steps to reproduce

1. Render <Video controls /> with an HLS stream that has multiple subtitle/audio tracks.
2. Change the track via the native picker.
3. Log onTextTracks / onAudioTracks - every track reports selected: false.
4. With controls={false}, the correct track is reported.

Reproduction repository

No response

react-native-video version

6.19.2

react-native version

No response

react-native-nitro-modules version

No response

Platforms

Android

OS version

No response

Device

No response

Architecture

No response

Expo

No response

Last working version

6.15.0

Media / source type

HLS (.m3u8)

[TWG-AI]

Thanks for the thorough root cause analysis — identifying PR #4581 as the regression point and the specific methods involved makes this very actionable.

This has been logged as a high-priority item for the team. The fix direction (computing actual track selection state in the basic methods instead of hardcoding false) is clear.

Note: I'm an AI and may have missed context. If anything above is off, please let me know.