How to Test Mini Program Small-Window Playback on Native and WebView Routes Across iOS and Android
Small-window playback should be tested in the actual Mini Program journey, especially the transition from a live room to a product page.
Small-window playback should be tested in the actual Mini Program journey, especially the transition from a live room to a product page. POLYV documents two routes: a native viewing page requests background playback from its active native player, while a WebView live room moves to a native intermediary page whose video component plays the live stream. Both depend on WeChat and OS versions, permissions, configuration and player state.
Small-window playback starts with the active native player; a WebView live route also needs its intermediary and return path tested.
01 / Check the active playback node
The POLYV integration guide says background playback is carried by a native <video> or <live-player> component. requestBackgroundPlayback() does not accept a media URL; the URL must already be bound to the active component. In the native POLYV room, watchCore.player.requestBackgroundPlayback() wraps the corresponding WeChat Context method. A visible button alone does not show that the active player and API call are ready.
02 / Test the native path in sequence
Start a live stream, request the small window and record whether video and audio continue. Open a product page, switch tabs and return to the room. Check for duplicate playback, lost channel state or stale controls. Repeat with manual close, stream end, channel switch and weak-network recovery. If co-hosting is required, verify player and live-pusher eligibility separately.
03 / Inspect the WebView intermediary
From the H5 live room, open the native intermediary and confirm its video component receives and starts the live stream before requesting background playback. Before returning to H5, exit background mode as documented. Listen for double audio and inspect black frames, wrong back-stack behavior and lost member state. POLYV currently documents this WebView intermediary for live viewing; treat replay and on-demand video as separate integration cases.
04 / Use five pass criteria
Record entry success, continued video, normal audio, clean restoration and clean exit as separate outcomes. A report such as “audio continued but returning created two sound tracks” is actionable; “small window failed” is not. Capture device model, OS, WeChat and base-library versions, AppID, service category, player, channel state, trigger and recording. Publish only the scenarios that pass on the target iOS and Android devices.
An existing uni-app Mini Program can host POLYV’s native viewing component through wxcomponents and then test small-window playback against the active player instance. Apps and H5 use their respective endpoint routes from the developer center.
Frequently Asked Questions
Should a media URL be passed to requestBackgroundPlayback()? No. Bind the URL to the active native component before calling its Context method.
Can the WebView live intermediary be reused for replay? The current POLYV Mini Program WebView intermediary documentation covers live viewing. Evaluate replay through its relevant route.
Does a visible small-window button count as a pass? No. Confirm continued picture and sound, clean return and clean exit without duplicate playback.
Further Reading
Continue with What Should a WeChat Mini Program Livestream POC Test? A Script for Live, Replay, Chat, Products and Login and A WeChat Mini Program Livestream Launch Checklist: Shares, Product Routes, Analytics and Return Paths. For the overall integration choice, see the WeChat Mini Program SDK guide. The Chinese edition covers the same task for local teams.
About POLYV
POLYV’s background playback guide distinguishes native viewing pages from the WebView live intermediary. Validate the actual experience on target iOS and Android devices.