MeetingService.handZoomWebUrl() crashes when using personal links

Meeting SDK Android
1

Discovered in Android SDK v5.2.41727.0928 but verified still exists in v5.2.42043.1112.

If you call MeetingService.handZoomWebUrl() with a URL containing a meeting ID, everything works fine. However if you call the same method with a URL containing a personal link (user id instead of meeting id), the app will crash with the following stack trace:

android.content.ActivityNotFoundException: Unable to find explicit activity class {com.vuzix.hud.zoom/com.zipow.videobox.IMActivity}; have you declared this activity in your AndroidManifest.xml?
    at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:2012)
    at android.app.Instrumentation.execStartActivity(Instrumentation.java:1675)
    at android.app.ContextImpl.startActivity(ContextImpl.java:917)
    at android.app.ContextImpl.startActivity(ContextImpl.java:888)
    at android.content.ContextWrapper.startActivity(ContextWrapper.java:379)
    at android.content.ContextWrapper.startActivity(ContextWrapper.java:379)
    at com.zipow.videobox.util.a.a(ActivityStartHelper.java:48)
    at com.zipow.videobox.IMActivity.d(IMActivity.java:289)
    at com.zipow.videobox.ptapp.PTUI.sinkIPCWebJoinNoConfNoImpl(PTUI.java:1943)
    at com.zipow.videobox.ptapp.PTUI.sinkIPCWebJoinNoConfNo(PTUI.java:1920)
    at com.zipow.videobox.ptapp.PTApp.handleZoomWebUrlImpl(Native Method)
    at com.zipow.videobox.ptapp.PTApp.handleZoomWebUrl(PTApp.java:1950)
    at us.zoom.sdk.z.handZoomWebUrl(MeetingServiceImpl.java:1033)

I am using a custom UI, so I don’t believe the SDK should not be attempting to launch an activity.

2

Hi @vuzix_greg, thanks for the post.

If you are using a custom UI, the handZoomWebUrl route is not compatible. If you need to handle starting a meeting from a URL, we recommend parsing the data you require from the URL and passing it into the corresponding params object. For more information see our documentation on joining/starting a meeting.

Thanks!

3

Thanks for the response @jon.zoom. We can start parsing the vanity ID out of the URL and pass it to JoinMeetingParams.vanityID if that is the only option.

My only concern is being able to handle and parse all the various Zoom URL formats. That’s why handZoomWebUrl() was so useful, it did all the work for you, including detecting the encrypted password if it was present or not. And that method has always worked before with a custom UI and just passing in a URL with a meeting ID.

I disabled my custom UI and still got the same ActivityNotFoundException. I was able to avoid this exception by adding:

    <activity
        android:name="com.zipow.videobox.IMActivity"
        android:configChanges="orientation|screenSize"
        android:theme="@style/ZMTheme.SubWindow" />

to my manifest file. But then I got a NoClassDefFoundError for org/greenrobot/eventbus/EventBus.

I solved this by adding:

implementation 'org.greenrobot:eventbus:3.0.0'

to my build.gradle file. Got another ActivityNotFoundException for com.zipow.videobox.JoinConfActivity which I also fixed by adding this activity to my manifest. I’ve got past all the crashes, but now when I pass a URL with a vanity ID to handZoomWebUrl(), it simply displays a “Join a Meeting” screen where I’m being prompted to enter a meeting ID or personal link name.

So it would seem like handZoomWebUrl() was never updated to support vanity IDs, with or without a custom UI, and it’s simply falling back to showing a UI where the user must enter this info.

I think we’ll start migrating away from handZoomWebUrl() and we’ll parse Zoom URLs ourselves even though I am still nervous about all the formats we have to support. Hopefully these remain constant for the foreseeable future?

*.zoom.us/j/{meeting-id}
*.zoom.us/my/{vanity-id}

and each can have an optional pwd=XXXX parameter at the end? Does that cover some general parsing rules we would have to handle?

Thanks!

4

Hi @vuzix_greg,

We can start parsing the vanity ID out of the URL and pass it to JoinMeetingParams.vanityID if that is the only option.

This may not be the only option, but it is the only option that we would recommend using at this time. Since we have publicly deprecated using client URLs directly, we will need to discuss what that means for the handZoomWebUrl method internally and get back to you.

I think we’ll start migrating away from handZoomWebUrl() and we’ll parse Zoom URLs ourselves even though I am still nervous about all the formats we have to support. Hopefully these remain constant for the foreseeable future?

If you have no other way of getting the required meeting info, I would recommend using this approach. The risk of the format of URLs changing is lower since a breaking change here would impact the Zoom client directly, and not just the SDKs.

Thanks!

1 Like