Add AdaptiveTrackSelection format priority ordering hooks

[AndyWangLYN]

Summary

This change adds extension points to AdaptiveTrackSelection so apps can control candidate format priority beyond default bitrate ordering, while preserving existing ABR behavior by default.

What Changed

Added getFormatPriorityOrder(...) hook to let developers provide an explicit per-update format priority list.
Added getFormatIndexForPriorityPosition(...) hook (default bitrate-descending behavior) for position-based custom ordering.
Updated ideal-index selection to use custom priority when provided.
Kept default behavior unchanged when hooks are not overridden.
Added validation/fallback behavior for invalid custom priority order:
invalid order is ignored with a warning
selection falls back to default ordering
Added unit coverage in AdaptiveTrackSelectionTest proving a custom priority order can be applied.

Why

Current adaptive selection effectively prioritizes higher bitrate first. This makes it hard to prioritize developer-defined rules (for example, quality score ranking). These hooks allow custom ordering without changing core ABR switching logic.

Compatibility

No behavior change for existing users.
No API break for default usage.
Buffer-based switch-up/switch-down logic remains unchanged.

Testing

Ran:
gradlew :lib-exoplayer:testDebugUnitTest --tests androidx.media3.exoplayer.trackselection.AdaptiveTrackSelectionTest
Result: BUILD SUCCESSFUL

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[tonihei]

This makes it hard to prioritize developer-defined rules (for example, quality score ranking).

Do you have an concrete example where this logic applies? If there is a format with a higher bitrate and a lower quality, I don't see a case where it would ever be beneficial to select that format. If that's the case, a better approach to solve your underlying issue may be to ensure that format is never part of the ABR selection ladder to start with.

Example:

• bitrate: 100, quality: 50
• bitrate: 200, quality: 70
• bitrate: 250, quality: 65 -> this Format is strictly worse than the one above in all scenarios and should never be considered
• bitrate: 300, quality: 80

These hooks allow custom ordering without changing core ABR switching logic

The concept of bitrate ordering is quite deeply engrained into the AdaptiveTrackSelection class and even the interface TrackSelection that requires Format instances to be sorted by bitrate. So besides the method you updates already, there are more places that would need to be touched.

[AndyWangLYN]

Hey @tonihei thank you for reviewing and commenting on my PR. This is an ABR customization issue I've encountered where server-side pruning isn't feasible because the 'best' track is device-dependent. For example, in a mixed-codec manifest, a more efficient codec can provide higher quality at a lower bitrate. Furthermore, on devices without hardware AV1 decoding, a high-bitrate AV1 rendition may cause stuttering compared to a lower-bitrate AVC rendition.
Regarding your point on bitrate ordering being engrained in the interface: I've tried to keep the hooks as non-intrusive as possible, aimming to give developers options for track priority only during ABR. But I'm open to suggestions on how to better align this with the existing architecture. Thank you!

[AndyWangLYN]

Based on the comment above, opened a new PR: #3068 to better address the track format sorting from the base level. Intend to close this PR once that one is deemed good.

[AndyWangLYN]

Let's move the conversation to this PR: #3068 in which I propose a better and more robost way to sort format tracks. Thank you! @tonihei @oceanjules