The constant has been renamed to COMMAND_SEEK_TO_NEXT_MEDIA_ITEM.

The JavaDoc of the deprecated Player.seekToNextWindow says:

/**
   * @deprecated Use {@link #seekToNextMediaItem()} instead.
   */

This means that the method is deprecated and that you can use the seekToNextMediaItem instead.

Does that mean that complex timelines with a mismatch between windows and playlist items are no longer supported?

I'm not quite sure how this should be understood. A Timeline.Window always has a MediaItem. A media source that creates the timeline has to provide N windows of which the timeline consists. Each window has a field MediaItem that needs to be set by the timeline when for instance timeline.getWindow(/* index= */ 0, new Timeline.Window()) is called.

Thanks for your answer. I misunderstood the concept underlying Windows, indeed. As the doc claims that a window usually corresponds to one playlist item, I thought there was not mandatorily a one-to-one relationship between windows and media items.

What I would like to do is introduce a distinction between, on one side logical media items which one can navigate between, and on the other side, "physical" audio tracks we ask Exolayer to play. For instance, seekToNextMediaItem could go two tracks or only half a track forward depending on the logical timeline structure. I think this could be achieved by implementing a custom Player wrapping ExoPlayer. Is that correct? Isn't there anything built in media3 to make it easier to do?

For switching only half a track you could try a ClippingMediaSource or by setting the ClippingConfiguration of the MediaItem. For concatenating two media items to a single media item, you could use ConcatenatingMediaSource2.

The latter is not yet public because it has some restrictions of use that are tricky. But if that would be useful we can open source this ConcatenatingMediaSource2.

I think that would enable your use case by clipping and concatenating accordingly. The following media items

[a] [b] [c] [d] [e] [f]

could become by concatenation/clipping a logical timeline as for instance the 4 windows:

[a, b] [c first half] [c second half] [d,e,f] 

where a pair of brackets is a media item/window with an index in the timeline. Window [a,b] and [d,e,f] are concatenated and window at index 1 and 2 is each a clip from the same media item by clipping.

That sounds good, thanks! I can see a public ConcatenatingMediaSource (without 2) in the source tree. What's the difference?

The ConcatenatingMediaSource does not concatenate to a single window. It was required to create a playlist with multiple windows before playlist support was added as a top-level API to the Player interface. With the top-level API, apps don't need that anymore and we recommend migrating to the top-level API instead.

I'll open source ConcatenatingMediaSource2 to make it publicly available for use.

Got it, thanks!