jitsi / jitsi-meet-sdk-samples

Jitsi Meet mobile SDK examples (Android, iOS and React Native)
Apache License 2.0
283 stars 240 forks source link

Some issues related to android #246

Closed akramraza2 closed 2 months ago

akramraza2 commented 3 months ago

After implementing jitsi sdk using JistiMeetView in my android app I have come across a few issue. Instead of raising separate requests I am going to list them here all together. If I am missing something I can be pointed in correct direction. First off I am using JitsiMeetView because I need to add some more UI in the frontend. And for now I am using jitsi's url , I have yet to host jitsi on my own.

  1. Name:- I am setting the username as follows:-
        val mBundle = Bundle()
        if (userName.isEmpty()) userName = MyPrefs(mContext).getUserName() ?: ""
        mBundle.putString("displayName", userName)

and also I am setting requireDisplayName to true as .setConfigOverride("requireDisplayName", true) .

But for some participants the name is not being set which results in the user being shown as Fellow Jitser. And due to this in the list of Participants Info , the name for this particular user is null which leads to crashes if null check is not done while retrieving user info.

So , first off why is it not setting user name even though I am setting it every time before joining ? Secondly, even if the name is not getting set why is retrieved info returning null ? Why not return Fellow Jitser itself for these participants ? If participants are being managed using their id then what's wrong with sending same name for those users ?

  1. No Audio :- Some times , the audio from the participants who starts the meeting is not audible to others participants in the meeting. This happens only with the one who starts the meeting. He can hear other's voices but his voice is not audible to others.

  2. Echo:- Some times, there's an echo being heard by participants. Which means along with other's voices they hear their own voice as well. The fix for this is nothing but the participants have to keep leaving and rejoining the meeting and hope that there is no echo.

  3. Screen Sharing:- Well for screen sharing the behavior is different on different devices. For android 14 at first the app crashes, my guess is it's related to FOREGROUND_MEDIA_PROJECTION service. And then late on nothing happens , the log says ERROR creating screen-sharing stream ', [gum.screensharing_user_canceled: User canceled screen sharing prompt] .

While for devices below 14 , it keeps saying the same thing every time. Here's the video for both cases, logs can be seen in the video.

Android 14:-

https://github.com/user-attachments/assets/b21e9b9f-ae4c-4780-a02a-ab65769e73aa

Android 12 :-

https://github.com/user-attachments/assets/c7fd9857-7550-4079-9dd6-9836602cacab

Now I know maybe I am missing somethings in my implementation. So, if that's the case please point me towards correct direction.

saghul commented 3 months ago

What SDK version are you using?

akramraza2 commented 3 months ago

I was on 10.0.0 but today I upgraded to 10.0.1 and the tested everything again and faced the same issues. The videos above are all on 10.0.1.

saghul commented 3 months ago
  1. Name:- I am setting the username as follows:-

Where is that bundle? Can you please share the code snippet where you set all conference options?

Secondly, even if the name is not getting set why is retrieved info returning null ? Why not return Fellow Jitser itself for these participants ? If participants are being managed using their id then what's wrong with sending same name for those users ?

That API returns what the user set. "Fellow Jitster" is an app default, you could configure your server to say "Guest" or whhatever.

2. No Audio :- Some times , the audio from the participants who starts the meeting is not audible to others participants in the meeting. This happens only with the one who starts the meeting. He can hear other's voices but his voice is not audible to others.

We have fixed one such bug and will be part of an upcoming SDK 10.1.

3. Echo:- Some times, there's an echo being heard by participants. Which means along with other's voices they hear their own voice as well. The fix for this is nothing but the participants have to keep leaving and rejoining the meeting and hope that there is no echo.

Echo is alas impossible to remove 100%. Are users in physical proximity? Are they using headphones?

4. Screen Sharing:

How are you integrating with our SDK using JitsiMeetActivity?

akramraza2 commented 3 months ago

Where is that bundle? Can you please share the code snippet where you set all conference options?

val mBundle = Bundle()
if (userName.isEmpty()) userName = MyPrefs(mContext).getUserName() ?: ""
mBundle.putString("displayName", userName)   // userName is set by me

setting this in conference options:-

 JitsiMeetConferenceOptions.Builder()
                .setRoom(channelName)
                .setAudioMuted(true)
                .setVideoMuted(true)
                .setAudioOnly(false)
                .setUserInfo(JitsiMeetUserInfo(mBundle))
                .build()

This is setting username correctly but it is not setting for some users.

That API returns what the user set. "Fellow Jitster" is an app default, you could configure your server to say "Guest" or whhatever.

Fellow Jitster is app default , but this app default is shown in participants list ui only. But it is not returned when we try to retrieve participants info using sendBroadcast(BroadcastIntentHelper.buildRetrieveParticipantsInfo("all_participants"))

instead of returning Fellow Jitster it returns null. Also, btw the participants lists returned is json but it is not a valid json. It is returned as follows:- Participants info: [{participantId=c3f9dae6, name=Akram, role=moderator, isLocal=true}, {participantId=224bcd3f, name=60CE2024, role=moderator, isLocal=false}, {participantId=7009e128, name=Test User, role=moderator, isLocal=false}]

