feat(rendering): allow multiformat (banner + video) on BannerView

[nsp37]

Intent to implement

#999

Problem

The rendering BannerView can only request a single format:

• its constructors set AdFormat.BANNER, and
• setVideoPlacementType(...) calls adUnitConfig.setAdFormat(VAST), which clears banner → video-only.

So a rendering-API banner placement can't let banner and outstream video compete on one impression — unlike InterstitialAdUnit(context, configId, EnumSet.of(AdUnitFormat.BANNER, AdUnitFormat.VIDEO)) and the original API (#610). Requested for banner in #621, where only interstitial was addressed.

Change

Add two passthroughs to BannerView, delegating to the already-public AdUnitConfiguration API (the same one InterstitialAdUnit uses):

public void setAdUnitFormats(EnumSet<AdUnitFormat> adUnitFormats)  // -> adUnitConfig.setAdUnitFormats(...)
public void setVideoParameters(VideoParameters videoParameters)    // -> adUnitConfig.setVideoParameters(...)

Why no renderer changes are needed

BannerView → DisplayView → PrebidRenderer.createBannerAdView → PrebidDisplayView, and PrebidDisplayView already branches on BidResponse#isVideo() (VideoView for VAST, banner otherwise). Only the request-side format set was gated; the render path already handles the winning format.

Notes

• Mirrors the iOS rendering BannerView, which already exposes adUnitConfig.adFormats — this closes an Android/iOS asymmetry.
• Happy to add unit tests and a demo-app example, and/or an EnumSet<AdUnitFormat> constructor instead of setters, per maintainer preference — kept this minimal for PMC review of Intent to implement: multiformat (banner + outstream video) on the rendering BannerView #999 first.
• CLA: I'll complete the Prebid CLA via cla-bot.

---

Disclosure: implemented with AI assistance (Claude Code); reviewed and submitted by @nsp37.

🤖 Generated with Claude Code

[nsp37]

Thanks for the thorough review — both points were spot-on. Pushed a follow-up commit taking option (a).

setVideoParameters() inert beyond ad size: relaxed the gate in BasicParameterBuilder.setVideoImpValues() so it reads VideoParameters on the rendering path too, not just when isOriginalAdUnit():

if (adConfiguration.isOriginalAdUnit() || adConfiguration.getVideoParameters() != null)

It's guarded on getVideoParameters() != null, so rendering units that never call setVideoParameters keep the existing default branch untouched — no behavior change for current rendering interstitials. I deliberately did not flip isOriginalAdUnit since it drives far more than video imp building.

Non-interstitial video.placement: this is resolved by the same change rather than a new setter — the caller's VideoParameters carry placement/plcmt, which the now-reachable branch reads, so a multiformat BannerView no longer falls back to PlacementType.INTERSTITIAL. That avoids the setVideoPlacementType() conflict you noted (it collapses formats to VAST-only, so it can't combine with setAdUnitFormats anyway).

Happy to add tests or adjust the approach (e.g. a dedicated non-original branch instead of the ||) if you'd prefer.