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>
We've been seeing a lot of socket timeouts on REST requests under
certain conditions. The issue seems to be a problem with the OkHttp
client. Through testing, I've seen that resetting the receiver and
retrying again seems to resolve most issues.
The crash happened because #getNextClosestEvent was called when
mmsDatabase was null, which would normally be impossible. However, it
seems implied that somehow #getNextClosestEvent was being called in the
parent constructor before the child class was fully initialized. That
would imply that the looper was called synchronously in some freak
scenario, but it's the only explanation. So I added a delay to the call
in the parent constructor.
```java
java.lang.NullPointerException:
at org.thoughtcrime.securesms.revealable.RevealableMessageManager.getNextClosestEvent (RevealableMessageManager.java:40)
at org.thoughtcrime.securesms.revealable.RevealableMessageManager.getNextClosestEvent (RevealableMessageManager.java:23)
at org.thoughtcrime.securesms.service.TimedEventManager.lambda$scheduleIfNecessary$1 (TimedEventManager.java:44)
at org.thoughtcrime.securesms.service.-$$Lambda$TimedEventManager$kZDO3F2WBQVtGx-SkAgEDt8jCeU.run (Unknown Source:2)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:193)
at android.os.HandlerThread.run (HandlerThread.java:65)
```
Because SMS sending is split over two jobs, there's no max retry limit
respected if we find out about the failure in SmsSentJob -- it's
requeued as a new job with a fresh attempt counter.
This commit carries a retry count between the two jobs. It also verifies
that we have service before attempting to send a message at all.
Relates to #8268
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.
Previously we were starting a background service, which isn't allowed
for targetSdk 26. This will do the same thing but at a time decided by
the system.
We never properly registered the ExpirationListener, meaning we were
relying on the wait-notify loop of ExpirationManager to delete things.
This normally works, but fails when your phone goes to sleep. So I
properly registered the receiver, and then added a failsafe to re-run
the ExpirationManager if we're about to render an expired message.
Fixes#7906
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.
