Event to detect when consent to record confirmed / denied?

Thanks @jon.zoom Do you have a link to some documentation describing how I can turn off the default recording consent dialog and use my own with custom UI? (Or do something similar if nothing so specific exists) Thanks

Hi @a.diament,

The recording consent dialog must be shown for privacy reasons, as it lets a user know that people not present in the current meeting may be able to view/hear their video/audio. As a result, we cannot offer a method through which this can be hidden.

If you were to implement a custom meeting UI from scratch, you could have significantly more control over this dialog. There are a couple of caveats to taking that approach. The two biggest considerations are:

  1. Implementing an entire meeting UI from scratch is a non-trivial amount of work.
  2. It is necessary to implement various legal notices in your custom UI implementation, including when a recording begins.

Thanks!

@jon.zoom further to the above, I have now implemented a custom meeting UI from scratch in Android. However the stock zoom legal notice about recording still displays automatically, and I am not clear how I can disable the automatic prompt and display my own from the documentation. Please could you point me in the right direction or provide some sample implementation code? I see from the link you posted to me that the InMeetingChatController (Zoom.us SDK API Document) class has methods to get the legal notice - but nothing about how to show a custom one / stop the automatic one showing. Also, the text that these methods returns is different to that from the consent to record screenshot that I posted, so I have a suspicion they don’t relate to the same thing. Thanks for your help.

Hi @a.diament,

The notice should not display when custom UI mode is enabled. Can you please try updating to the latest version of the SDK? There have been some versions in which a bug would cause this to incorrectly show when using a custom UI.

Also, the text that these methods returns is different to that from the consent to record screenshot that I posted, so I have a suspicion they don’t relate to the same thing. Thanks for your help.

What is the message you are seeing?

Thanks!

Hi Jon. I am already on the latest Android SDK, the one released this week.v5.7.6.1918

getChatLegalNoticesExplained returns:

Recording is on, so the account owner and everyone in the meeting can see and save messages sent to Everyone — and can share them with apps and others.

Only you and those you chat with can save your direct messages and share them with apps and others.

getChatLegalNoticesPrompt returns

Who can see your messages? Recording On

In contrast the consent to record message that pops up by itself reads:

This meeting is being recorded. By staying in this meeting, you consent to being recorded. The account owner and host can watch zoom cloud recordings and any participant with permission can record to their local device. These individuals can share these recordings with apps and others.

For reference, this is how I am initializing the sdk and setting custom meeting ui enabled:

