It's not necessary and makes the build faster.

A libre build will exclude the following:

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

It's a number whichb must be ever increasing with each build submitted to the
store.

Automate its value by using the number of seconds since 1st of January 2019.
That should be enough for ~680 years.

When running the app from Android Studio the React packager is not automatically
started. In vanilla RN projects this is done by the "react-native run-android"
command, but often times it is desired to run from Android Studio.

This fixes that by starting the packager from Gradle.

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.

The annotation processor is required for our Glide module to be included.

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.

Set them to the next release versions. In additon, the buildNumber variable will
be used to match the requirements of versionCode:
https://developer.android.com/studio/publish/versioning

that is, a monotonically increasing number, independent of the app / sdk
version.

LeakCanary is a memory leak detection library which will run only in Debug mode.

This reverts commit 9e0fee6c7d.

WebRTC requires Java 8, and Java 7 is now considered unsupported:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/discuss-webrtc/V1h2uQMDCkA/RA-uzncVAAAJ

Updates react-native-webrtc to get rid of Java 8 requirement for
the Android app.

It was recently introduced in WebRTC, so we we need to enable it project wide.
As for what features are supportd, see:
https://developer.android.com/studio/write/java8-support.html

Based on work authored by Shuai Li <sli@atlassian.com>, Daniel Ornelas
<dornelas@atlassian.com>, and Lyubo Marinov <lmarinov@atlassian.com>.

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.

Now that Apple have approved build 1.3.204 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.

Now that Apple have approved build 1.2.199 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.

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.

The implementation varies across platforms, with the same goal: allow the app to
use the entire screen real state while in a conference.

On Android we use immersive mode, which  will hide the status and navigation bars.

https://developer.android.com/training/system-ui/immersive.html

On iOS the status bar is hidden, with a slide effect.

Now that Apple have approved build 1.1.185 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.

Now that Apple have approved build 1.0.178 for release in the App Store,
the short app version needs to be incremented; otherwise, no new builds
can be uploaded to TestFlight and, respectively, for release in the App
Store.

The variables in gradle.properties can be overridden on command line like: -Pversion=1.

Bundle our custom icon font jitsi.ttf in the Android app (which we
already do for the iOS app).

Additionally, remove icon font files which are not in use.

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.

As an intermediate step on the path to merging jitsi-meet and
jitsi-meet-react, import the whole source code of jitsi-meet-react as it
stands at
2f23d98424
i.e. the lastest master at the time of this import. No modifications are
applied to the imported source code in order to preserve a complete
snapshot of it in the repository of jitsi-meet and, thus, facilitate
comparison later on. Consequently, the source code of jitsi-meet and/or
jitsi-meet-react may not work. For example, jitsi-meet's jshint may be
unable to parse jitsi-meet-react's source code.