We missed a spot when transitioning to split apk versions. It ended up
breaking the update prompt for web apks.
This will put the raw universal apk version in the json file, which
should put us back on the right track.
Fixes#8936
Previously, we'd crash if we couldn't find the attachment at runtime,
but that's not uncommon if someone deletes before sending. Now we just
fail.
Also, previously we'd fail if we couldn't create a memory file. Now we
will only fail if the attachment is >100mb (same as the other video
failures).
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.