val sdk = ZoomSDK.getInstance()

  suspendCoroutine { cont: Continuation<ZoomSDK> ->

                if (sdk.isInitialized){
                    return@suspendCoroutine
                }

                val zoomParams =  ZoomSDKInitParams()
                zoomParams.appSecret = appSecret
                zoomParams.appKey = appKey
                zoomParams.enableLog = true

                sdk.initialize(context,
                    object : ZoomSDKInitializeListener {
                    override fun onZoomSDKInitializeResult(
                        errorCode: Int,
                        internalErrorCode: Int
                    ) {
                        when (errorCode) {
                            ZoomError.ZOOM_ERROR_SUCCESS -> {
                                sdk.meetingSettingsHelper.isCustomizedMeetingUIEnabled = true
                                cont.resume(sdk)
                            }
...

I also tried doing it identically matching the documentation with

sdk.getMeetingSettingsHelper().setCustomizedMeetingUIEnabled(true)

  • it is equivalent in compilation terms, and I see the same behaviour.

Hi @a.diament,

We’ll need to investigate the recording notification showing up with custom UI enabled. It is possible that the requirements around this have changed recently. I will keep you updated as soon as we have any new information on that front.

Regarding the difference in wording you are seeing: the scenario present in your screenshot is not the same notice outlined in our legal notices documentation. It does seem odd that we do not have a notice for the recording dialog, but perhaps that is related to the possible change in requirements noted earlier. Let’s hold off on looking further into that while I get more information on the first point.

Thanks!

1 Like

@jon.zoom I’m just wondering if there is any update on the expected behaviour around the consent to record dialog in custom ui?

The dialog to consent to recording has now stopped appearing automatically in my custom ui implementation - zoom sdk. Consequently I cannot turn on or off the video or audio any more.
If when I create the meeting with the zoom api, I set auto_recording to “none” instead of “cloud” video and audio work as normal. Reference question Toggling A/v throws SDKERR_NO_PERMISSION - #13 by jon.lieblich

@jon.zoom I have tested a lot today and I have some more information on how to replicate making the consent to record dialog appear/not appear, which hopefully will be useful for you devs. I think there are some race conditions happening, around when exactly the zMACtivity is started compared to the status of the zoom meeting.

sdk v v5.7.6.1918.
Custom UI is enabled.

  1. What works for me, is if I start my ZMActivity when the meeting status is “connecting” then I do see the consent to record dialog. If I wait to start the ZM activity until after my meeting status is “In Meeting” then I almost never see the consent dialog, and can never start the video/audio.
  2. In the “on create” override of the ZMActivity, I inflate the MobileRTCVideoView and get the reference to the MobileRTCVideoViewManager as described in the documents. All this time the meeting status is still “Connecting”. Crucially, at this point I do not call any “AddVideoUnit” methods, e.g AddAttendeeVideoUnit. If I do, the method will return false/failure.
  3. So, in order to start video etc I need to wait until the consent to record has been clicked. But there is no way to know when it has! My workaround is going to be adding a button to the zmactivity ui to add the attendee video unit, and start video - and make it so that the button doesn’t enable for several seconds, to try to stop them clicking it before they have consented to record. But it is quite hacky. And if they choose “no I don’t consent” I have no hook to keep the button disabled.

In conclusion - I think my previous request for zoom to to add a hook to the sdk to know when the “request to record” has been granted, is actually quite important, rather than a “niche” request. As evidenced by the other users experiencing similar problems in the Toggling A/v throws SDKERR_NO_PERMISSION - #16 by a.diament ticket.

I too have found some consistency with the consent dialog appearing or not appearing. When the recording starts, if there is a MobileRTCVideoView on screen, the dialog appears. If I navigate to another screen that is free of MobileRTCVideoViews, the consent dialog does not appear.

Unfortunately, I still can’t reproduce the issue where audio/video can’t be controlled if the dialog does not appear. I’m still working on that.

Hi @a.diament,

Apologies for missing this post regarding the expected behavior for the recording consent dialog as there were multiple posts on the topic. The dialog definitely should appear when using a custom meeting UI. It seems that there is an issue with the consent dialog not displaying properly, which we will need to investigate further.

Regarding the race condition around rendering user video, I think this may be an order of operations issue. In the SDK sample app, I am seeing successful video subscriptions while the consent dialog is still present. Are you solely relying on the meeting status changing as the indicator that you should start setting up the video units? If not, please let me know exactly when you are starting to call MobileRTCVideoViewManager#addVideoUnit so we can figure out where the discrepancy is between your implementation and the sample app.

Thanks!

Hi @vuzix_greg,

Thanks for the additional information as we continue to look into this. Your findings are consistent with what I’ve seen surrounding the consent dialog not showing. I’ll keep you updated with any new information.

Thanks!

1 Like

Thanks Jon. I will send you this information when I am back to work next week. Could you please send me the link to the sample app code which uses custom ui. I can only see the one for default UI. Cheers!

Adam

@a.diament

The same sample app (mobilertc-android-studio/sample) has both default and custom UI. But you have to go into settings and turn on the switch for custom UI. Then join a meeting and it will use a custom UI instead of the default.

Hi @a.diament,

As @vuzix_greg pointed out, the custom UI in the sample app can be toggled in the settings. The sample app is included in the SDK download from the Marketplace.

Thanks!

Hi @a.diament,

I just wanted to provide an update regarding the initial feature request. When a user consents to recording, you should see the onUserVideoStatusChanged callback invoked. Let me know if you are seeing any issues with this and we can investigate further.

Thanks!

Thanks @jon.zoom, indeed it does trigger that event. I get a “video on” event when the consent is clicked. I can certainly use this to turn on the camera, and it’s better than I had before, so thanks!

I will say it is not ideal. The event is triggered multiple times, and the parameter only tells me if the user’s video is on or off or muted by host, rather than anything specific about the user having clicked “I consent”.
Additionally, although the event is called “onUserVideoStatusChanged” I receive several events in a row with the same status triggered.

So, in order to use the event to trigger switching on the camera etc. I need to make the assumption that the first time I receive a “video on” parameter from onUserVideoStatusChanged for a particular call, it will have been caused by the user clicking the consent “GOT IT”.

Assuming I can make that assumption (?) then I can use this, but I would still prefer a specific event along the lines of “userConsentToRecordChanged” with some kind of RecordingConsentStatus granted/denied flag.

Thanks again for the update.

Adam

Hi @a.diament,

I’m glad we’re at least headed in the right direction!

I totally hear you on this not being ideal. With the current implementation, it would require some state management in your app, which obviously can increase the risk of bugs. We can consider adding a distinct callback for this in the future, but to be completely transparent, it may not get prioritized as long as there is a workaround available. Let me know if there are any significant issues with this workaround and we can try to bump up the priority of this. :slightly_smiling_face:

Thanks!

1 Like

Using it with the state management I have described seems pretty solid so far. Basically I assume the first “video on” event for a particular call really means “consent granted”. So far so good. I will post here again if I find any bugs.

Cheers!

Adam

Hi @a.diament,

That’s great to hear that managing the state locally is working! I’ll be happy to help if there are any issues with using this approach.

I was able to follow up internally on this and discovered that we would not be able to implement a change to prevent this callback from being triggered multiple times. This originates from the back end service, and was initially implemented to overcome some edge cases with the Zoom client. So basically, preventing duplicate events from being sent could break the Zoom client.

Thanks!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.