The local stream is set only when the activity is created. However, it
was disposed when hanging up, which happens not only when closing the
activity, but also in cases in which the call activity is kept open and
the participant reconnects to the call (for example, when starting the
call times out), which caused the local stream to freeze. Now the local
stream is disposed only when the call activity is destroyed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call state uses a RelativeLayout with a wrap content height where
the state icons (including the progress bar) position was set as above
the message. However, this caused the call state to wrap only the text;
the icons were indeed above the message, but out of the view boundaries.
Now the icons are wrapped in a FrameLayout and the text position is set
below that frame layout instead, which causes the RelativeLayout height
to correctly wrap its content.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a publisher fails during a call a reconnection is triggered, which
first leaves the call and then initiates it again. Initiating a video
call first request the permissions, but it seems that the request hangs
when done while in PiP mode. Due to this if the publisher fails while in
PiP mode and the call is initiated again the call will be simply left,
without reconnecting to it.
The problem is specific to video calls, as in voice only calls
"onMicrophoneClick" is used instead, and it explicitly checks if the
permissions are already granted. Checking if the permissions are already
granted before requesting them is also recommended in the Android
developer guide, and as the permissions are requested during the
original call initialization it is expected that they will be already
granted if the call is changed to PiP mode, so the problem is work
arounded that way (but if the permissions are not granted when the
publisher fails in PiP mode the problem would still happen, although
that should be quite uncommon).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The chat controller gets the room information again and again to check
whether the lobby is enabled and update the UI as needed. This loop is
stopped when the chat controller is detached, but only if no call is
active; if a call is active the room information will still be got again
and again, even if the chat controller is detached.
To solve that now getting the room information is simply stopped when
the chat controller is detached, no matter if there is an active call or
not, and started again when joining the room, which is done when the
chat controller is attached.
However, this is just a quick fix that does not solve the issue in all
cases; the loop can still continue during calls, for example if the
request to get the information is sent before detaching the controller
and the response is received once the controller was detached, as that
would start the timer again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
new notification channels must not be deleted. for this an enum was created, so that in removeOldNotificationChannels there is no manual work to do
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When coming back from PiP mode the self video occupied the full height
of the window. Now the height is set to the default value set in the
layout, so it matches the size used when starting the call activity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The newly created function 'ChatController#determinePreviousMessageIds'
contains now the duplicated code from functions
'ChatCtonroller#processMessagesFromTheFuture' and
'ChatController#processMessagesNotFromTheFuture'.
Signed-off-by: Tim Krüger <t@timkrueger.me>