Echo is alas impossible to remove 100%. Are users in physical proximity? Are they using headphones?

No they are not in physical proximity and yes they are using headphones.

How are you integrating with our SDK using JitsiMeetActivity?

No I am not using JitsiMeetActivity. I am using JitsiMeetView because I need to add more custom UI.

saghul commented 3 months ago

.setUserInfo(JitsiMeetUserInfo(mBundle))

Shouldn't you call this like so? .setUserInfo(new JitsiMeetUserInfo(mBundle))

Not sure why it would apply to some and not to others, did you observe a pattern?

Fellow Jitster is app default , but this app default is shown in participants list ui only. But it is not returned when we try to retrieve participants info using sendBroadcast(BroadcastIntentHelper.buildRetrieveParticipantsInfo("all_participants"))

instead of returning Fellow Jitster it returns null.

Yes, because this is a low level API, you get to choose what default name you want when you process it. They UI is not built on top of this API.

Also, btw the participants lists returned is json but it is not a valid json. It is returned as follows

Ops, would you like to send a PR with a fix?

No they are not in physical proximity and yes they are using headphones.

What SDK version are you using?

No I am not using JitsiMeetActivity. I am using JitsiMeetView because I need to add more custom UI.

Then it's hard for me to help you since I don't know if the view is corretly wired to the Acivity. Take a look at how the activity does it and give our activity a try to see if you can reproduce it.

akramraza2 commented 3 months ago

Shouldn't you call this like so? .setUserInfo(new JitsiMeetUserInfo(mBundle))

well I would if I was working with java but I am working with kotlin and in kotlin there is no new keyword.

Not sure why it would apply to some and not to others, did you observe a pattern?

I tried to but I failed. It's very weird. Because , if it is not setting for a user and if the user leaves the meeting and rejoins , it works fine.

Yes, because this is a low level API, you get to choose what default name you want when you process it. They UI is not built on top of this API.

The documentation should specify this behavior . Because all participants are managed using their id . So anyone would guess looking at the UI list that surely every participant has a name , might it be Fellow Jitster or his own name. This was so hard to catch because as per doc , setting username should work and since it doesn't work sometimes, it returns null in the list but shows Fellow Jitster in UI.

Also, btw the participants lists returned is json but it is not a valid json. It is returned as follows

This is also strange behaviour. Because during testing phase the returned list was valid json everytime. But after production crashes were reported indicating MalformedJsonException . So I ran tests immediately with a live meeting going on and found out this issue. Currently , I am manually fixing the returned list in my app.

What SDK version are you using?

10.0.1

Then it's hard for me to help you since I don't know if the view is corretly wired to the Acivity. Take a look at how the activity does it and give our activity a try to see if you can reproduce it.

Well , everything is wired correctly. But , I still didn't understand the reason behind this. Because, media projection screen comes up as expected because your sdk uses media projection to share screen. But , the issue starts after that. The log says screen capture was cancelled by user even though I allow it.

akramraza2 commented 3 months ago

Here's an update on echo. What is happening is if a user leaves the app without leaving the meeting and if they rejoin the meeting again. They receive audio on repeat. Which means the meeting does not kick him even though he disconnected the first time. And so in the meeting there are 2 participants for the same user and both receive the audio/video or whatever. And since the receiver is in reality just one person , he receives echo. Maybe there should be an auto kick out mechanism for users who leave the meeting activity without leaving the meeting.

Also, can you link me the latest android sdk ? I tried getting it from github but there are so many branches it's so confusing to know which is the latest one.

saghul commented 3 months ago

Here's an update on echo. What is happening is if a user leaves the app without leaving the meeting and if they rejoin the meeting again. They receive audio on repeat. Which means the meeting does not kick him even though he disconnected the first time. And so in the meeting there are 2 participants for the same user and both receive the audio/video or whatever. And since the receiver is in reality just one person , he receives echo. Maybe there should be an auto kick out mechanism for users who leave the meeting activity without leaving the meeting.

Aha. How are you leaving the meeting then?

Also, can you link me the latest android sdk ? I tried getting it from github but there are so many branches it's so confusing to know which is the latest one.

From the releases page: https://jitsi.github.io/handbook/docs/releases you can jump onto the release notes: https://github.com/jitsi/jitsi-meet-release-notes/blob/master/CHANGELOG-MOBILE-SDKS.md

akramraza2 commented 3 months ago

Aha. How are you leaving the meeting then?

The thing is sometimes when the app is sent to background in case for example user switches to another app , then PIP mode should come into play and meeting should continue in it preserving the activity state. But that's not the case PIP mode is not acting up , which pushes the app to background. Now even though in background the meeting is still in progress and user can talk/hear audio. But since the app is in background, android's system kills the activity. Which means when user returns to the app , he is actually out side the meeting screen , but still able to continue with the meeting. Now if he tries to join back again, in order to return to meeting screen the whole scenario related to echo as explained by me above is experienced.

