Screen sharing issues

I am running the latest version of Android Zoom SDK.

When my app shares the screen, if I use another computer to forcefully stop the app screen sharing, the app receives the notification properly, but overlay buttons (stop sharing/annotate) remain on the screen. I have to push “stop sharing” button to get it away.

In the similar scenario, when the other user doesn’t merely stops app screen sharing, but kicks the app out of the meeting, the situation is actually worse. Overlay buttons also remain on the screen. If I remove the buttons, by pushing the “stop sharing”, the app wouldn’t be able to share the screen anymore. When I attempt sharing the screen again, the app would share black screen into the meeting and the overlay buttons don’t show up.

I tried calling InMeetingShareController.stopShareScreen() and InMeetingShareController.stopShareView() when I receive notifications about disconnection, but it didn’t help.

Should I do any other deinitialization when sharing is stopped or I am kicked out of the meeting?

Please advise on whether those are known issues and whether there is any workaround.

Hi grey-bit,

Thanks for the post. I tried the scenario you are describing with our demo app, here are my observation:

  1. The default Zoom UI works fine
  2. When testing with Custom UI, if I joined a meeting and started sharing, then the host(on the desktop client) force to stop the sharing, the toolbar stays on the screen. And on the host side, the shared screen is not shown.
  3. When pressing the “Stop sharing” button, the toolbar disappears. When I go back to the meeting, and start sharing again, I am able to start sharing the screen again.

I will double check this behavior with our engineering team. In the meantime, since my attempt to reproduce the issue you are describing with our demo was not fully successful, would you mind providing more information on this issue?

Which SDK version are you using? Are you able to reproduce this issue with our demo app? Are you getting any errors or do you have any logs?


Thanks for the response.
I am running v4.4.55130.0712.
I will retest #3 tomorrow, including with the demo app and will report back with any findings.


Thanks for the reply. The behavior that I observed is an issue with our demo app, and it will be fixed in the demo app of the next release. Please let us know if you have any additional info regarding the unexpected behavior that you have mentioned but I was not able to reproduced. If the behavior is reproducible and happening in our SDK, we will identify it and fix it asap.

Hope this helps. Thanks!

Thanks for the check.
When would you estimate the next version of the SDK to be released alongside the fixed demo? Would you be able to share the pointer to the exact part of the fixed code on this thread?

Regarding the second issue.
I verified using the demo app and it doesn’t manifest the behavior.
When host kicks the app out of the meeting, the app stops sharing and is able to share again.

Checking further, I found my bug that prevented the app from sharing again.

However, I am still struggling with the toolbar buttons not going away even though the app is fully disconnected from the meeting (verified on the host).
Just like in the demo app, I am trying to stopShareScreen() in onMeetingLeaveComplete(). First checking isSharingScreen(). The problem is that SDK thinks that the sharing session is already off - isSharingScreen() returns false and even if I still perform stopShareScreen() it doesn’t have any effect.

One interesting data point:
Before I receive onMeetingStatusChanged, there are debug outputs in the log:
1566980214.248 29609-29609 D: stop() called with 704160 frames delivered
1566980214.426 29609-29609 D: CHONG CAnnoTimerAndroid::~CAnnoTimerAndroid _interval:30---------------------------------
1566980214.426 29609-29609 D: CHONG CAnnoTimerAndroid::~CAnnoTimerAndroid _interval:50---------------------------------
1566980214.426 29609-29609 D: CHONG CAnnoTimerAndroid::~CAnnoTimerAndroid _interval:30---------------------------------
1566980214.426 29609-29609 D: CHONG CAnnoTimerAndroid::~CAnnoTimerAndroid _interval:30---------------------------------
1566980214.465 29609-29609 D: onMeetingEvent, meetingEvent=MEETING_STATUS_DISCONNECTING, errorCode=0, internalErrorCode=0

First line seems to suggest that sharing is stopped, which would be consistent with isShareScreen() returning false… But the overlay buttons are still present on the screen.

