Check whether context is that of an Activity before launching the Jitsi Conference Activity. If context is not an activity context, apply flag FLAG_ACTIVITY_NEW_TASK to the Jitsi Activity Intent to ensure activity can launch without error.
This scenario would manifest when a user attempts to launch the Jitsi Actvity from a Widget... for example.
https://developer.android.com/about/versions/pie/android-9.0-changes-all#fant-required
Looks like audio devices must be re-set after focus was lost and regained.
Otherwise some devices (tested on a Samsung Galaxy S9) are in a weird state
where the second microphone is not used when speakerphone is on.
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.
The RN Permissions module calls this in a non-UI thread. What we observe is a
crash in ViewGroup.dispatchCancelPendingInputEvents, which is called on the
calling (ie, non-UI) thread. This doesn't look very safe, so try to avoid a
crash by pretending the permission was denied.
In the Android SDK, the setServerURL option is erroneously
ignored. The meeting's serverURL always defaults to
https://meet.jit.si because the serverURL is not parceled.
In 49e3b03885 we turned on SW encoders / decoders
on account of some devices having broken HW *encoders* and also our desire for
using simulcast.
Well, the astute reader may have noticed that only *encoding* was mentioned.
Indeed, we should be able to keep using the HW decoder just fine.
This shouldn't be needed, as ConnectionService should take care of it, but we
suspect some devices don't do it since we got reports of people not hearing
users, and the problem went away when CS was disabled.
Fallback to the non-ConnectionService case for any error. Also, handle errors
when registering the phone account; Pixel C devices throw UnsupportedException.
Some Samsung devices will fail to fully engage ConnectionService if no SIM card
was ever installed on the device. We could check for it, but it would require
the CALL_PHONE permission, which is not something we want to do, so fallback to
not using ConnectionService.
Some devices seem to have a bug in their Android versions and startCall fails
with SecurityError because the CALL_PHONE permissions is not granted. This is
not a requirement for self-managed connection services as per the official
documentation though:
https://developer.android.com/guide/topics/connectivity/telecom/selfManaged
Alas, connection services takes over audio device management too, so let's
handle the error and disable CS if we get SecurityError.
Alex Bumbu
tmoldovan8x8
Jake Breen
Saúl Ibarra Corretgé
Andrzej Moskal
Titus-Andrei Moldovan
Titus-Andrei Moldovan
Volker Braun