Fix video capturer null handling and reset localVideoTrack on teardown

[DivyanshuChipa]

Motivation

• Prevent crashes and broken video after the first call by handling cases where createVideoCapturer() returns null and by ensuring the local video track is rebuilt between calls.
• Avoid publishing a disposed or null localVideoTrack to the PeerConnection, which can cause subsequent calls to fail.

Description

• Guarded startLocalVideo() against a null capturer by checking createVideoCapturer() and logging a warning while falling back to audio-only mode when no capturer is available, avoiding !! force-unwraps (file: app/src/main/java/com/example/intra/WebRTCClient.kt).
• Switched video publication to only add localVideoTrack to the peer connection when the track is actually non-null, with a log warning when unavailable.
• During endCall() teardown, dispose and null localVideoTrack so subsequent calls recreate a fresh capture pipeline instead of reusing a disposed track.

Testing

• Attempted to compile the app Kotlin sources with ./gradlew :app:compileDebugKotlin, which ran but the build could not complete in this environment due to a missing Android SDK/platform dependency (25.0.1).

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 542406b4da

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Propagate video fallback to negotiation metadata

When createVideoCapturer() fails, startLocalVideo() flips the field isVideoCall to false, but startCall()/answerCall() still build SDP constraints and signaling JSON from their isVideoCall parameter (the original requested mode). In the no-camera path, this means the app logs an audio-only fallback locally yet still advertises a video call remotely, which can leave the peer/UI in a mismatched call mode and expect video that will never be published.

Useful? React with 👍 / 👎.