This is done at the app level, not the SDK.
Currently 2 Firebase services are used:
- Crashlytics
- Dynamic Links
They are enabled in tandem, if the appropriate Google services file
(GoogleService-Info.plist on iOS or google-services.json on Android) is found.
Each service needs to be individually enabled in the Firebase console.
Note that Android 9 Pie (API 28) disallows HTTP requests by default, so an
exception was needed in the app in order for the Metro bundler to work in debug
mode.
Glide (which is used by react-native-fast-image) can cause trouble if the host
app (the one using the SDK) is using Glide already.
To avoid this, don't use the builtin AppGlideModule (as the docs recommend) and
let apps define it.
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.
Saúl Ibarra Corretgé
Saúl Ibarra Corretgé
damencho
Bettenbuk Zoltan
Lyubo Marinov