Skip to contentSkip to navigationSkip to topbar
Rate this page:
On this page

Migrating from 4.x to 5.x



This documentation is for reference only. We are no longer onboarding new customers to Programmable Video. Existing customers can continue to use the product until December 5, 2026(link takes you to an external page).

We recommend migrating your application to the API provided by our preferred video partner, Zoom. We've prepared this migration guide(link takes you to an external page) to assist you in minimizing any service disruption.

This guide provides an introduction to the 5.x Programmable Video Android SDK and a set of guidelines to migrate an application from 4.x to 5.x

Programming Model

programming-model page anchor

The programming model has not changed from 4.x to 5.x. Refer to our 2.x migration guide for a refresher on the Video Android SDK models.

The SDK uses a new WebSocket based signaling transport, and communicates with globally available signaling Servers over IPv4 and IPv6 networks. The ConnectOptions.region property has been added which allows you to specify the region of the signaling server. By default, the Client will connect to the nearest signaling Server determined by latency based routing. Setting a value other than "gll" bypasses routing and guarantees that signaling traffic will be terminated in the region that you prefer.

ConnectOptions connectOptions =
new ConnectOptions.Builder("token").
Room room = Video.connect(context, connectOptions, roomListener)

If you were previously whitelisting signaling servers by IP address you will now need to whitelist the FQDN for the region that you are connecting to. See the Signaling Communication section of the IP Address Whitelisting guide for more information.

With this new WebSocket based signaling transport, some modifications may need to be made to the Access Tokens that you generate. Specifically:

  • Ensure that the AccessToken does not contain a configuration profile sid. Configuration profiles were previously deprecated and are no longer supported.
  • Set the Time-To-Live (TTL) of your AccessToken to the maximum allowed session duration, currently 14400 seconds (4 hours). This ensures that when a network loss occurs the client will be able to re-authenticate the reconnection. Note, a reconnection attempt with an expired AccessToken will result in an AccessTokenExpiredError .

Rate this page: