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>
Reduce the number of Detekt issues for the 'OperationsMenuController' by
splitting the function 'processOperation' into smaller pieces. But in
the end it is not enough, because also the now short function
'processOperation' is too complex for Detekt. Because of that the
suppress annotation is set.
Signed-off-by: Tim Krüger <t@timkrueger.me>
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>
how to test:
1. click on file with big file size that was not clicked before (so it's not in the cache)
2. leave media tab view or just select other tab.
3. go back to the clicked file
4. --> see that progress bar is still spinning (otherwise it's already finished and a click should oen the file directly without showing the progress bar)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
when starting media tab from conversation info, the back button opened media tab again. to fix this FLAG_ACTIVITY_CLEAR_TOP was set as flag
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
request maximum_file_preview_size instead hardcoded 100px for file previews
but somehow this his no effect because many file previews are not found on sermo?!
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this is done because in a next step this logic should also be used by the SharedItemsAdapter
extracting is not yet done in a clean way. in a next step some better architecture patterns must be used to separate layers
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
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 toggleEmojiPopup method is a hacky workaround to avoid bug #1914
As the bug happens only for the very first time when the popup is opened,
it is closed after some milliseconds and opened again.
200 milliseconds seems to be a good value to initialize the popup correctly with the desired size
downside: there is even some flickering when opening the "more emojis" window
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
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>