Would you have some ideas on how my code could potentially lead to this state of the SDK? The demo app doesn’t exhibit such a behavior.


Hi gery-bit,

Thanks for the reply. The next release with the fixed demo will come out really soon(Early Sep). I wish I could send you the code of the fix but I don’t have the new code in hand yet.

Glad to hear that the stop sharing issue has been resolved and thanks for sharing the findings. I will need to consult the engineers on this interesting behavior and get back to you with updates. I will also try to get the new code regarding this part as well.


1 Like

I have upgraded to the latest SDK that was published today, but it still behaves the same:
If I kill my app locally, then screen sharing continues + if the app is kicked out of the meeting by the host, the overlay buttons remain on the screen.

I guess, I should also make the changes that you referenced in the previous messages. Can you please point me to the demo app changes in the latest SDK?

Hi grey-bit,

Thanks for the reply. You can implement the onShareActiveUser callback( to handle the case that the screen is not stopping when the host forces the sharer to stop sharing. You can refer to the following code snippet:

        public void onShareActiveUser(long userId) {

            // If the user is forced to stop sharing by the host, stop the screen sharing
            if (userId != ZoomSDK.getInstance().getInMeetingService().getMyUserID()) {

            for (ShareEvent event : callbacks) {

For another scenario you have mentioned, if you uses the Recent App to close the SDK app while sharing, you can implement the onDestory() method and stop sharing in this method.

Hope this helps! Thanks!

Thanks for the reply and sorry for my late response - I was dealing with other issues.

The problem with the overlay button remaining after the app is fully closed is gone.
I haven’t had to make any modifications, so I assume that latest SDK performs the necessary cleanup.

Regarding the other issue: my app sharing the screen and host either “stops sharing” or “removes the app from the meeting”.

Her the progress is very limited - I could make the overlay buttons go away when in the “stop sharing” case (but not in the “removes from the mtg”), but in both cases, I am not able to share again into the meeting, unless the app is fully restarted.

I have verified this behavior with the sample apps (pulled on Sep. 4th) and here are the results:
“example2”: behaves very well in both cases. Overlay buttons disappear and resharing is possible.
“sample”: If I am using standard UI, then everything works well. If Custom UI is used, then same behavior is experienced - overlay buttons remain on the screen after the host stops app sharing or when host removes app from the meeting + if app tries to share again, host will see " is sharing the screen" message, but no actual sharing happens.

Seems like there is still something missing in the “sample” logic. Something that is implemented correctly in the standard UI. Hopefully, the reproduction steps would help you to get the right fix from the dev team.

thanks and have a great day!

The problem is actually more acute:
even if I stop sharing the screen using the overlay “stop” button (not by kicking the app out by the host), the app can’t share the screen into the meeting again.

Verified using “sample” app in the custom UI mode.

This seems to be new behavior of the latest SDK - previously, I could restart sharing after stopping it through the overlay button.

Hi grey-bit,

Thanks for the reply and thanks for the detailed information. Could you share some info on how do you perform the case “removes the app from the meeting”?


On Mac Zoom client, I go to the “manage participants”, click “more” button to the right of the app user and click “remove”.

Hi grey-bit,

Thanks for the reply. We will look into this issue based on the detail you provided. Will get back to you asap.


1 Like

Hi @carson.zoom,

Any news on this one?


Hi grey-bit,

Thanks for the reply. We have looked into this issue and it is a little bit complicated to fix in the demo. Hence we will introduce a fix for this issue and add an SDK method for this situation. The fix will be included in the next release, which is coming soon. Once that version is available, I will show you how to fix it easily.


Thanks Carson!

Yes please do @grey-bit!


@Tommy, would you have some rough schedule for the next SDK release?

Hi grey-bit,

Thanks for the post. We are expecting a release very soon, please follow our Github repo for the latest update.


1 Like

Hi grey-bit,

Our new Client SDK release is now available. You may find the latest Android SDK here:


Thanks @carson.zoom.
Can you please point out the fixes to the demo that would now avoid the issues that we had discussed on this thread?