Jitsi Meet Android SDK 4.1.0 not ending activity when conference is ended

According to Android SDK · Jitsi Meet Handbook the activity should finish when the meeting manager ends the meeting for participants. This was happening on 3.10.2 but fails on 4.1.0

Documentation reference:


This class encapsulates a high level API in the form of an Android FragmentActivity which displays a single JitsiMeetView . You can pass a URL as a ACTION_VIEW on the Intent when starting it and it will join the conference, and will be automatically terminated (finish() will be called on the activity) when the conference ends or fails.

What are you seeing instead? Can you please provide some adb logcat logs?

Instead of terminating the meeting it just shows an indeterminate spinner on black screen with my identity as if it’s trying to connect.

I have captured a concise logcat and screenshot. How do I attach files here?

I think you can just drag and drop.

Did you extend the JitsiMeetActivity?

logcat.txt (304.0 KB)

I’ll share some code to show you the options I am using and how I’m starting the activity:

JitsiMeetConferenceOptions jitsi_options = null;

JitsiMeetUserInfo info = new JitsiMeetUserInfo();

jitsi_options = new JitsiMeetConferenceOptions.Builder()
    //.setWelcomePageEnabled(false) - removed in jitsi sdk 4.x
    .setFeatureFlag("add-people.enabled", false)
    .setFeatureFlag("calendar.enabled", false)
    .setFeatureFlag("conference-timer.enabled", false)
    .setFeatureFlag("invite.enabled", false)
    .setFeatureFlag("live-streaming.enabled", false)
    .setFeatureFlag("meeting-password.enabled", false)
    .setFeatureFlag("recording.enabled", false)
    .setFeatureFlag("server-url-change.enabled", false)
    .setFeatureFlag("video-share.enabled", false)
    .setFeatureFlag("security-options.enabled", false)
    .setFeatureFlag("toolbox.alwaysVisible", true)
    .setFeatureFlag("android.screensharing.enabled", false)

IntentFilter intentFilter = new IntentFilter();
LocalBroadcastManager.getInstance(MainActivity.mSingleton).registerReceiver(mBroadcastReceiver, intentFilter);

JitsiMeetActivity.launch(MainActivity.mSingleton, jitsi_options);

For what it’s worth, I do get the BroadcastEvent for CONFERENCE_TERMINATED, it’s just that the Jitsi activity doesn’t finish/go away.

We changed the way we finish the Activity in SDK 4: jitsi-meet/JitsiMeetActivity.java at c34d2de51967a47aa018ef95724f5ab80b54cac6 · jitsi/jitsi-meet · GitHub

I updated the demos and they finish properly: GitHub - jitsi/jitsi-meet-sdk-samples: Jitsi Meet SDK examples (Android and iOS)

Can you give those a try? Is there anything else you do differently?

Oh wait. Does adding .setFeatureFlag("welcomepage.enabled", false) help?

Sorry for the delay. I just tested with that feature flag set to false and it made no difference.

I’ll look into the demos next.

Is there possibly any incompatibility with the jitsi server version we are using?

hi jitsi-meet-prosody 1.0.5638-1 all Prosody configuration for Jitsi Meet
hi jitsi-meet-web 1.0.5638-1 all WebRTC JavaScript video conferences
hi jitsi-meet-web-config 1.0.5638-1 all Configuration for web serving of Jitsi Meet
hi jitsi-videobridge2 2.1-592-g1e2879e0-1 all WebRTC compatible Selective Forwarding Unit (SFU)

They seem to all have various version numbering and updates are released at different times (which I completely understand). I just don’t know if it’s definitely client-side? I figure it is since I do get the BroadcastEvent but just wanted to be thorough.

I just tried the current Android SDK test app (nice sample, by the way…it’s short and easy to follow). Unfortunately I see the same thing against our servers:

So I used meet.jit.si and it worked as expected. It must be something server side I guess. Please see my previous post about the server versions we’re currently using. And I apologize for consuming your time when it seems to be a deployment issue on our end.

No worries, thanks for willing to try things out.

I took a look at the logcat and TBH I’m a bit lost. The SDK bundles all code, so it should always work with the backend.

Unfortunately I cannot dig deeper, your backend is ~1 year old (Release jitsi-meet_5638 · jitsi/jitsi-meet · GitHub) and since it’s fixed in further releases I cannot justify the time to dig into it. Plus, even if we found the issue, we don’t make old re-releases.

So, the best you can do is update the infra. Sorry about that.

I completely understand and I didn’t expect any solution once I realized it works with your latest infrastructure. Unfortunately I don’t control the back end in this environment. Thank you for your time.

1 Like

@saghul Related to this version part of this discussion - can you help me understand this?

We use apt update from https://download.jitsi.org stable/ and this was done on December 9 and we installed what looks to be:

user@host:~$: dpkg -l | grep jitsi
jitsi-meet-prosody                 1.0.5638-1
jitsi-meet-web                     1.0.5638-1
jitsi-meet-web-config              1.0.5638-1
jitsi-videobridge2                 2.1-592-g1e2879e0-1

Also, see images. Can you help clear up the confusion?

The jitsi-meet-web version was pushed on Dec 6 and you installed it on Dec 9. And this is part of jitsi-meet 2.0.6689.

Jitsi-meet 2.0.5638 was created on 16 Mar 2021:

jitsi-meet is a meta-package that depends on certain component versions and depends on jicofo, jvb and jitsi-meet-web.

Does this answer your questions?

:thinking: Are you saying that the latest stable (jicofo, jvb, etc) is not installed when running apt update?

After running that, dpkg -l tells me:

hi  jicofo                             1.0-840-1
hi  jitsi-meet-prosody                 1.0.5764-1
hi  jitsi-meet-web                     1.0.5764-1
hi  jitsi-meet-web-config              1.0.5764-1
hi  jitsi-videobridge2                 2.1-607-g153f7e4e-1

is that what you would expect? Are those really only current as of Apr 09, 2021?

No, you’re confusing the version of the wrapper (Jitsi meet) with the versions of the individual packages. JM 2.0.5638 is the wrapper, the individual packages have their own version numbers (e.g. jitsi-meet-web 1.0.5638). All those packages are bundled in a wrapper which has its own version number.

I guess @saghul’s response confused me - We are running the same as @gordon_warren

Going by this, you are running version 6689 of jitsi meet (the bundle). The individual packages in those bundles have different version numbers. The bundle wraps them all and presents them as one installable package.

The changelog.txt also has its own version number… lol.

I get the bundle concept. With all the version numbers (meta package vs individual packages) and various ways to install / upgrade, it’s confusing (to me anyway) how to help someone if there is no direct way to know exactly how current things are. I have always used dpkg -l

I think it just takes getting used to. Yes, it would be more coherent if everything had the same version number, but because they’re different packages, each one needs to be versioned differently. dpkg -l will return all the relevant packages with their corresponding version numbers. But for more robust reporting, I use:

dpkg -l "jitsi-*" "jicofo*" "prosody*" | egrep '^ii'

This gives me everything, including the bundle version:

Latest Unstable-12-23-21