The motivating example for this issue is that MediaItem.Builder#setDrmSessionForClearPeriods() is silently ignored if MediaItem.Builder#setDrmUuid() is not set (#8842 (comment)).

From an implementation details perspective it's understandable that the UUID is required for any of the other DRM fields to be useful, but the silent dropping of the value (rather than failing during build()) leads to confusing behaviour for users of the API who believe they're calling a method and have no indication it's having no effect.

This issue tracks changing MediaItem.Builder to more aggressively fail during build() if some setters have been called that are going to be ignored.

This isn't limited to the DRM fields, there are many other examples (the javadoc has lots of text like "If setUri(java.lang.String) is passed a non-null uri, the MIME type is used to create a MediaItem.PlaybackProperties object. Otherwise it will be ignored.").

Some apps may be (intentionally or unintentionally) depending on the existing silently-drop behaviour, so we may need to consider making this change gradually, e.g. by introducing a buildStrict() method which fails loudly and deprecating the silently-ignoring build() method. (this specific example is a shame because we'd really like to end up in a final state where the method is called build() (since that seems like obviously the correct name) - so it might be enough to instead change the behaviour of build() and introduce a temporary buildLenient() method with the 'old' behaviour that apps can switch to if they observe problems with the strict behaviour).