Well, I do not understand why is only the meeting state getting preserved but not the whole activity state. Maybe because there is no actual disconnection happening. Anyways, to avoid such issue I tried setting the replaceParticipant flag, but still no benefit. After several test runs, still couldn't figure out the reason behind all this because activity's onDestroy should disconnect the meeting as well but it doesn't. Also I don't understand what's the use of replaceParticipant flag, it appears to be doing nothing.

saghul commented 2 months ago

There are a couple of problems here.

First, PiP should work automatically. Do you have any idea about why that is not the case?

Now even though in background the meeting is still in progress and user can talk/hear audio. But since the app is in background, android's system kills the activity.

That shouldn't be the case since we start a Foreground service.

I feel like your view integration in the activity is the problem here, since this is not reproducible when using JitsiMeetActivity.

akramraza2 commented 2 months ago

It is reproducible and no it's not related to my integration. Here's how you can reproduce it. Start/join any meeting an open chat window. Now switch to any other app or put this the app in background. PiP will not work and you will experience the above mentioned issue. Moreover, I have integrated JitsiMeetView exactly as mentioned in the doc overriding every lifecycle state.

saghul commented 2 months ago

Oh, I see PiP did not work indeed, we'll look into that.

The app continued to run in the background no problem, however.

akramraza2 commented 2 months ago

The app continued to run in the background no problem, however. Yes that's the issue the app and meeting keeps working until android system kills the app. Give it some time in the background and you will be able to experience the whole thing. Meeting will keep running , but when you try to return to the app you will have to rejoin the meeting, leading to duplicate user.

saghul commented 2 months ago

How long? I left it running around 30 minutes and audio was still flowing, could go back to the app no problem.

akramraza2 commented 2 months ago

Yes , audio is flowing even after android system kills the activity. So returning to the app leads to the whole problem because you are out of the meeting.

saghul commented 2 months ago

I have not experienced this. Do you have that option to kill background activities in developer options by any chance?

akramraza2 commented 2 months ago

No, I have tested this in emulator , and real devices as well without having developer options turned on at all. It has nothing to do with developer options. This is default behavior of android system to kill background processes. Moreover, in a real world application , you cannot tell your users individually to check developer options. And this issue was reported to me by my users. When I investigated further , I found this behavior. Watch , I had to trim the video , but it took around 2 minutes for this.

https://github.com/user-attachments/assets/97cdb84b-bf73-42ee-9400-8abbdb2ee670

saghul commented 2 months ago

Android won't kill your background process if you have the "right" to continue running.

I cannot reproduce what you are experiencing.

Are you able to reproduce it with our sample app which uses the SDK and the Activity API?

akramraza2 commented 2 months ago

Android won't kill your background process if you have the "right" to continue running.

After looking at behind the scenes of how a meeting is running, you would expect this behavior. Since it is running as a foreground service, this should be true and it should not be killed. But sadly it being as you can see in the video above. The video is using official jitsi meet app and not my app. And no I have not yet tested sample app , so I will share an update once I test it.

saghul commented 2 months ago

What version of the app did you test?

akramraza2 commented 2 months ago

24.4.0

saghul commented 2 months ago

24.4.2 is rolling out with some relevant fixes. You can opt-in to the beta if you want to test them early.

akramraza2 commented 2 months ago

Okay , I signed up as beta tester. Also, what about the SDK ? Clearly if this issue is happening with official jitsi meet app then it's not related to my app specifically. It's related to SDK, so the SDK should be fixed.

saghul commented 2 months ago

What build did you get and could you reproduce the problem with it?

akramraza2 commented 2 months ago

Well , I already explained how this issue can be reproduced. Btw, even in beta the official app has 24.4.0. If 24.4.2 has this issue fixed then I have not tested it yet because it's not available yet. Also, I am using the v10.0.1 for the SDK . I just now saw there's a new version out v10.1.0 , so I will test that.

also, out of curiosity, when is participants info getting to be fixed ?

saghul commented 2 months ago

I was testing 24.4.2 yesterday, which matches SDK 10.1.

also, out of curiosity, when is participants info getting to be fixed ?

What participants info? (please let's keep the issue on topic)

akramraza2 commented 2 months ago

Well I am on track. If you check all the issues I have posted here, participants info is also one of them where the returned json is not correctly formatted. And I have upgraded to 10.1.0 and will test if the issue still persists or not.

akramraza2 commented 2 months ago

Okay, tested v10.1.0 , it's fixed in it. PiP is working even with chat opened and the activity is not getting killed.

saghul commented 2 months ago

Great to hear! Sorry for the back and forth.

participants info is also one of them where the returned json is not correctly formatted

Ah, I remember now. A PR would be welcome, this is not an API we use and doesn't get much attention alas.

akramraza2 commented 2 months ago

Okay, once I am done with my project I will create a PR for it.

Also on another note. Now since everything else is fixed as listed in my comment above, I guess only screen sharing issue remains. My guess is it's related to React Native. I am not sure of it yet , but soon I will provide a report on it also.

saghul commented 2 months ago

👍 I'm going to close this one then. Please open a new issue with as many details as possible. I haven't been able to reproduce any screen-sharing problems with the latest version...

Cheers!