fix(android) apply flags when launching activity from non-activity context
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
fix(android) reset audio route after audio focus was lost
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.
android: unmute microphone on the ConnectionService handler
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.
android: handle ConnectionService failures more resiliently
Fallback to the non-ConnectionService case for any error. Also, handle errors
when registering the phone account; Pixel C devices throw UnsupportedException.
android: handle ConnectionService failures more resiliently
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.
android: disable ConnectionService if permissions are not granted
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.
Samsung devices (of course) seem to stick with the earpiece if we first select
Bluetooth but then set speaker to false. Reverse the order to make everyone
happy.
This only applies to the generic and legacy handlers.
android: fix initializing audio device handler modules too early
When ConnectionService is used (the default) we were attaching the handlers too
early, and since attaching them requires that the RNConnectionService module is
loaded, it silently failed. Instead, use the initialize() method, which gets
called after all the Catalyst (aka native) modules have been loaded.
Alex Bumbu
tmoldovan8x8
Jake Breen
Saúl Ibarra Corretgé
Andrzej Moskal
Titus-Andrei Moldovan
Titus-Andrei Moldovan
Volker Braun