I started using android app and after using various alternatives I find it very inconvenient that screen is timing out during the call. All the alternates keep screen on which allows easy access to mute / unmute. Having to turn on device screen before unmuting is very inconvenient.
Possibly relevant app setting https://developer.android.com/training/scheduling/wakelock#screen
We do keep the screen on when using video. Are you in an audio only call perhaps?
Yes, sometimes to save bandwidth I only use audio. Wouldn’t it be possible to have a setting that allows disabling screen timeout in audio only call? This way it would be easier to access unmute/mute button.
Sorry, we don’t think that use-case warrants a setting, it’s kind of an edge case.
@saghul We are developing the CarPlay addition to our Jitsi wrapped iOS meetings client. What we are noticing is that when the device screen locks (goes to sleep) the Jitsi network stops. Any ideas how we can keep the Jitsi network flowing when connected to CarPlay? The OS is not shutting down our network as I can see via my Charles Proxy that our network calls continue.
Hey there. I’ve never tinkered with CarPlay… do you have access to any logs? Are you using our SDK or did you make any changes? AFAICT the app does remain in the background properly. Isn’t CarPlay a tiny addon like WatchOS companion apps?
Not sure how I would get any logs…we are using your 3.10.2 SDK with a few minor changes, but nothing on the network side of things. Yes, CarPlay is really just another window, however, it’s limited to the CarPlay framework as far as views are concerned. You can’t show any video and it has limited text ability. I can see the Jitsi logs happening in the Xcode console, is there something I can look for?
Not sure what I’m looking for either Just share all the logs around the time the connection is lost please.
Here are the logs that I could find within the Xcode console.
JitsiLogs.txt (38.2 KB)
I see you are using XMPP WebSockets. We haven’t enabled them by default on mobile yet, for instance, there are bugs detecting disconnections, I wonder if switching to BOSH will helpo you here.
No, we’ve tried it both ways. We only enabled WebSockets when we updated to the 3.10.2 SDK.
Did you set all the background modes in your app? (audio and voip)
Yes, all background modes are set: Audio, AirPlay, PiP, VOIP
One thought I’m having is the thought about the CarPlay view taking over as the main view. That’s what made me find this thread (Android screen going dark). Is there some setting that will prevent the current main window from going dim during a meeting?
Hi @saghul, I’ve been working with @JCaudill on this and we have tried on a server where websockets is not enabled. I have the iPhone running through fiddler so I can see the http-bind traffic and the same sort of thing happens but only when connected to CarPlay. The scenario is as follows:
I join a meeting, as long as I stay in the foreground all is good, screen stays bright and traffic flows. If I put the app in the background I will see the screen dim after 30 seconds (I have the Auto-Lock set to 30 in the device settings). Then the iPhone will lock but audio and http-bind traffic still flows just fine and will continue to flow.
Now if I run the same scenario when connected to CarPlay what I see is when the app is backgrounded and the device locks the http-bind traffic stops flowing and the participant on the iPhone will eventually get dropped from the meeting. Note that we are not using CallKit here, we are simply building a custom scene for CarPlay so we can have a custom CarPlay UI. This all works great as long as the phone doesn’t lock.
I did try a similar test using the Jitsi Meet app and noticed some differences that actually may help us out here. When I join a meeting with JitsiMeet with the app in the foreground I see the screen dim but it never locks. Even if I put JitsiMeet in the background, I see the screen dim after 30 seconds but it never locks. If we could pull off the same behavior, I think it might help.
I’m a bit confused since Android and iOS were both mentioned here I’m assuming we are talking about iOS.
So, if you develop your own CarPlay scene, that means you are no longer using CallKit? Is there a reason not to? CallKit is instrumental in keeping the app running in the background.
As for keeping the screen on, here is what we do while in a meeting: react-native-keep-awake/KCKeepAwake.m at master · corbt/react-native-keep-awake · GitHub
Hope that helps!
Callkiit seems a bit limited with what we can do. Only mute and hangup. If we can use our own UI we can raise hands, show who is talking, etc. And yes we are talking iOS here. Thanks for the link for the keep-awake.
I see. Can’t you use both though?
No, you can’t use both. If you choose CallKit, you are confined to the view that Apple gives for CallKit. That’s why we would rather not use CallKit and have our own custom view for the in meeting experience. the other problem we have with CallKit is the ability to create another call during the meeting, which we don’t want to allow.
Gotcha. then maybe give the above code a try so the system remains not-idle. This our default when making a video call. Audio calls don’t engage that, FYI.
We tried the same setIdleTimerDisabled but our experience is different than that which we see with the jitsi meet app. When we call it the screen does not dim at all, but once you go to the background the screen dims and then locks after the 30 seconds. With the Jitsi app in the foreground the screen dims but never locks. When you put the jitsi app in the background the same happens. The screen dims but never locks. That is the behavior that we are trying to get. I don’t mind if the screen dims, I just don’t want it to lock. Are you doing anything with the idle timer when you go to the background? Maybe I just don’t understand when RCT_EXPORT_METHOD(activate) and RCT_EXPORT_METHOD(deactivate) are being called? We call the setIdleTimerDisabled in our main app view for the meeting in the viewDidLoad and viewDidDisappear functions. My understanding is that the call only is effective when that app screen is on the glass.