Chrome发起屏幕共享时Android端WebRTC远程音视频流冻结问题求助

I’ve run into similar cross-platform WebRTC screen share issues before, so let’s break down what might be going wrong and how to fix it:

• Double-check your track replacement workflow
  When Chrome initiates screen share, make sure you’re replacing the existing video track instead of spinning up a new PeerConnection or adding an entirely new stream. Android’s WebRTC SDK can be finicky about how track updates are handled.
  On Chrome’s side, locate the existing video sender via peerConnection.getSenders(), call replaceTrack() with the screen share track, then trigger re-negotiation (createOffer → setLocalDescription → send over your signaling layer). Avoid adding a new stream from scratch—this often causes Android to miss the track update entirely.

• Validate SDP handling for screen share
  Screen share SDP has subtle differences from camera stream SDP (like unique msid, ssrc values, and framerate constraints). Print out the Offer SDP from Chrome and Answer SDP from Android when screen share starts, then compare them to your normal call SDP.
  Look for missing attributes like a=rtcp-mux or incorrect media type declarations. Sometimes Android’s SDK fails to properly acknowledge screen share-specific SDP parameters, which breaks media flow even if ICE stays connected.

• Ensure Ice candidates are exchanged during re-negotiation
  Even if IceConnectionState shows "connected", re-negotiation for screen share might generate new Ice candidates that aren’t being passed correctly via your signaling layer.
  Make sure both sides are sending onIceCandidate events immediately and calling addIceCandidate on the remote end. You can also try calling peerConnection.restartIce() before initiating screen share to force a fresh Ice gather—this sometimes resolves hidden connectivity glitches.

• Debug Android’s track reception and rendering
  Check if Android’s ontrack event fires when Chrome switches to screen share. If it doesn’t, your signaling or track replacement logic is off. If it does fire, verify that the new track is properly attached to your SurfaceViewRenderer/TextureViewRenderer—don’t forget to call initialization methods like init or setMirror if needed.
  For audio: Even though Chrome receives Android’s audio fine, confirm that Android is receiving Chrome’s audio track correctly. Check if the audio track is marked as active, and make sure your audio renderer isn’t accidentally paused or muted during re-negotiation.

• Dig into WebRTC logs
  Enable verbose logging on Android with Logging.enableLogToDebugOutput(Logging.Severity.LS_VERBOSE) and watch for errors like "Failed to set remote description" or "Track ended". On Chrome, use chrome://webrtc-internals/ to check media stats—look for zero incoming packets for Chrome’s video/audio once screen share starts. If packets aren’t arriving, it’s an ICE/SDP issue; if they are, it’s a rendering problem.

• Tweak screen share constraints
  Try dialing back Chrome’s screen share constraints (e.g., lower resolution to 1280x720, frame rate to 15fps). Sometimes high-resolution screen share streams overwhelm Android’s WebRTC stack, causing it to freeze even if ICE stays connected.

内容的提问来源于stack exchange，提问作者Tanay Mondal