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.
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.
Android Studio won't build the app otherwise. Since the gradle plugin 3.0 beta7,
the minimum supported build tools version is 26.0.2, so set it to that. Also
bump compileSdkVersion to 26 since they need to match (in the major number, that
is).
The target API is still 25. Android Oreo (26) brought some changes in overlay
permissions which I haven't figured out yet.
This reverts commit c9a29153dd.
Now that react-native-webrtc supports the permissions system in 23, use it since
it provides a more pleasant experience to users.
In addition, fix a bug in the previous code: the React Native view must be
loaded after we have acquired the permission to draw on top of other apps,
otherwise our app may crash while we accept the permission, since React may try
to draw.
API level 22 is below 23 (aka Marshmallow), which included an overhaul in the
permissions system. React Native recommends 22 (it's the default when you create
a new app) and there have been reports when set higher [0] and [1].
This also fixes a critical bug, wherein Jitsi Meet wouldn't request permissions
for the camera and microphone.
Last, this change also allows us to get rid of the overlay checking code,
because it was only needed for API level 23 or higher.
[0]: https://github.com/facebook/react-native/pull/10479
[1]: https://github.com/facebook/react-native/issues/10587
Dames en heren, welcome to Jitsi Meet SDK for Android, the Jitsi Meet library
for Android.
The Jitsi Meet SDK encapsulates React Native and all the dependencies Jitsi
Meet has so other aopplications can integrate it easily.
Unlike iOS, creating "fat" libraries is not allways (if at all) possible on
Android, however, effort was put into making the integration as easy as
possible.
While React Native can be embedded in native applications, I don't think it was
designed to be embedded as part of an Android library, hidden away from the
application using it. This surfaced as a number of issues which had to be
addressed specifically due to our use-case:
- Activity lifecycle methods must be linked with the React Native engine, so the
library provides wrapper methods.
- Custom fonts have to be manually added as assets, since the provided gradle
script doesn't work properly in a library target.
- The RN packager has to be manually triggered since the gradle script will no
longer do it for us.
At this stage, the Jitsi Meet application is just a small single activity
application which uses the Jitsi Meet SDK to create a single activity which
represents the entire application. Events and external conference handling are
forthcoming.
PS: Yours truly would like to add that it was a lot more fun to work on the iOS
side of things.
Recent versions of the Android plugin for Gradle started to automatically
download the SDK build tools dependency if it is not installed already.
So it is no longer necessary to have the developer of the Android app
install the SDK build tools dependency in advance.
As a step toward merging jitsi-meet-react with jitsi-meet to share as
much source code as possible between mobile and Web, merge the part of
jitsi-meet-react's source tree which supports mobile inside the
jitsi-meet source tree and leave jitsi-meet-react's Web support in the
source code revision history but don't have it in master anymore because
it's different from jitsi-meet's Web support. In other words, the two
projects are mechanically merged at the file level and don't really
share source code between mobile and Web.
Bettenbuk Zoltan
Saúl Ibarra Corretgé
Lyubo Marinov
Lyubomir Marinov