It's the source of uncountable problems for which we don't have a good
solution, since they are caused by buggy implementations of self-managed
connection services by manufacturers.

The notification is posted by a foreground service, which also has the nice
side-effect of keeping the app alive for a long time.

It may be called in the Activity instead of in the Fragment. Handle both.

At the moment it includes:

- display name
- email
- avatar URL

This information is used *only* if no token was specified.

A libre build will exclude the following:

- Analytics modules
- Google Play services GMS
- Crashlytics
- Firebase

Consolidate all failure cases into a single one: CONFERENCE_TERMINATED. If the
conference ended gracefully no error indicator will be present, otherwise there
will be.

It renders a single JitsiMeetFragment which holds the JitsiMeetView view.

Co-authored-by: Saúl Ibarra Corretgé <saghul@jitsi.org>

Add JitsiMeetFragment and refactor the app to use it.

We are going to implement the invite dialog *inside* the SDK, so there is no
need to have all this machinery anymore.

These values must match these ones in React Native:
5939d078a0/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.java (L20-L22)

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.

Since this is a feature implemented in the SDK, it makes sense that all the
plumbing required to make it work it's in the SDK itself.

LeakCanary is a memory leak detection library which will run only in Debug 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>

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.

* Javadoc introduced @code as a replacement of <code> and <tt> which is
  better aligned with other javadoc tags such as @link. Use it in the
  Java source code. If we switch to Kotlin, then we'll definitely use
  Markdown.

* There are more uses of @code in the JavaScript source code than <tt>
  so use @code for the sake of consistency. Eventually, I'd rather we
  switch to Markdown because it's easier on my eyes.

* Xcode is plain confused by @code and @link. The Internet says that
  Xcode supports the backquote character to denote the beginning and end
  of a string of characters which should be formatted for display as
  code but it doesn't work for me. <tt> is not rendered at all. So use
  the backquote which is rendered itself. Hopefully, if we switch to
  Markdown, then it'll be common between JavaScript and Objective-C
  source code.

JitsiMeetViewListener is an integral part of the public API of Jitsi
Meet SDK for Android. Utilize it in the Debug configuration of the Jitsi
Meet app for Android in order to increase (1) awareness of API breakages
and (2) API coverage.

The same goes for JitsiMeetViewDelegate in Jitsi Meet SDK and app for
iOS.

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.

Some devices may give an error stating that INTERACT_ACROSS_USERS_FULL
permission is neeced. This permission can only be achieved by signing the
application with the same key as the system, which is never going to happen so
deal with it by catching any exceptions setting the mode may cause and failing
as gracefully as we can.

Ref:
http://stackoverflow.com/questions/34172575/audiomanager-setmode-securityexception-on-huawei-android-4

When the audio-only mode is enabled, turn on the proximity sensor to dim the
screen and disable touch controls when there is an object nearby.

Turns out React Native's timers (setTimeout / setInterval) don't run while the
app is in the background: https://github.com/facebook/react-native/issues/167

This patch replaces the global timer functions with those from the
react-native-background-timer package, which work in the background.

These timers won't magically make an application work in the background, but
they will run if an application already happens to run in the background. That's
our case while in a conference, so these timers will run, allowing XMPP pings to
be sent and the conference to stay up as long as the user desires.