Request the 'BLUETOOTH_CONNECT' permissions if not already granted.
If the permission is be granted in this request, the
'MagicBluetoothManger' will be started.
See: #2132
Signed-off-by: Tim Krüger <t@timkrueger.me>
i suspect that peerConnectionFactory could have been null because e.g. "hangup()" was already called which sets it to null. Because of some async task getOrCreatePeerConnectionWrapperForSessionIdAndType might still be called afterwards and it failed because peerConnectionFactory was already null.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
In case a moderator of a restricted room ends the call for all
participants a update participants event with the field 'all=true' will
be thrown by the HPB.
{
"type": "event"
"event": {
"target": "participants",
"type": "update",
"update": [
"roomid": "the-room-id",
"incall": new-incall-state,
"all": true
]
}
}
In that case the call can be ended directly without handling every
single participant.
Resolves: #1881
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>
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>
