Screen sharing issues


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_Chen,

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_Chen.
Can you please point out the fixes to the demo that would now avoid the issues that we had discussed on this thread?

Hi grey-bit,

Thanks for the reply. Actually the issue has been handled internally in our SDK so the issue you have mentioned in this thread will not longer exist and you do not need to do any extra implementation. I tried to follow the steps you have mentioned above to reproduce this issue with our latest demo app(Under custom UI mode), and this issue no longer appears.

Let me know if you have any questions. Thanks!

Indeed - it’s all fixed now!

1 Like

Glad to hear that it is fixed! Let me know if any other questions. Happy Zooming! :smiley:

1 Like