Via the conversation info or the menu entry in the conversation menu a
overview of shared items can be opened.
Signed-off-by: Tim Krüger <t@timkrueger.me>
The call flags describe the streams provided by the client, so in a
video call both audio and video are provided, not just video.
Note that as publishing permissions are currently not implemented in the
Android app the provided flags do not take into account the available
permissions. Nevertheless, the server restricts the flags based on the
permissions, so the other participants would see the appropriate flags.
In the future it would be better to send the right flags directly from
the Android app.
Similarly, for now, it is just assumed that both audio and video tracks
will be provided by the Android app, but the flags should reflect the
actually available tracks (for example, if it was not possible to get a
video track for some reason the call flags should not include
"WITH_VIDEO").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Android app creates a connection with a participant when that
participant joins the call and ends it when the participant leaves the
call. However, it also created a connection when any signaling message
was received from a participant that had no connection yet. Due to this
if a signaling message was received from a participant before that
participant was in the call the Android app tried to establish a
connection too soon, which would be rejected by the HPB.
Similarly, if a signaling message was received from a participant after
that participant left the call a connection will try to be established.
That would fail, but the connection object was not removed, and if that
participant joined the call again no connection would be established, as
a connection for that participant was already found, even if it was not
usable.
To solve that now a connection is created when a signaling message is
received only if that message is an offer (which is necessary without
HPB if the other participant sends the offer before this participant
"noticed" that she is in the call); otherwise the message is ignored.
Besides that a connection will no longer be created either when setting
up the video stream. However, this would be just for correctness and it
should not make any difference, as the MediaStreamEvents that cause that
are only emitted by changes in peer connections, so they should be
already created.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
NotificationWorker provides the user information under KEY_USER_ENTITY parameter of the notification intent, but does not set the KEY_INTERNAL_USER_ID parameter.
With this change existing ChatController instance that has been opened manually from the conversation list is properly reused when a notification is opened.
Otherwise two instances of the ChatController were running in parallel for the same room, causing unintended side effects.
Signed-off-by: Dariusz Olszewski <starypatyk@users.noreply.github.com>
The peerConnection get passed the tracks of the localStream. So to make
sure that the tracks are not released before the connection is closed it
will now done after closing the peerConnection.
Signed-off-by: Tim Krüger <t@timkrueger.me>
The in 'MagicPeerConnectionWrapper#removePeerConnection' used method
'PeerConnection#removeStream' was not longer available in the unified
plan. So to make sure that the local stream is disposed, it will now be
done in 'CallActivity#hangup'.
Resolves: #1773
See: [1]
[1] https://webrtc.org/getting-started/unified-plan-transition-guide
Signed-off-by: Tim Krüger <t@timkrueger.me>
if wired headset is plugged in hide earpiece and speaker icons
if wired headset is plugged out show earpiece and speaker icons
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
