Initial commit of the RingRTC Java interface implementation.
The implementation lives in an external .aar with the package
org.signal.ringrtc.
The package provides two high level objects of interest
=======================================================
org.signal.ringrtc.CallConnection -- represents the session of a call,
very similar to WebRTC's PeerConnection.
org.signal.ringrtc.CallConnectionFactory -- creates CallConnection
objects, very similar to WebRTC's PeerConnectionFactory.
The implementation interfaces with the Android application in a few
places:
==================================================================
src/org/thoughtcrime/securesms/ApplicationContext.java -- RingRTC
library initialization at application startup.
src/org/thoughtcrime/securesms/service/WebRtcCallService.java -- Call
creation and state machine.
src/org/thoughtcrime/securesms/ringrtc -- this package implements
interface classes needed by ringrtc and a CallConnectionWrapper helper
class.
The two interfaces needed so far are:
ringrtc/Logger.java
ringrtc/SignalMessageRecipient.java
The logger is self-explanatory, but SignalMessageRecipient is a little
more involved. SignalMessageRecipient encapsulates the Signal-Android
notion of "Recipient" and the mechanism for sending Signal Messages
related to audio/video calling.
The CallConnectionWrapper class is clone of the original
org.thoughtcrime.securesms.webrtc.PeerConnectionWrapper, suitably
modified to match the CallConnection interface.
This class continues to handle the Camera switching APIs, with that
portion of the code remaining unmodified from the original.
CallConnectionFactory Details
=============================
The primary public methods:
initialize() -- initialize the WebRTC library and RingRTC library.
The WebRTC initialization is lifted from the original Signal-Android
code.
createCallConnectionFactory() -- creates a CallConnectionFactory
object. Internally it creates a WebRTC PeerConnectionFactory object
and a RingRTC CallConnectionFactory object.
dispose() -- tears down the CallConnectionFactory object, including
the internal PeerConnectionFactory and RingRTC CallConnectionFactory.
createCallConnection() -- creates a CallConnection object, connecting
that with an application controlled CallConnection.Observer object.
This function takes a CallConnection.Configuration object to link the
CallConnection object with some application provided services, like
sending Signal protocol messages.
CallConnection Details
======================
This object is a subclass of WebRTC's PeerConnection class.
The primary public methods and objects:
CallConnection.Configuration
----------------------------
Configuration object used to parameterize a call. Notable members:
- SignalServiceMessageSender messageSender
- long callId
- org.signal.SignalMessageRecipient recipient
The 'accountManager' is used to fetch public information from the Signal
service, specifically used here to obtain the public Signal TURN
server details.
The 'callId' is a 64-bit pseudo-random number generated when the call
is initiated, used to identify the call through out its lifetime.
The "recipient' is an implementation of the
org.signal.SignalMessageRecipient interface, which encapsulates the
sending of Signal service messages to a recipient (remote peer) using
existing Signal protocol data structures.
The native library needs to be able to send Signal messages via the
service, but it does not have a native implementation to do so.
Instead the native code calls out to the client for sending Signal
messages. To accomplish this, the client implements the
org.signal.SignalMessageRecipient interface and passes an instance of
that in a CallConnection.Configuration object.
CallConnection
--------------
dispose() -- tears down the CallConnection object, including the
internal PeerConnection and RingRTC CallConnection.
sendOffer() -- initiates a call to a remote recipient. This is the
beginning of an outbound call.
validateResponse() -- checks an offer response recipient against the
originating call details.
handleOfferAnswer() -- handles the receipt of answer, which was a
response from an originating offer.
acceptOffer() -- accept an offer from a remote participant. This is
the begin of an incoming call.
answerCall() -- invoked when the call is completely established and
online.
hangUp() -- hang up the connection and shut things done. This is the
end of the call.
sendBusy() -- send the remote side an indication that the local side
is already in a call and the line is busy.
sendVideoStatus() -- send the current state of the local camera video
stream to the remote side.
CallConnection.Observer
-----------------------
Observer object, used by the RingRTC library to notify the client
application of important events and status changes. Similar in spirit
to WebRTC's PeerConnection.Observer.
Observer callbacks come in three flavors:
- state change notifications,
- on stream notifications
- errors conditions
For state notifications, the callback contains the callId, the
recipient and a CallConnection.CallEvent type.
For streams, the callback contains the callId, the
recipient and a org.webrtc.MediaStream.
For errors, the callback contains the callId, the recipient and an
exception type. The currently thrown exceptions include:
- UntrustedIdentityException
- UnregisteredUserException
- IOException
Signed-off-by: Curt Brune <curt@signal.org>
Updates to support ringrtc-android version 0.1.0.
* simplify logging interface
It is no longer necessary for the application to specify a Log object
as the library can log via the NDK directly.
* improve error handling and notification
In a number of places where ringrtc errors could occur, no
notification was ever sent to the user, nor was the UI cleaned up. It
would look like the app was in hung state.
This patch updates these situations to send the WebRtcViewModel a
NETWORK_FAILURE message.
* update handleIncomingCall() for lockManager and notification
During the conversion to RingRTC, the implementation of
handleIncomingCall() missed a couple of things:
-- updating the Phone state with the lockManager
-- sending a message to the viewModel
* log the callId in various handler methods
For debugging purposes it is very handy to have the callId present in
the log during the various call handler methods.
Signed-off-by: Curt Brune <curt@signal.org>
CameraX was initializing Camera2 API stuff on API < 21, causing
crashes at boot. To handle this, we disable the default
ContentProvider initializer and initialize things ourselves for
appropriate API levels.
- Eliminate the explicit spongycastle dependency. All access to
primitives is done through the JCE interfaces now, which allows
us to use a secure native-backed provider like conscrypt.
- Use conscrypt for our default security provider. This gives us
fast TLS 1.2 and 1.3 support on all devices, even before they
had platform support (like 4.4).
- Update minSdk to 18. Unfortunately the JCE interfaces for GCM
primitives are JDK 7+ (!) only, which became supported by Android
at 18.
Due to an Android P bug, we basically need to stop calling
startService() in onResume()/onPause(). That means I had to turn
MessageRetrieval service into a singlton instead of a service. I also
moved the offending KeyCachingService calls into static methods that
didn't have to start the service.
This gives us more control over when it happens, as well as lets us set
things like the debug level. Also let's us get rid of the synchronized
block we had in Application#onCreate().
Added a new logger that persists logs for a longer duration to the
user's cache directory. Logs are encrypted. The new logs are sent
in addition to the user's logcat output.
Unfortunately, there's apps out there that trigger contact changes
very frequently. Because we listen to the system for contact
changes to tell us when to sync, that could result in us sending
an abundance of contact syncs to linked desktop instances.
This throttles contact sync requests using the following methodology:
- By default, throttle contact syncs to 6 hrs while the app is
backgrounded.
- If a sync is throttled in the background, we set a dirty flag and
will execute the sync the next time the app is foregrounded.
- Syncs explicitly requested by desktop are never throttled.
We have to make some changes, and it's gotten to the point where
maintaining it as a separate library is more hassle than it's worth,
especially with Google releasing WorkManager as the preferred job
scheduling library.
