Skip to main content
The whiteboard itself is an H5 page; drawing and collaboration logic all run on the web side. You only need three steps: get the URL → load it in a WebView → handle the agreed interaction events.
This page covers only how to embed the whiteboard on Android. For how boards map to channels, when a whiteboard is destroyed, and how to sync the “who opened the whiteboard” state to others (SRTC doesn’t broadcast it automatically), see Whiteboard.

1. Where the whiteboard URL comes from

SRTC delivers the whiteboard URL when you successfully join a channel, through the whiteBoard parameter of the RTCClientEvent.onJoinSucceed callback:
Implement RTCClientEvent (or extend RTCClientSimpleEvent and override only the methods you need), and take the URL in the callback:
  • The URL looks like https://<api-domain>/white-board/?code=<session-credential>&device_type=2&.... Each person’s URL is different (code is each user’s own session credential—one-time use, invalid after connecting), but they all point to the same board (the board ID is the channel name)—so don’t forward your URL to others.
  • whiteBoard is normally not empty: the whiteboard is created automatically the first time someone enters, with no need to enable it in advance. If it’s empty, the line configuration is abnormal, and you shouldn’t open the page.

2. How to use it (load it in a WebView)

2.1 Required WebView configuration

2.2 Load the URL (append control parameters)

Append control parameters to the URL when loading:
Parameters are joined with &, relying on the URL already having a query string (the address from the joinChannel callback already includes ?code=...). Don’t add a second ?, or all the parameters after it are swallowed.
These parameters only set the initial state. To change them during the call (showing/hiding the toolbar, taking away or giving back the pen), call the JS methods in 3.4; changing the URL without reloading has no effect.

2.3 Inject the JS Bridge

The whiteboard communicates with native code through a JS interface with the fixed name AndroidInterface, which must be injected before loading:
JS Bridge implementation (reusable as is):

2.4 Release

Release the WebView when the screen is destroyed:

3. Interaction events and commands

There are four kinds of interaction: ① Native → whiteboard (URL parameters, initial values only), ② Whiteboard → native (JS Bridge), ③ Whiteboard calls into WebView system capabilities, and ④ Native → whiteboard (JS methods for dynamic control during the call).

3.1 Native → whiteboard: URL control parameters

Passed through the URL query when loading (see 2.2) to control the whiteboard UI:

3.2 Whiteboard → native: JS Bridge events

The interface object name is fixed as AndroidInterface; the whiteboard calls it as window.AndroidInterface.<method>(...). Reference implementation for saving the image in onExportImage:

3.3 Whiteboard calls into WebView system capabilities

Whiteboard features such as “Insert image” and “Upload image” trigger WebView system callbacks, which you need to handle in WebChromeClient:
Tip: the whiteboard has a size limit for images. We recommend compressing images before returning them (for example, to under 1 MB) to avoid upload failures with large images.

3.4 Native → whiteboard: dynamic control during the call

URL parameters take effect only when the page opens. To show/hide UI or take away/give back the pen during the call, use evaluateJavascript to call the methods the whiteboard attaches to window:
Hiding UI isn’t the same as disabling actions: setShowMenu / setShowToolUi only hide the interface; users can still draw with keyboard shortcuts and the context menu. To make “this person unable to draw”, you can only use setReadonly.
The page-following rule for multi-page whiteboards is “whoever can draw turns the page, and everyone else follows”; read-only clients only follow and don’t broadcast. See SRTC · Whiteboard · Multi-page whiteboards. You don’t need to designate anyone as host.