This makes the PermissionsAndroid builtin module work.
Introduce the JitsiMeetActivityInterface, which defines the interface that
activities using JitsiMeetView directly must implement in order to ensure full
functionality.
The JSC version used by React Native is about 3 years old, and doesn't implement
things like Symbol or Typed Arrays, which require polyfills. These polyfills are
sometimes a los less performant, as is the case for Typed Arrays.
Bumping an updated JSC version makes both platforms consistent when it comes to
the JavaScript platform.
Use react-native-fastimage, which uses 2 full-native image impleentations using
well known and mature (native) libraries.
This gets us rid of 2 libraries which were observerd as a source of bugs and
created trouble with dependencies: react-native-fetch-blob and
react-native-img-cache. They are also no longer well maintained.
It's a separate view (on the native side) and app (on the JavaScript side) so
applications can use it independently.
Co-authored-by: Shuai Li <sli@atlassian.com>
Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
As the need for adding more views connected with our React code arises, having
everything in JitsiMeetView is not going to scale.
In order to pave the way for multiple apps / views feeding off the React side,
the following changes have been made:
- All base functionality related to creating a ReactRootView and layout are now
in BaseReactView
- All Activity lifecycle methods that need to be called by any activity holding
a BaseReactView are now conveniently placed in ReactActivityLifecycleAdapter
- ExternalAPIModule has been refactored to cater for multiple views: events are
delivered to views, and its their resposibility to deal with them
- Following on the previous point, ListenerUtils is a utility class for helping
with the translation from events into listener methods
* feat(recording): add sounds for when recording starts and stops
* squash: use constants, play sounds for file only
* squash: rename recordingStopped.mp3 -> recordingOff.mp3
* squash: flip var declaration for alpha order
Releases are also published to jcenter, and due to how the dependency is
declared, we are picking the latest release from there, which is arguably not
what we want.
Activity.enterPictureInPictureMode method must be invoked synchronously
on userLeaveHint callback in order to be sure that the current Activity
is still visible (does not transit to PAUSED state). Previously if the
asynchronous processing would be delayed enough for the Activity to go
into the PAUSED state it will be too late to go into the PiP mode.
* Button conditionally shown based on if the feature is enabled and available
* Hooks for launching the invite UI (delegates to the native layer)
* Hooks for using the search and dial out checks from the native layer (calls back into JS)
* Hooks for handling sending invites and passing any failures back to the native layer
* Android and iOS handling for those hooks
Author: Ryan Peck <rpeck@atlassian.com>
Author: Eric Brynsvold <ebrynsvold@atlassian.com>
Activity.enterPictureInPictureMode can fail for a couple of reasons
mentioned in the JSDoc:
"The system may disallow entering picture-in-picture in various cases,
including when the activity is not visible, if the screen is locked or
if the user has an activity pinned."
It seems to be safe to assume that those cases will be caught by
a RuntimeException handler (only RuntimeExceptions can be left without
explicit catch block).
Anyway the root cause for problems is the fact that the current process
for going to the picture in picture mode is not synchronised with
Activity's lifecycle. On Activity's "userLeaveHint" callback we dispatch
async task to the JS code which only then after dispatching some more
stuff eventually call native method that enter PiP. In case we spend too
much time on the JS side and the Activity goes to PAUSED state the call
will fail with IllegalStatException: "activity is not visible",
"activity is paused" etc. This means with this fix the app will not
crash, but we'll see it sometimes not go to the PiP mode as expected.
On Android the files will be copied to the assets/sounds directory of
the SDK bundle on build time. To play the "asset:/" prefix has to be
used to locate the files correctly.
On iOS each sound file must be added to the SDK's Xcode project in order
to be bundled correctly. To playback we need to know the path of the SDK
bundle which is now exposed by the AppInfo iOS module.
Adds Nat64InfoModule which resolves IPv6 addresses for IPv4 addresses
in IPv6 only network where jitsi-meet deployment does not provide any
IPv6 addresses as ICE candidates.
Adds base/sounds feature which allows other features to register a sound
source under specified id. A new SoundsCollection component will then
render corresponding HTMLAudioElement for each such sound. Once "setRef"
callback is called by the HTMLAudioElement, this element will be added
to the Redux store. When that happens sound can be played through the
new 'playSound' action which will call play() method on the stored
HTMLAudioElement instance.
The new libwebrtc.jar contains an extra unused class file, when proguard is enabled result in the following warning:
org.chromium.build.BuildHooksAndroidImpl: can't find superclass or interface org.chromium.build.BuildHooksAndroid
java.lang.RuntimeException: Tried to access a JS module before the React instance was fully set up. Calls to ReactContext#getJSModule should only happen once initialize() has been called on your native module.
at com.facebook.react.bridge.ReactContext.getJSModule(ReactContext.java:102)
at com.rnimmersive.RNImmersiveModule.emitImmersiveStateChangeEvent(RNImmersiveModule.java:74)
at org.jitsi.meet.sdk.JitsiMeetView.onWindowFocusChanged(JitsiMeetView.java:504)
at android.view.View.dispatchWindowFocusChanged(View.java:10257)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1193)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:1197)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3602)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
This only works automatically on Android >= 8. On other platforms / versions, it
relies on the SDK user on implementing a "reduced UI" mode and reacting to the
"request PIP" delegate method.
On Android we go into "immersive mode" when in a conference, this is our way of
being full-creen. There are occasions, however, in which Android takes us out of
immerfive mode without us (the application / SDK) knowing: when a child activity
is started, a modal window shown, etc.
In order to be resilient to any possible change in the immersive mode, register
a listener which will be called when Android changes it, so we can re-eavluate
if we need it and thus re-enable it.
hristoterezov
Bettenbuk Zoltan
Saúl Ibarra Corretgé
Lyubo Marinov
virtuacoplenny
Guus der Kinderen
paweldomas
Ryan Peck
Shuai Li
damencho