Should fix this error:
~~~
Fatal Exception: java.lang.IllegalArgumentException: org.jitsi.meet: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
at android.app.PendingIntent.checkFlags(PendingIntent.java:402)
at android.app.PendingIntent.getActivityAsUser(PendingIntent.java:485)
at android.app.PendingIntent.getActivity(PendingIntent.java:471)
at android.app.PendingIntent.getActivity(PendingIntent.java:435)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(com.google.android.gms:play-services-basement@@17.5.0:25)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(com.google.android.gms:play-services-basement@@17.5.0:21)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(com.google.android.gms:play-services-base@@17.5.0:170)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(com.google.android.gms:play-services-base@@17.5.0:173)
at com.google.android.gms.common.GoogleApiAvailability.zaa(com.google.android.gms:play-services-base@@17.5.0:112)
at com.google.android.gms.common.api.internal.GoogleApiManager.zaa(com.google.android.gms:play-services-base@@17.5.0:252)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.5.0:109)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.onConnectionFailed(com.google.android.gms:play-services-base@@17.5.0:75)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zai(com.google.android.gms:play-services-base@@17.5.0:263)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.5.0:133)
at com.google.android.gms.common.api.internal.GoogleApiManager.handleMessage(com.google.android.gms:play-services-base@@17.5.0:164)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:240)
at android.os.Looper.loop(Looper.java:351)
at android.os.HandlerThread.run(HandlerThread.java:67)
~~~
Fix for this crash:
~~~
Fatal Exception: java.lang.IllegalArgumentException: org.jitsi.meet: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
at android.app.PendingIntent.checkFlags(PendingIntent.java:377)
at android.app.PendingIntent.getActivityAsUser(PendingIntent.java:460)
at android.app.PendingIntent.getActivity(PendingIntent.java:446)
at android.app.PendingIntent.getActivity(PendingIntent.java:410)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(GoogleApiAvailabilityLight.java:25)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(GoogleApiAvailabilityLight.java:21)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(GoogleApiAvailability.java:97)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(GoogleApiAvailability.java:100)
at com.google.android.gms.common.GoogleApiAvailability.zaa(GoogleApiAvailability.java:41)
at com.google.android.gms.common.api.internal.GoogleApiManager.zac(GoogleApiManager.java:214)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.onConnectionFailed(GoogleApiManager.java:86)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.connect(GoogleApiManager.java:219)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(GoogleApiManager.java:112)
at com.google.android.gms.common.api.internal.GoogleApiManager.handleMessage(GoogleApiManager.java:145)
at android.os.Handler.dispatchMessage(Handler.java:107)
at com.google.android.gms.internal.base.zap.dispatchMessage(zap.java:8)
at android.os.Looper.loopOnce(Looper.java:238)
at android.os.Looper.loop(Looper.java:357)
at android.os.HandlerThread.run(HandlerThread.java:67)
~~~
This basically reverts
e61ccc956f
since we are no longer interested in using Detox.
In addition, the WebRTC initialization code was only placed in the RAN
instance manager holder's App initialization path, which is now gone, so
add it to the Activity initialization path.
Few (but some) RN modules rely on the main Application implementing
ReactApplication.
For Detox to actually work on Android we need the app to be a greenfield
app. Specifically, the main Application must implement ReactApplication.
In order to satisfy this requirement we are introducing a helper
ReactNativeHost implementation which encapsulates our RN integration,
which is what the ReactApplication needs to expose.
While we don't really need this ourselves (except if we end up adopting
Detox) we have known people who fork our app and add dependencies that have
this requirement to it, so this change will help them too.
This event is the event host applications need to listen to for knowing when to
dispose the SDK from now on.
Since the introduction of breakout rooms it's possible that we navigate from one
meeting to another, so there will be several conference join / terminations.
In addition, local track destruction is now moved to SET_ROOM when there is no
room, aka, we are going back to the welcome page or to the black page.
Looks like the "Firebase Analytics" dependency is needed when migrating to the
new Firebase Crashlytics SDK. We are only interested in the "latest iversion
crash-free users" stat, which seems to require this. The documentartion is
somewhat confusing though.
JSC wasn't the cause for the crash we were hunting after all. RN doesn't set
HErmes as the default, neither does Expo, so the jury is still out on Hermes,
and it looks like JSC is still the safest bet.
In addition, the way Hermes is packaged (as a standalone AARs, instead of a
local "Maven repo") complicates the SDK build and can make the resulting build
bloated.
When exiting PiP with by pressing the X the onPictureInPictureModeChanged method
is called. Since onResume is called a while after, in case the maximize button
is called, it's not easy to know if the user pressed the X button, and that was
the cause for exiting PiP.
So, in order to avoid show the user they are still in the meeting, bring the
activity to the foregound so they can hangup.
Android for Enterprise provides special feature for applications to obtain configuration through RestrictionManager remotely by some MDM solution.
Jitsi Meet can be remotely installed and provisioned with a proper URL (making URL not editable by the user) inside the Work Profile or Fully managed device.
It's the source of uncountable problems for which we don't have a good
solution, since they are caused by buggy implementations of self-managed
connection services by manufacturers.
